rxi microtar CVE-2026-54417

The target application must use rxi microtar to parse a tar archive supplied by or derived from attacker-controlled input - for example, a user-uploaded file, a downloaded package, or a network-received archive. The attacker must be able to craft a tar header whose size field is a multiple of 512 in the range 0xFFFFFC01-0xFFFFFE00 (e.g., 0xFFFFFE00 = 4,294,966,784 bytes), which is a precise but mechanically straightforward requirement. No authentication is required per CVSS PR:N, and no user interaction is required per CVSS UI:N, assuming archive processing is performed server-side or programmatically. Exploitation is limited to environments where: (1) the rxi microtar library is linked into the application, (2) archive parsing runs synchronously on a thread without a CPU-time or iteration-count watchdog, and (3) the application does not perform pre-validation of tar header size fields before passing archives to the library. Environments that process archives in isolated subprocesses with CPU limits or that validate header fields before parsing are not vulnerable to process hang.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) reflects a remotely triggerable, low-complexity availability-only flaw, which is accurate given the unauthenticated network delivery path and deterministic infinite-loop outcome. However, the EPSS score of 0.42% (33rd percentile) and SSVC Automatable:none together indicate that automated, at-scale exploitation is not currently occurring or expected imminently - likely because the attack is contingent on delivering a crafted archive through an application-specific ingestion channel rather than a universally open socket. The SSVC Technical Impact:total reflects the complete loss of availability when triggered, consistent with an unrecoverable process hang. The absence of a CISA KEV listing and low EPSS corroborate that this is a credible but not presently widespread threat. The primary real-world risk lies in applications that accept tar archives from untrusted parties (e.g., user-uploaded files, network-retrieved packages) and process them synchronously without timeout controls. Note: SSVC Automatable:none appears conservative given the straightforward crafted-input vector; defenders should not rely solely on that signal.

An attacker uploads or delivers a specially crafted tar archive containing a header with the size field set to 0xFFFFFE00 (or another qualifying multiple of 512) to any service that uses microtar to iterate archive entries - such as a file upload endpoint, a package manager, or a build tool. When the target application calls mtar_find() or manually loops with mtar_next(), the function seeks to offset zero relative to the current record on every iteration, repeating indefinitely. The process consumes 100% of one CPU core and becomes unresponsive until killed externally, achieving denial of service with a single malformed archive submission.