Mad Bugs: Vim vs. Emacs vs. Claude
by Munksgaard on 4/1/2026, 6:05:57 AM
https://blog.calif.io/p/mad-bugs-vim-vs-emacs-vs-claude
Comments
by: kleiba
For Emacs, I agree with the maintainer's analysis that this is really a git bug: what happens is that Emacs runs `git ls-files` and that triggers a script execution.<p>So, the attack vector here is the following: attacker provides a malicious script in a .git directory, packaged for download. If the user unpacks the the package and merely opens a file, Emacs runs `git ls-files` which in turn executes the malicious script.<p>However, while I agree that this is a flaw in git, and Emacs should rightfully expect that running an "ls" command should be considered harmless, I do not agree with the stance that this should not require an reaction on the part of the Emacs maintainers: Now that you've been made aware of this unfortunate git behavior, I think some steps should be taken to not trigger it. That is, the functionality that runs `git ls-files` should be double checked (do we really need it? can we avoid the malicious side-effects? etc.)
4/1/2026, 7:49:46 AM
by: snarf_br
Overhyped, misnomer as this is not an RCE, and emacs maintainers who are correct as you can trigger the same thing by just running git ls-files to execute things if you configure the .git folder as the exploit does.
4/1/2026, 6:50:03 AM
by: chrismorgan
I suspect that if you asked ten Vim developers where they’d start looking for this kind of security issue, at least nine of them would say “modeline” (and if one didn’t, it would just be because they forgot about the feature, and would change their answer to that as soon as you mentioned it). There’s a reason popular configurations have disabled it from time immemorial.<p>As for the Emacs thing, it feels <i>utterly</i> unfair to blame Emacs. The issue is 100% Git, and it’s unreasonable <i>and undesirable</i> for things like Emacs to try to put guard rails around <i>parts</i> of its functionality. Especially guard rails that may harm functionality. They were right to decline the suggested patch.<p>I don’t know how the sessions actually ran, but the Vim one probably started with “low-hanging fruit, let’s start by seeing if modeline has accidentally become insecure <i>yet again</i>”, and the emacs with “meh, don’t know anything offhand, before delving into code let’s see if… ooh look it runs Git, so can we apply the ol’ fsmonitor chestnut there?”
4/1/2026, 6:52:10 AM
by: i_cannot_hack
The first one seems to indeed be a real RCE in vim.<p>Also including the emacs one as a "found vulnerability" seems really disingenuous. It basically amounts to "emacs will call git status, and git status will call git hooks that can execute arbitrary code".<p>1. As the Emacs maintainers point out, it is indeed an issue with git, not emacs, and they are completely right to not address the issue.<p>2. It is something that has been known for decades. That is the reason hooks are never copied when doing git clone, to prevent this scenario (notice that the author uses wget instead of git clone to get around this).<p>Funnily enough this posts highlights both the strengths and the hazards of using AI, (1) quickly and easily finding real issues that would have taken a human a laborious audit to find (2) quickly and unthinkingly generating plausible sounding but ultimately meaningless vulnerability reports on some clout chasing mission and overwhelming open source maintainers with AI slop.
4/1/2026, 6:50:53 AM
by: 152334H
Doubtful commentary misses the obvious: that, had Calif been slightly more responsible in their harness design -- and in particular, their definition of what constitutes a real bug -- it'd be rather unsurprising if Claude correctly dug some up.
4/1/2026, 7:31:43 AM
by: zingar
The claim is astonishing, given emacs’ continuous use and open source scrutiny for decades. Edit: and turns out to be a problem with git, not emacs.<p>OTOH it’s really just the core that has been used so widely and so continuously for so long. This integration with git will have been scrutinized far less.<p>As an emacs user I frequently find myself in territory where I’m seemingly the only person in the world with my use case. In fact that’s half of the value: I can make emacs do whatever I want. Which means there’s security consistent with a bus factor of 1.
4/1/2026, 6:48:13 AM
by: Andebugulin
That's a bit funny to me, because the level of absurdity you get from reading something like that is insane, I have been using vim on a daily bases for more than 5 years now. One day thought about contributing to vim because was silly enough to believe that the tool shouldn't be that many lines of code, something doable, like in couple thousands, then found out its way way more than that and closer to half a mill, couldn't even dream of understanding anything, not close to be fluent enough to find RCEs.
4/1/2026, 6:48:11 AM
by: normie3000
I'd be interested to understand what modelines are for, and if this is a class of bug that can be disabled via vim settings. Also, are there editors which could not be affected by this class of bug?
4/1/2026, 6:41:00 AM
by: pjmlp
> How do we professional bug hunters make sense of this? This feels like the early 2000s. Back then a kid could hack anything, with SQL Injection. Now with Claude.<p>Lack of accountability.<p>With other industries, when people aren't happy with their products, they ask for money back, they sue, they switch to the competition.<p>There are no EULA that assert removal of customer rights if the product is acquired.
4/1/2026, 6:37:28 AM
by: grimm8080
What does RCE mean?
4/1/2026, 6:34:10 AM
by:
4/1/2026, 7:27:06 AM
by: jeremie_strand
[dead]
4/1/2026, 7:35:03 AM
by: 000ooo000
tldr<p><pre><code> /* vim: set showtabpanel=2 tabpanel=%{%autocmd_add([{'event'\:'SafeStateAgain','pattern'\:'*','cmd'\:'!id>/tmp/calif-vim-rce-poc','once'\:1}])%}: */</code></pre>
4/1/2026, 6:47:25 AM