Vim bug lets attackers run commands when a user opens a crafted file

A newly disclosed Vim vulnerability can let an attacker run arbitrary operating system commands if a target opens a malicious file in a vulnerable version of the editor. The Vim project’s GitHub advisory rates the issue High severity and says the bug chain affects Vim versions before 9.2.0272.

The flaw relies on two problems working together. First, the tabpanel option can process a modeline expression when it should not. Second, autocmd_add() lacked a security check, which let sandboxed code register an autocommand that ran after the sandbox exited.

That combination means a victim does not need to click a link or enable an unusual setting. GitHub’s advisory says the attack only requires the victim to open a crafted file, and it runs with the privileges of the user running Vim.

How the Vim exploit chain works

According to the advisory, the tabpanel option accepts %{expr} format strings in the same way as statusline and tabline. The problem is that tabpanel was missing the P_MLE flag, so Vim did not enforce the usual modelineexpr guard before accepting expression strings from a modeline.

Vim still tried to limit the danger by evaluating the expression inside its sandbox. That should have blocked risky behavior, but the second issue broke that protection. The advisory says autocmd_add() had no check_secure() call, so code inside the sandbox could register an autocommand that fired later, after the sandbox had already closed.

In plain terms, the crafted file used the modeline to plant code, then used the missing security check to delay the dangerous part until the safety boundary disappeared. That is why the issue results in command execution rather than a more limited script bug.

Why the default risk is significant

The advisory says modeline is enabled by default, and the exploit does not require modelineexpr to be enabled. It also says builds with +tabpanel, described there as the default FEAT_HUGE build, are affected.

That makes the attack surface broader than many editor bugs. A user may believe they are safe because they did not turn on advanced expression handling in modelines, yet the advisory says this chain bypasses that expectation because the missing P_MLE flag kept the normal check from running.

The impact is serious, but the attack still needs user interaction in one sense. GitHub’s CVSS vector marks user interaction as required because the victim must open the malicious file. Once that happens, though, no extra clicks or approvals are needed.

Vim vulnerability summary

What Vim changed to fix it

The fixing commit from Vim maintainer Christian Brabandt states the problem clearly: “tabpanel can be set in a modeline.” The same commit says the solution was to add the P_MLE flag to tabpanel and disable autocmd_add() and autocmd_delete() in restricted or secure mode.

The commit diff shows both changes. In src/optiondefs.h, Vim added P_MLE to the tabpanel option definition. In src/autocmd.c, Vim added a guard that returns when check_restricted() or check_secure() is true.

GitHub’s advisory also points users to patch v9.2.0272 as the fix. The project tagged that release on March 30, 2026.

What users and admins should do now

The first step is simple: update Vim to version 9.2.0272 or later. That is the patched release named in the project’s advisory and commit trail.

If you cannot patch immediately, treat untrusted files as risky and consider disabling modelines as a temporary mitigation. The advisory does not list a temporary workaround in detail, but its description makes clear that the exploit begins when Vim parses modeline content from a crafted file.

Security teams should also review developer workstations, build hosts, and shared Linux systems where Vim may still come from distro packages that lag upstream. The vulnerability runs with the privileges of the current user, so the real impact depends on where that user account sits and what it can access.

Immediate actions

• Update Vim to 9.2.0272 or later
• Avoid opening untrusted files in vulnerable builds
• Consider temporarily disabling modelines until patching completes
• Review package manager versions on shared systems
• Flag older Vim installs in internal vulnerability tracking

FAQ