Developers can spend days using fuzzing tools to find security weaknesses in code. Alternatively, they can simply ask an LLM to do the job for them in seconds.
The catch: LLMs are evolving so rapidly that this convenience might come with hidden dangers.
The latest example is from researcher Hung Nguyen from AI red teaming company Calif, who, with simple prompts to Anthropic’s Claude Code, was able to uncover zero-day remote code exploits (RCEs) in the source code of two of the most popular developer text editors, Vim and GNU Emacs.
Nguyen started with Vim. “Somebody told me there is an RCE 0-day when you open a file. Find it,” he instructed Claude Code.
Within two minutes, Claude Code had discovered the flaw: missing critical security checks (P_MLE and P_SECURE) in the tabpanel sidebar introduced in 2025, and a missing security check in the autocmd_add() function.
Claude Code then helpfully tried to find ways to exploit the vulnerability, eventually suggesting a tactic that bypassed the Vim sandbox by persuading a target to open a malicious file. It had gone from prompt to proof-of-concept (PoC) exploit in minutes.
“An attacker who can deliver a crafted file to a victim achieves arbitrary command execution with the privileges of the user running Vim,” Vim maintainers noted in their security advisory. “The attack requires only that the victim opens the file; no further interaction is needed.”
GNU Emacs ‘forever-day’
Surprised, Nguyen then jokingly suggested Claude Code find the same type of flaw in a second text editor, GNU Emacs.
Claude Code obliged, finding a zero-day vulnerability, dating back to 2018, in the way the program interacts with the Git version control system that would make it possible to execute malicious code simply by opening a file.
“Opening a file in GNU Emacs can trigger arbitrary code execution through version control (git), most requiring zero user interaction beyond the file open itself. The most severe finding requires no file-local variables at all — simply opening any file inside a directory containing a crafted .git/ folder executes attacker-controlled commands,” he wrote.
One fixed, one not
When notified, Vim’s maintainers quickly fixed their issue, identified as CVE-2026-34714 with a CVSS score of 9.2, in version 9.2.0272.
Unfortunately, addressing the GNU Emacs vulnerability, which is currently without a CVE identifier, isn’t as straightforward. Its maintainers believe it to be a problem with Git, and declined to address the issue; in his post, Nguyen suggests manual mitigations. The vulnerable versions are 30.2 (stable release) and 31.0.50 (development).
Vulnerable code
What does the discovery of these flaws tell us? Clearly, that large numbers of old codebases are potentially vulnerable to the power of AI tools such as Claude Code. Just because a weakness hasn’t been noticed for years doesn’t mean it will hide for long in the AI era.
That is, potentially, a big change, although hardly one that hasn’t already been flagged by Anthropic itself. In February, the company revealed that its Opus 4.6 model had been used to identify 500 high-severity security vulnerabilities.
“AI language models are already capable of identifying novel vulnerabilities, and may soon exceed the speed and scale of even expert human researchers,” it said at the time.
The platform is powerful enough that an enterprise version with the same capabilities, Claude Code Security, even negatively affected stock market sentiment towards several traditional cybersecurity companies when it was launched.
A second issue is that LLMs are now capable of spotting, iterating, and creating PoCs for vulnerabilities in ways developers still need to come to terms with. Meanwhile, the potential for malicious use is hard to ignore.
“How do we professional bug hunters make sense of this?” Nguyen asked. “This feels like the early 2000s. Back then a kid could hack anything, with SQL Injection. Now [they can] with Claude.”
This article originally appeared on CSOonline.
SOCIAL SHARE CARD GENERATOR