Vim 9.2.0074 Patch Fixes Emacs Tags Parsing Heap Overflow CVE-2026-28418

A heap-based buffer overflow in Vim’s Emacs-style tags parsing (tracked as CVE-2026-28418) has been disclosed and patched: users should update to Vim 9.2.0074 or later immediately to eliminate a crash-inducing out-of-bounds read that can be triggered by a crafted tags file. (github.com)

Background​

Vim remains one of the most widely used terminal text editors across developer workstations, build systems, and remote shells. One long-standing convenience feature is support for tags files (ctags/Etags), which let editors quickly jump to symbol definitions across a codebase. Vim implements both Exuberant/Universal ctags formats and an Emacs-style tags format; the latter is less common but supported for interoperability. The recent vulnerability is specifically in the Emacs-style tags parsing path. (github.com)
Tags files are typically created inside a repository (or published artifact) and are often consumed automatically by editors or by project-specific tooling. That integration is what makes a tags parsing bug notable: a tagged repository or a project artifact containing a malicious tags file can be a delivery vector if a user opens or performs a tag lookup against it. (github.com)

---

What the vulnerability is — technical summary​

• Vulnerability: Heap-based buffer overflow manifested as an out-of-bounds read.
• Affected code path: Emacs-style tags parsing, specifically the function emacs_tags_new_filename() in src/tag.c.
• Root cause: The parser reads a subsequent line from the tags file into a fixed-size heap buffer (512 bytes), then searches for a comma delimiter to split filename and metadata. If the line exceeds the buffer and contains no comma, the search loop can run past the end of the buffer and the code proceeds as if it had found the comma — then it reads memory beyond the allocation by up to 7 bytes. This produces an out-of-bounds heap read and can cause a crash. (github.com)

The GitHub security advisory provides the high-level narrative and the affected function name; the upstream Git commit (patch 9.2.0074) demonstrates the fix: an explicit check for the buffer end was added and the function returns early if the delimiter is not found, preventing the subsequent out-of-bounds access. The commit also adds a test case that reproduces the previous crash condition. (github.com)

---

Why this matters (impact analysis)​

On the surface this CVE is a read-only heap overflow (an out-of-bounds read), not a write-into-adjacent-memory corruption. The practical impacts are therefore more limited than classic remote code execution bugs, but still meaningful:

• Crash / Denial-of-Service: An attacker who can influence which tags file a user’s Vim instance loads can trigger a crash during a tag lookup operation. This is the primary confirmed impact and the reason the patch was issued. (github.com)
• Information disclosure risk (theoretical): Although the current advisory classifies the issue as an out-of-bounds read — which could leak a small number of bytes beyond the buffer — exploiting such a leak to obtain useful secrets from a modern process heap is non-trivial due to address space layout randomization (ASLR), memory protections, and typical allocation patterns. Nevertheless, read-only over-reads can sometimes be chained into leaks in complex scenarios; a cautious stance is warranted if an attacker can also control other variables.
• Attack vector and required conditions: The vulnerability is local in the sense that it requires Vim to open and parse a crafted tags file; the CVSS vector assigned in public listings reflects Local attack vector and user interaction required (a user must perform the tag lookup). This limits mass remote exploitation but does not eliminate risk for developers who open untrusted repositories, build artifacts, or mounted network shares containing tags files. (github.com)

Public vulnerability trackers and the NVD list the severity as medium (CVSS 3.x vector available in advisory listings), largely because the exploit requires user interaction and is not a write-based arbitrary memory corruption. That said, the presence of a heap out-of-bounds operation in widely used code is always worth attention and swift patching. (github.com)

---

How the issue was discovered and fixed​

