Vulnerabilities in the Vim and GNU Emacs text editors, discovered using simple prompts with the Claude assistant, allow remote code execution simply by opening a file.

The assistant also created multiple versions of proof-of-concept (PoC) exploits, refined them, and provided suggestions to address the security issues.

Vim and GNU Emacs are programmable text editors primarily used by developers and sysadmins for code editing, terminal-based workflows, and scripting. Vim in particular is widely used in DevOps, and is installed by default on most Linux server distributions, embedded systems, and macOS.

Vim flaw and fix

Hung Nguyen, a researcher at the boutique cybersecurity firm Calif, which specializes in AI red teaming and security engineering, found the issues in Vim after instructing Claude to find a remote code execution (RCE) zero-day vulnerability in the text editor triggered by opening a file.

The Claude assistant analyzed Vim’s source code and identified missing security checks and issues in modeline handling, allowing code embedded in a file to be executed upon opening.

A modeline is text placed at the beginning of a file that instructs Vim how to handle it.

Even if the code was supposed to run in a sandbox, another problem allowed it to bypass the restriction and execute commands in the context of the current user.

The vulnerability has not received a CVE ID and affects all versions of Vim 9.2.0271 and earlier.

Nguyen reported the issue to the Vim maintainers, who promptly released a patch in Vim version 9.2.0272. The Vim team noted that a victim would only need to open a specially crafted file to trigger the vulnerability.

“An attacker who can deliver a crafted file to a victim achieves arbitrary command execution with the privileges of the user running Vim,” reads the bulletin.

GNU Emacs points to Git

In the case of GNU Emacs, the vulnerability remains present, as the developer considers it Git’s responsibility to address.

The problem stems from GNU Emacs’ version control integration (vc-git), where opening a file triggers Git operations via vc-refresh-state, which causes Git to read the .git/config file and run a user-defined core.fsmonitor program, which can be abused to run arbitrary commands.

An attack scenario devised by the researcher involves creating an archive (e.g., an email or a shared drive) that contains a hidden .git/ directory with a config file pointing to an executable script.

When the victim extracts the archive and opens the text file, the payload executes without any visible indicators on the GNU Emacs default configuration.

GNU Emacs maintainers consider this a problem in Git, not the text editor, because the environment is merely the trigger for the dangerous action executed by Git: reading the attacker-controlled config and executing a program from it.

While this argument is technically correct, since nothing is executed in GNU Emacs directly, the risk to the user exists since the editor is automatically running Git on untrusted directories without neutralizing dangerous options and without requiring user consent, or sanbox protections.

Nguyen suggested that GNU Emacs could modify Git calls to explicitly block ‘core.fsmonitor,’ so any dangerous scripts/payloads wouldn’t be executed automatically  when opening a file.

As the flaw remains unpatched in the latest version of GNU Emacs, users are advised to exercise caution when opening files from unknown sources or downloaded online.