Claude Code Found Real Zero-Days in Vim and GNU Emacs. Here’s What the Prompt Did
In 2026, Claude Code helped uncover zero-day Remote Code Execution (RCE) flaws in Vim and GNU Emacs from very simple prompts. That is the part that should grab your attention. The prompt was not a long red-team playbook. It was closer to a casual instruction: there may be an RCE when you open a file, find it. And Claude found one.
If you write code, manage endpoints, or just open random files a little too confidently, this story matters. It shows how quickly AI can move from a rumor, to code review, to a proof of concept.
What happened
According to reporting by CSO Online, researcher Hung Nguyen of AI red teaming company Calif used Anthropic's Claude Code to investigate rumored bugs in two old, widely used editors: Vim and GNU Emacs.
The result was not vague theory.
- Claude Code found a Vim issue in about two minutes
- It then moved toward an exploit path
- Nguyen later tried a similar idea against GNU Emacs
- Claude surfaced a related arbitrary code execution path there too
That speed is the real story. You are looking at a workflow where simple natural-language prompts can shorten the time from suspicion to exploit research.
The exact Vim prompt that kicked this off
The prompt that started the Vim investigation was simple:
“Somebody told me there is an RCE 0-day when you open a file. Find it.”
That was enough for Claude Code to start auditing relevant code paths. Within minutes, it reportedly identified missing security checks introduced in 2025.
The missing checks included:
- Missing P_MLE and P_SECURE checks in the tabpanel sidebar
- A missing security check in the autocmd_add() function
Those gaps mattered because they opened a path where a crafted file could trigger behavior that should have been blocked.
How the Vim zero-day worked
The impact described by the Vim maintainers was serious. If an attacker could get a victim to open a malicious file, arbitrary command execution could happen with the privileges of the user running Vim.
In plain English, that means this is not just a crash bug or a weird editor glitch.
It means:
- An attacker delivers a crafted file
- You open it in Vim
- Code runs as your user account
- No extra clicks are required after opening the file
That is why this class of bug is so dangerous. People trust text files. They should. Usually.
Vim fix status: patched as CVE-2026-34714
The good news is that Vim fixed its issue quickly.
Here are the key details:
- CVE: CVE-2026-34714
- CVSS score: 9.2
- Fixed in: Vim 9.2.0272
If your systems rely on Vim, patching is the obvious step. If you maintain developer workstations, build runners, or jump boxes, this should not sit in a backlog.
GNU Emacs had a similar problem, but the response was different
After the Vim result, Nguyen reportedly joked that Claude Code should find the same kind of issue in GNU Emacs.
It found something close.
The Emacs issue appears tied to how Emacs interacts with Git, and the vulnerable behavior goes back to 2018. The most severe version of the finding reportedly needed no file-local variables at all. In the worst case, simply opening any file inside a directory containing a crafted .git/ folder could execute attacker-controlled commands.
That is a rough sentence to read if you use source trees from untrusted places.
Why the Emacs finding is especially uncomfortable
A lot of security bugs sound bad until you read the user interaction requirements. Then the risk drops because the attacker needs many steps, extra confirmations, or strange setup.
That is not what makes this case troubling.
According to Nguyen's description:
- Many cases require only opening a file
- The most severe case does not rely on file-local variables
- A crafted directory with a malicious .git setup may be enough
That means the exploit path can hide inside a workflow many developers treat as normal. Clone, extract, open, inspect. Nothing about that feels suspicious when you are moving fast.
Emacs fix status: still messy
Unlike Vim, the GNU Emacs case was not cleanly resolved at the time of the article.
Known details:
- No CVE identifier yet
- Affected versions reportedly include 30.2 and 31.0.50
- Emacs maintainers reportedly viewed this as a Git problem
- They declined to address the issue directly
- Nguyen pointed readers to manual mitigations in his own write-up
That kind of response creates confusion for users. If one project says the root cause belongs to another project, your practical question stays the same: what do I need to change right now to stay safe?
What the prompt really did
The headline makes it sound like the prompt itself was magic. It was not. The prompt acted more like a starting pistol.
What it did was:
- Point Claude Code at a likely bug class
- Ask it to inspect code paths around file-open behavior
- Let it reason through missing checks and unsafe execution flow
- Push it toward exploit development once a candidate bug appeared
So the prompt mattered because it was minimal, not because it was clever. That is the unsettling part. You did not need pages of instructions. You needed a hint and a capable model.
Why this matters beyond Vim and Emacs
The deeper lesson is not really about editors. It is about old codebases and the shrinking gap between bug discovery and exploit development.
Legacy software often has:
- Deep feature sets
- Edge-case behavior built up over years
- Security assumptions that predate modern threat models
- Hard-to-review interactions across plugins, shell calls, file handlers, and helper tools
Those are perfect conditions for AI-assisted auditing.
Anthropic had already said in February that its Opus 4.6 model helped identify 500 high-severity security vulnerabilities. This new case adds something more concrete for everyday readers: a familiar pair of editors, a very short prompt, and real impact.
The new security problem: AI can help defenders and attackers
There are two truths here.
First, this is useful for defenders. Security teams can use models to review code, test assumptions, and speed up triage.
Second, it is also useful for attackers. A tool that can spot weak checks, iterate on exploit ideas, and draft proof-of-concept code lowers the effort needed to weaponize mistakes.
That is why this story feels bigger than one CVE.
It suggests a near future where:
- More bugs are found faster
- Public disclosure pressure increases
- Patch windows feel shorter
- Security teams need stronger prevention and containment, not just detection
In other words, waiting around for the CVE feed is not a full strategy anymore.
What you should do right now
If you own endpoints, developer laptops, or CI systems, keep this practical.
For Vim users
- Upgrade to Vim 9.2.0272 or later
- Treat untrusted files as risky, even plain text files
- Review editor sandbox and shell-invoking features in your environment
For Emacs users
- Be careful opening files from untrusted repositories or extracted archives
- Pay attention to directories containing suspicious .git structures
- Follow any manual mitigations published by the researcher or your distro maintainers
- Test whether local hardening, sandboxing, or execution restrictions can reduce impact
For security teams
- Add editor and developer-tool risk to endpoint threat models
- Patch productivity tools with the same urgency as server software when RCE is involved
- Assume AI will speed up both discovery and exploitation
- Invest in containment controls so one opened file does not become full compromise
My take
The most striking thing here is not that Claude found bugs. Good tools help people find bugs. That part makes sense.
The striking part is how little setup it took to get useful results. A rumor-like prompt turned into a real security finding in software millions of people know by name. If that does not change how you think about secure coding and patch speed in 2026, it probably should.
FAQ
Did Claude Code really find zero-days in Vim and GNU Emacs?
Yes, based on the cited reporting, researcher Hung Nguyen used Claude Code to uncover real zero-day style RCE flaws affecting Vim and GNU Emacs. The Vim issue was assigned CVE-2026-34714 and patched. The Emacs issue had no CVE yet at the time of reporting.
What prompt did Claude Code use to find the Vim bug?
The reported prompt was: “Somebody told me there is an RCE 0-day when you open a file. Find it.” That simple prompt directed Claude Code to inspect file-open related logic and identify missing security checks.
Is the Vim zero-day fixed?
Yes. The Vim issue was fixed in Vim 9.2.0272. It is tracked as CVE-2026-34714 with a CVSS score of 9.2.
Is GNU Emacs still vulnerable?
As of the reporting summarized here, GNU Emacs did not have a direct fix or a CVE assigned. The issue reportedly affected 30.2 and 31.0.50, and maintainers viewed it as related to Git rather than fixing it inside Emacs.
Can opening a file really trigger remote code execution?
Yes. In these reported cases, the dangerous condition was that opening a crafted file, or opening a file inside a specially prepared directory, could trigger arbitrary command execution with little or no further user interaction.
Why is this such a big deal for software security?
Because it shows how AI-assisted code review can speed up the path from a vague suspicion to a working exploit idea. That changes the tempo of vulnerability discovery, disclosure, and patching for old and modern software alike.
Final thought
If you still think of text editors as harmless tools, this story is a reminder that they are also complex software with deep hooks into your system. And now, thanks to tools like Claude Code, those deep hooks are easier to inspect than ever.