The vulnerability was reported to the Vim project by community researchers (GitHub users credited in the advisory). The project accepted the report and issued a targeted patch in the 9.2.0074 release series. The fix is concise and defensive: after reading a line into the buffer the parser now checks whether the search loop actually reached a comma delimiter; if not, it returns early rather than assuming the comma exists and proceeding to read bytes after the buffer. A unit test was added to avoid regressions, which writes a deliberately long line and asserts that the previous failure (a crash) no longer occurs. (github.com)
This is a textbook example of a small but critical correctness check being omitted earlier and then restored once the out-of-bounds condition was demonstrated. The patch is minimal, which is good: it reduces the chance of introducing side-effects while resolving the root cause directly. (github.com)

---

Verification and cross-references​

Key claims in public advisories are cross-checked against multiple authoritative sources:

• The Vim project’s official GitHub security advisory documents the vulnerability, the affected versions, the patched release (9.2.0074), the vulnerable function, and the CVSS/impact summary. (github.com)
• The upstream commit that implements the patch (commit f6a7f46) shows the changed lines in src/tag.c, the added test in src/testdir/test_taglist.vim, and the bump of included patches. That commit message explicitly states the problem and the defensive solution. (github.com)
• The NVD entry and OSV/other trackers mirror the advisory content and publish the CVE record and metadata, providing additional confirmation of dates and the essence of the flaw.

Where public trackers lack rich context (e.g., they don’t always include code diffs), the GitHub commit and advisory supply the definitive technical detail. The convergence of the advisory, patch commit, and NVD/CVE records provides high confidence in the factual claims: the bug exists, it was patched in 9.2.0074, it’s a heap-based out-of-bounds read tied to Emacs tags parsing, and it can crash Vim when presented with a crafted tags file. (github.com)

---

Exploitability: realistic scenarios and threat models​

Because the attacker needs to place a malicious tags file where a target will read it, the most realistic threat scenarios are targeted rather than indiscriminate:

• Malicious repository or archive: A repository hosted on a code-sharing service or included as a dependency that contains a crafted tags file could trigger the bug when a developer opens the repository and invokes a tag lookup. This is particularly plausible for developers who fetch and explore unknown repositories or quickly open project roots in their editor without review. (github.com)
• Shared network storage: A shared mount or developer share with a malicious tags file could deliver the payload when files are browsed in Vim on a workstation or CI host. (github.com)
• Supply-chain artifacts: Build artifacts or zipped source archives that include tags files may be an indirect vector if the artifact is used locally in a way that makes Vim parse tags. (github.com)

Practical exploitation as a data exfiltration or code-execution primitive is unlikely with the reported behavior alone: the advisory and patch context make clear the immediate impact is crash (denial-of-service) and a small out-of-bounds read. However, defenders should not dismiss the theoretical risk that an out-of-bounds read could be combined with other faults or environment-specific behaviors to increase impact. For example, in older environments or non-standard memory allocator setups, even read overflows can become more consequential. For these reasons the fix was prioritized and labeled with moderate severity. (github.com)

---

Recommended immediate actions (for users and administrators)​

• Update immediately:
• If you run system packages, check your distribution’s package manager and install the updated Vim package that includes patch 9.2.0074 or newer.
• If you use the upstream binaries or build from source, download the Vim source with included patch 9.2.0074 and rebuild, or install the upstream release that contains the patch. (github.com)
• Verify: After update, confirm with vim --version (or your platform’s package query) that the included patches list contains 74 (or higher). The upstream patch increments the included_patches array to include 74. (github.com)
• Avoid opening untrusted repositories: Until systems are patched, treat repos and archives from untrusted sources with caution—especially if they contain an ETAGS/TAGS file or a file named tags that could be interpreted as Emacs-style tags.
• Sanitize toolchains and CI: If your CI or build systems run automated tag lookups (or tools that parse tags files), ensure those systems are updated or that tags parsing is disabled/isolated until patched versions are installed.
• Use sandboxing: For high-risk workflows where developers open third-party projects frequently, consider running editors inside sandboxed containers, firejail, or restricted VMs to limit the blast radius of crashes or other impacts.

These steps reflect a defense-in-depth approach: patch first, then minimize exposure vectors and add runtime restrictions where practical. (github.com)

---

