CVE-2026-71267

The CVSS 9.8 rating here obscures a more nuanced picture. This is a buffer overflow in microtar's filename handling, where the library accepts arbitrarily long filenames but the tar header structure reserves only 100 bytes for the name field. The root cause isn't simply a missing strlen check—it's a library design that chose not to implement the ustar long-name extension (the standard mechanism for filenames exceeding 100 bytes). That creates a fundamental tension: truncate and corrupt archives silently, reject valid use cases, or invest in proper long-name support. The API itself is the ergonomic trap. The function `mtar_write_file_header(const char* name)` exposes no length parameter, no documented limit, and no companion function to query the maximum. A developer passing a string has no friction at the call site to make them think about bounds. The vulnerability lives in the interface design, not just the strcpy call inside. The EPSS score of 0.0034 sits in stark contrast to the 9.8 severity—this gap is worth interrogating. CVSS models worst-case potential; EPSS models current exploitation activity. The low score suggests this isn't being actively exploited today, but that reflects deployment patterns, not blast radius. The more important question is whether microtar operates at a trust boundary where attacker-controlled filenames reach it: build systems processing external dependencies, backup infrastructure archiving user uploads, or CI/CD pipelines extracting from external sources. In those contexts, exploitation probability may be low but impact is high. One complicating factor: available evidence suggests microtar may be unmaintained. If no maintainer will implement the proper fix (uster long-name support), the 9.8 becomes a theoretical severity on abandoned code. Downstream projects face a choice between local forks with the architectural fix, or accepting that the vulnerability will persist indefinitely. Prioritize understanding whether this library sits in a trust boundary in your environment—and if so, plan for a local fix rather than waiting for an upstream patch.

Reviewed through automated stages and approved by a human before publication.