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.
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.
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 does not require a 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.)
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.
Disclosure: I didn’t discover the bugs, but helped write the blog post.
These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not strictly RCE.
At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.
I'm pretty sure the lesson is that at the end of the day, it’s worth being aware of the risks of using git, as security issues intrinsic to git can extend to other tools which use git as a component.
I think we can agree that Git is at least partly responsible for this issue, if not more.
That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context.
This is why I think editor maintainers should do more to protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.
Please read the LLM output critically instead of doubling down on it.
Your defense-in-depth framing makes no sense. If .git/config or similar mechanisms are the attack vector, then adding more editor safeguards would be treating a symptom, as the real problem is git's trust model. The "users don't think about git when using editors" argument also proves too much. Many users also do not think about PATH, shell configs, dynamic linker, or their font renderer either, but you cannot make editors bulletproof against all transitive dependencies...
Seriously, it is actually backwards. Git is where the defense belongs, not every downstream tool that happens to invoke git. Asking editors to sandbox git's behavior is exactly as absurd as it sounds.
And BTW, "technically AV:L but feels like RCE" is your usual blog-post hype. It either is, or is not.
Sure, but you said that was the end of the day analysis, and I didn't think you went far enough in your analysis.
FWIW, I'm not thinking about git at all since I use Mercurial, and never enabled vc hooks in my emacs, which is based on 25.3.50.1, so wasn't affected by this exploit - I tested. I use git and hg only from the command-line.
My end-of-day analysis is to avoid git entirely if you can't trust its security model. ;)
Should the emacs developers also do more to secure emacs against ImageMagick exploits?
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.
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.
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.
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.
As for the Emacs thing, it feels utterly unfair to blame Emacs. The issue is 100% Git, and it’s unreasonable and undesirable for things like Emacs to try to put guard rails around parts of its functionality. Especially guard rails that may harm functionality. They were right to decline the suggested patch.
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 yet again”, 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?”
Yup, I've had "nomodeline" in my vimrc for years. I used to add the "securemodelines" plugin https://www.vim.org/scripts/script.php?script_id=1876 but just recently removed that too (I think I may have ran into an annoyance after a vim update, and decided I never really use automatic modeline support anyway)
Those that have some git status information in their shell prompts should probably make sure they are not bitten by the same git issues. I currently have to following (zsh syntax) setup for that:
git=(git -c core.hooksPath=/dev/null)
fsmonitor=$($git config core.fsmonitor)
if [[ -n $fsmonitor && $fsmonitor != true && $fsmonitor != false ]]; then
git+=(-c core.fsmonitor=false)
echo "Worrying git core.fsmonitor setting: $fsmonitor"
fi
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.
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?
modelines allow you to put a special comment in your file (typically on the first or last line of the file, and [for vim] of the format `# vim: set ts=2:`) to configure a subset of editor settings automatically whenever that file is opened in a buffer. They're very common, especially in codebases where there are lots of different styles in different files. Many editors (e.g., Zed (as of https://github.com/zed-industries/zed/pull/49267)) support vim and/or emacs's syntaxes for modelines.
Modelines were disabled by default for security reasons for a long time. It's kind of wild to me that they're enabled in some distributions, but there still isn't much restriction on what settings can be configured; I've never seen a modeline in the wild that did anything other than set `filetype`, `fileencoding`, `tabwidth`, `expandtab` (hard tabs vs spaces), and maybe `tabstop` / `softtabstop`.
They no doubt predate .editorconfig, but the problem as described is now better solved by .editorconfig, which can be used to configure directory and file specific configuration and works cross-editor too.
modelines are special lines you can put into files that sets vim options when the file is read by vim. Probably most commonly used to set tab space and tab width.
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.
RCE stands for Remote Code Execution: being able to trigger arbitrary code execution (ACE) from a remote machine.
This, however, is mislabelled: it’s not remote code execution at all, only local. It would only become RCE if there was some path to remotely triggering Vim to open the attack file, or Emacs the attack repository, or if a normal way of fetching a repository automatically set up and executed the hook.
The first one seems to indeed be a real RCE in vim.
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".
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.
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).
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.
> The first one seems to indeed be a real RCE in vim.
Barely, since there is little restriction as to what options modelines can set they should be largely considered equivalent to eval (if unintentionally). And generally they are which is why distros typically disable them by default.
IMHO in this day and age securemodelines should just be the default.
I don't know much about vim, but from the report it sounds like part of the issue was that disabling modelines would not prevent it:
> tabpanel is missing P_MLE
Unlike statusline and tabline, tabpanel is not marked with the P_MLE flag. This allows a modeline to inject %{...} expressions even when modelineexpr is disabled.
Edit: Upon re-reading the above I guess disabling modelineexpr is not the same as disabling modelines, and disabling modelines altogether might indeed prevent the issue.
But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.
If you don't trust git, you can remove from your system or configure emacs not to use it. If you are worried about unsuspecting people with both git and emacs getting into trouble when downloading and interacting with untrusted malware from the internet, the correct solution is to add better safeguards in git before executing hooks. But you did not report this to the git project (where even minor research beyond Claude Code would reveal to you that this has already been discussed in the git community).
I suspect that what happened here was that (1) you asked Claude to find RCEs in Emacs (2) Claude, always eager to please, told you that it indeed has found an RCE in Emacs and conjured up a convincing report with included PoC (3) since Claude told you it had found an RCE "in Emacs", you thought "success!", didn't think critically about it and simply submitted Claude's report to the Emacs project.
Had you instead asked Claude to find RCEs in git itself and it told you about git hooks, you probably would not have turned around and submitted vulnerability reports to all tools and editors that ever call a git command.
>But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.
That’s fair, but it would be pretty unusual for me to run Git commands in a directory I’m not actively working on. On the other hand, I open files from random folders all the time without really thinking about it, so that scenario feels much more realistic.
It’s extremely common for shell prompts to integrate Git status for the working directory.
Who’s responsible for the vulnerability? Your text editor? The version control system with a useful feature that also happens to be a vulnerability if run on a malicious repository? The thing you extracted the repository with? The thing you downloaded the malicious repository with?
Windows + NTFS has a solution, sometimes called the “mark of the web”: add a Zone.Identifier alternate data stream to files. And that’s the way you could mostly fix the vulnerability: a world where curl sets that on the downloaded file, tar propagates it to all of the extracted files, and Git ignores (and warns about) config and hooks in marked files. But figuring out where the boundaries of propagation lie would be tricky and sometimes controversial, and would break some people’s workflows.
If you untar a file and get a git repository, you should absolutely expect malicious behavior. No one does that, you clone repos not tarball them, and cloning doesn't copy hooks for precisely this reason
> 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.
Lack of accountability.
With other industries, when people aren't happy with their products, they ask for money back, they sue, they switch to the competition.
There are no EULA that assert removal of customer rights if the product is acquired.
Those kinds of bugs exist because no-one is accountable for quality like in other industries, unless it is on high integrity computing, or the cyber security laws that are finally coming into place across several countries.
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.
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.
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 does not require a 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.)
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.
Disclosure: I didn’t discover the bugs, but helped write the blog post.
These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not strictly RCE.
At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.
I'm pretty sure the lesson is that at the end of the day, it’s worth being aware of the risks of using git, as security issues intrinsic to git can extend to other tools which use git as a component.
I think we can agree that Git is at least partly responsible for this issue, if not more.
That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context.
This is why I think editor maintainers should do more to protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.
Please read the LLM output critically instead of doubling down on it.
Your defense-in-depth framing makes no sense. If .git/config or similar mechanisms are the attack vector, then adding more editor safeguards would be treating a symptom, as the real problem is git's trust model. The "users don't think about git when using editors" argument also proves too much. Many users also do not think about PATH, shell configs, dynamic linker, or their font renderer either, but you cannot make editors bulletproof against all transitive dependencies...
Seriously, it is actually backwards. Git is where the defense belongs, not every downstream tool that happens to invoke git. Asking editors to sandbox git's behavior is exactly as absurd as it sounds.
And BTW, "technically AV:L but feels like RCE" is your usual blog-post hype. It either is, or is not.
Sure, but you said that was the end of the day analysis, and I didn't think you went far enough in your analysis.
FWIW, I'm not thinking about git at all since I use Mercurial, and never enabled vc hooks in my emacs, which is based on 25.3.50.1, so wasn't affected by this exploit - I tested. I use git and hg only from the command-line.
My end-of-day analysis is to avoid git entirely if you can't trust its security model. ;)
Should the emacs developers also do more to secure emacs against ImageMagick exploits?
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.
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.
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.
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.
As for the Emacs thing, it feels utterly unfair to blame Emacs. The issue is 100% Git, and it’s unreasonable and undesirable for things like Emacs to try to put guard rails around parts of its functionality. Especially guard rails that may harm functionality. They were right to decline the suggested patch.
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 yet again”, 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?”
> We asked Claude to find a bug in Vim. It found an RCE. Just open a file, and you’re owned.
Yeah reading the above opening paragraph I was immediately going "oh Claude found out about modelines"
modelines are largely considered a (roundabout) equivalent to flat out eval, There's a reason plugins such as securemodelines exist:
https://www.vim.org/scripts/script.php?script_id=1876
Right. I am surprised to see this considered to be an RCE. Or a "mad bug" worthy of being here on HN. sighs.
Pretty sure a lot of people have spent lots of tokens into finding RCEs in vim and emacs, he is not the first person to do this.
Yup, I've had "nomodeline" in my vimrc for years. I used to add the "securemodelines" plugin https://www.vim.org/scripts/script.php?script_id=1876 but just recently removed that too (I think I may have ran into an annoyance after a vim update, and decided I never really use automatic modeline support anyway)
Those that have some git status information in their shell prompts should probably make sure they are not bitten by the same git issues. I currently have to following (zsh syntax) setup for that:
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.
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?
modelines allow you to put a special comment in your file (typically on the first or last line of the file, and [for vim] of the format `# vim: set ts=2:`) to configure a subset of editor settings automatically whenever that file is opened in a buffer. They're very common, especially in codebases where there are lots of different styles in different files. Many editors (e.g., Zed (as of https://github.com/zed-industries/zed/pull/49267)) support vim and/or emacs's syntaxes for modelines.
Modelines were disabled by default for security reasons for a long time. It's kind of wild to me that they're enabled in some distributions, but there still isn't much restriction on what settings can be configured; I've never seen a modeline in the wild that did anything other than set `filetype`, `fileencoding`, `tabwidth`, `expandtab` (hard tabs vs spaces), and maybe `tabstop` / `softtabstop`.
> I've never seen a modeline in the wild that did anything other than
Hence the securemodelines plugin
https://www.vim.org/scripts/script.php?script_id=1876
> if this is a class of bug that can be disabled via vim settings.
That is, as parent mentioned, if it's not done already by your distro or OS.They no doubt predate .editorconfig, but the problem as described is now better solved by .editorconfig, which can be used to configure directory and file specific configuration and works cross-editor too.
Struggling to find a source, but apparently modelines are disabled by default in debian and perhaps other common distros.
modelines are special lines you can put into files that sets vim options when the file is read by vim. Probably most commonly used to set tab space and tab width.
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.
> shouldn't be that many lines of code, something doable, like in couple thousands
If you believe that then you have hardly scratched the surface of what your editor is capable of doing.
What does RCE mean?
RCE stands for Remote Code Execution: being able to trigger arbitrary code execution (ACE) from a remote machine.
This, however, is mislabelled: it’s not remote code execution at all, only local. It would only become RCE if there was some path to remotely triggering Vim to open the attack file, or Emacs the attack repository, or if a normal way of fetching a repository automatically set up and executed the hook.
Remote Code Execution, which this isn't, in both cases.
It is code execution.
Remote code execution - aka they can run arbitrary code on the compromised machine via the bug.
Basically the worst possible thing.
The first one seems to indeed be a real RCE in vim.
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".
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.
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).
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.
> The first one seems to indeed be a real RCE in vim.
Barely, since there is little restriction as to what options modelines can set they should be largely considered equivalent to eval (if unintentionally). And generally they are which is why distros typically disable them by default.
IMHO in this day and age securemodelines should just be the default.
https://www.vim.org/scripts/script.php?script_id=1876
I don't know much about vim, but from the report it sounds like part of the issue was that disabling modelines would not prevent it:
> tabpanel is missing P_MLE Unlike statusline and tabline, tabpanel is not marked with the P_MLE flag. This allows a modeline to inject %{...} expressions even when modelineexpr is disabled.
Edit: Upon re-reading the above I guess disabling modelineexpr is not the same as disabling modelines, and disabling modelines altogether might indeed prevent the issue.
When I wget a tarball, unzip, and emacs a.txt inside, I don't expect that it'd execute arbitrary commands.
I think people should be aware of this risk, especially when it looks like it's not getting fixed.
Disclosure: I didn't find the bugs. I helped wrote the blog post.
But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.
If you don't trust git, you can remove from your system or configure emacs not to use it. If you are worried about unsuspecting people with both git and emacs getting into trouble when downloading and interacting with untrusted malware from the internet, the correct solution is to add better safeguards in git before executing hooks. But you did not report this to the git project (where even minor research beyond Claude Code would reveal to you that this has already been discussed in the git community).
I suspect that what happened here was that (1) you asked Claude to find RCEs in Emacs (2) Claude, always eager to please, told you that it indeed has found an RCE in Emacs and conjured up a convincing report with included PoC (3) since Claude told you it had found an RCE "in Emacs", you thought "success!", didn't think critically about it and simply submitted Claude's report to the Emacs project.
Had you instead asked Claude to find RCEs in git itself and it told you about git hooks, you probably would not have turned around and submitted vulnerability reports to all tools and editors that ever call a git command.
>But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.
That’s fair, but it would be pretty unusual for me to run Git commands in a directory I’m not actively working on. On the other hand, I open files from random folders all the time without really thinking about it, so that scenario feels much more realistic.
It’s extremely common for shell prompts to integrate Git status for the working directory.
Who’s responsible for the vulnerability? Your text editor? The version control system with a useful feature that also happens to be a vulnerability if run on a malicious repository? The thing you extracted the repository with? The thing you downloaded the malicious repository with?
Windows + NTFS has a solution, sometimes called the “mark of the web”: add a Zone.Identifier alternate data stream to files. And that’s the way you could mostly fix the vulnerability: a world where curl sets that on the downloaded file, tar propagates it to all of the extracted files, and Git ignores (and warns about) config and hooks in marked files. But figuring out where the boundaries of propagation lie would be tricky and sometimes controversial, and would break some people’s workflows.
If you untar a file and get a git repository, you should absolutely expect malicious behavior. No one does that, you clone repos not tarball them, and cloning doesn't copy hooks for precisely this reason
I don't think this is fair, as it will likely also affect any editor with Git integration (or not?)
Yes, likely. And git is not going to fix it. So isn't it fair to expect the editor maintainers to do something about it, to protect their users, no?
Tested with zed and vscode. They don't seem to have the issue. Probably due to "Restricted Access" mode when opening new folder?
Edit: yeah pwned when clicking the big green trust button
No
[dead]
tldr
> 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.
Lack of accountability.
With other industries, when people aren't happy with their products, they ask for money back, they sue, they switch to the competition.
There are no EULA that assert removal of customer rights if the product is acquired.
I don’t understand the connection to the post, could you elaborate?
Those kinds of bugs exist because no-one is accountable for quality like in other industries, unless it is on high integrity computing, or the cyber security laws that are finally coming into place across several countries.
The FSF will give you a full refund for Emacs if you’re not satisfied.
We get what we pay for, as for FSF.
https://fsfe.org/news/2025/news-20251218-01.en.html