How to check whether you’re vulnerable​

• Check the Vim version/patch level: Run vim --version and look for the included patches list. If 74 (or more recent) is listed under included patches for your Vim 9.2 branch, you have the fix. The patch was added to the included_patches array in src/version.c in the commit. (github.com)
• Inspect tags files in repositories you’ve recently opened: Look for unusually long lines or a tags file that appears to be in Emacs format (\f form-feed separators, etc.). If you suspect a tags file, avoid interacting with it with an unpatched Vim. (github.com)

---

Longer-term mitigations and hardening​

Beyond the immediate patch, projects and system administrators should adopt policies and practices to reduce the attack surface for malformed metadata and auxiliary files:

• Limit automatic parsing of metadata files: Editors and tooling that automatically process repository metadata (tags, ccache, prebuilt indexes) should avoid automatic parsing of untrusted content, or should require explicit user consent before processing.
• Enforce package signing and provenance: Code repositories, tarballs, and artifacts should be consumed from trusted sources and where possible verified via signatures or trusted provenance mechanisms.
• Use sandboxing for dev tools: Developers who routinely test or inspect untrusted code should use containerized editor sessions or ephemeral virtual machines to isolate editor crashes and limit access to sensitive credentials or project resources.
• Build-time hardening: When compiling editors or other user-space tools, enable standard hardening flags (FORTIFY_SOURCE, stack protection where applicable, ASLR-friendly linker settings) to make exploitation of memory-corruption vulnerabilities harder in the future.
• Fuzzing and regression tests: The presence of test additions in the patch highlights the value of automated tests and fuzzers focused on file-parsing code paths. Projects should invest in fuzzing tags/metadata parsers to catch boundary conditions early. (github.com)

---

Related CVEs and context​

At the same time the Vim project addressed this out-of-bounds read, other edge cases in Emacs tags parsing were flagged in adjacent CVEs, including a heap-based buffer underflow (CVE-2026-28419) that affects a different parsing function and is fixed in an immediately subsequent patch release. Administrators should review related advisories and apply all relevant patches (9.2.0074 for CVE-2026-28418; 9.2.0075 and later for other tag-related fixes) rather than applying only a single patch. Cross-referencing related advisories is a good practice to avoid being caught by a nearby but distinct issue.

---

What the patch shows about secure maintenance​

The fix is instructive for maintainers: a small guard check can eliminate an out-of-bounds access and a focused regression test ensures the condition remains covered. The patch demonstrates the healthy security posture of a mature open-source project:

• Timely acknowledgement and patching: The report was accepted and a specific patch released.
• Minimal, targeted remediation: The change adds a correct boundary check and returns early, which is the least risky fix consistent with functional correctness.
• Test coverage: Adding a unit test for the failure mode reduces the risk of regressions and is a best practice for parser code — which is often where subtle boundary bugs hide. (github.com)

---

Final assessment and guidance​

CVE-2026-28418 is a real but limited-risk vulnerability: a heap-based out-of-bounds read in Emacs-style tags parsing that can crash Vim and in theory leak a few bytes of heap memory. Its exploitability is constrained by user interaction and the need for the target to open or run a tag lookup against a malicious tags file, which makes mass exploitation unlikely. Still, because the bug affects a ubiquitous editor used by a wide swath of developers, the maintainers released a concise patch (Vim 9.2.0074) and added tests — a clear signal that users should update promptly. (github.com)
Action checklist:

• If you or your team use Vim, update to version 9.2.0074 or newer as your first step. (github.com)
• Audit workflows that open or parse tags files from external sources and add explicit gating or sandboxing where appropriate. (github.com)
• Apply related patches (for example, adjacent fixes in 9.2.0075) to ensure comprehensive coverage of tag-parsing issues.

Memory-safety issues in file parsers are among the most common sources of software vulnerabilities. The right response combines prompt patching, cautious handling of untrusted inputs, and the sort of small but effective defensive coding demonstrated by the Vim team in this fix.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center