Skip to main content

rxi microtar CVE-2026-54417

HIGH
Integer Overflow or Wraparound (CWE-190)
2026-06-17 TuranSec
8.7
CVSS 4.0 · Vendor: TuranSec
Share

Severity by source

Vendor (TuranSec) PRIMARY
8.7 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
vuln.today AI
7.5 HIGH

Network-delivered crafted archive, no privileges or interaction needed; pure availability impact with no confidentiality or integrity consequence.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (TuranSec).

CVSS VectorVendor: TuranSec

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

4
Analysis Updated
Aug 10, 2026 - 12:34 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Aug 10, 2026 - 12:22 vuln.today
cvss_changed
CVSS changed
Aug 10, 2026 - 12:22 NVD
7.5 (HIGH) 8.7 (HIGH)
Analysis Generated
Jun 17, 2026 - 14:27 vuln.today

DescriptionCVE.org

An integer overflow in the mtar_next() function in src/microtar.c in rxi microtar 0.1.0 allows a remote attacker to cause a denial of service (uncontrolled CPU consumption / infinite loop) via a crafted tar archive. mtar_next() computes the offset to the next record as round_up(h.size, 512) + sizeof(mtar_raw_header_t) using 32-bit arithmetic. When the header size field is a multiple of 512 in the range 0xFFFFFC01-0xFFFFFE00 (e.g. 0xFFFFFE00), the addition wraps to 0, so mtar_next() seeks to the current record position instead of advancing. As a result, mtar_find() and any loop that iterates entries with mtar_next() repeat indefinitely over the same record, hanging the process at 100% CPU with no recovery.

AnalysisAI

Denial of service through infinite CPU consumption affects rxi microtar 0.1.0, a lightweight C library for tar archive parsing. The mtar_next() function performs 32-bit arithmetic to compute the offset to the next record; when a tar header encodes a size value in the range 0xFFFFFC01-0xFFFFFE00 (multiples of 512), the addition of round_up(h.size, 512) and sizeof(mtar_raw_header_t) wraps to zero, causing the function to seek back to the current record position rather than advancing. Any application that uses microtar to iterate archive entries - via mtar_find() or a manual loop - will loop indefinitely over the same record, pegging the process at 100% CPU with no recovery path. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Technical ContextAI

rxi microtar (cpe:2.3:a:rxi:microtar:*:*:*:*:*:*:*:*) is a single-file, dependency-free C library for reading and writing POSIX tar archives, commonly embedded in game engines, embedded firmware, and minimalist C projects. The root cause is CWE-190 (Integer Overflow or Wraparound): the offset computation in mtar_next() at src/microtar.c:239 uses native 32-bit unsigned integer arithmetic. For header size values such as 0xFFFFFE00 (a multiple of 512), round_up(0xFFFFFE00, 512) yields 0xFFFFFE00, and adding sizeof(mtar_raw_header_t) (512 bytes) overflows to 0x00000000. The resulting seek lands on the current record's start position, creating a permanent loop. The CPE wildcard version field indicates that the vulnerability may extend beyond the documented 0.1.0 release to any version sharing this code path.

RemediationAI

No vendor-released patch has been identified at time of analysis; the CVE references point exclusively to the existing source code with no fix commit, tagged release, or upstream pull request visible. Downstream maintainers embedding microtar should apply a local patch to mtar_next() that performs the offset arithmetic in a wider integer type (e.g., uint64_t) before assigning back to the 32-bit seek position, rejecting records where the computed next offset would overflow. As a compensating control, applications processing untrusted archives should enforce a maximum record count or total bytes-consumed limit to terminate pathological loops - a practical ceiling of, say, 65,536 records would stop the infinite loop with minimal impact on legitimate archives. Sandboxing or process-isolating the archive parsing component (e.g., running it in a child process with CPU time limits via setrlimit(RLIMIT_CPU)) provides defense in depth regardless of the library version. Restricting archive ingestion to authenticated, trusted sources reduces the network attack surface without requiring code changes.

Share

CVE-2026-54417 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy