CVE-2026-55738: rxi microtar Buffer Overflow Vulnerability

CVE-2026-55738 Overview

CVE-2026-55738 is a stack-based buffer overflow [CWE-121] in the raw_to_header() function of src/microtar.c in rxi microtar 0.1.0. The function uses strcpy() to copy the 100-byte name and linkname fields from a TAR header without guaranteeing null termination of the source data. A crafted POSIX ustar archive whose linkname field contains no null terminator causes strcpy() to read past the 512-byte raw header stack buffer and write past the destination header buffer. Any application that opens an attacker-supplied archive through mtar_open(), mtar_read_header(), or mtar_find() is exposed to denial of service and potential arbitrary code execution.

Critical Impact

A single malicious TAR archive parsed by a vulnerable microtar consumer can crash the process or execute attacker-controlled code in the context of the victim application.

Affected Products

• rxi microtar 0.1.0
• Applications statically linking or vendoring src/microtar.c from rxi microtar
• Downstream tooling that parses untrusted TAR archives with microtar

Discovery Timeline

• 2026-06-17 - CVE-2026-55738 published to NVD
• 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-55738

Vulnerability Analysis

The defect lives in raw_to_header() at src/microtar.c:112, where the parser converts a 512-byte raw TAR block into an mtar_header_t structure. The implementation calls strcpy() against the fixed-width name and linkname fields of the ustar header. POSIX ustar permits these 100-byte fields to be completely filled with non-null bytes, meaning a conforming archive can legally omit a terminating null inside the field.

When the linkname field lacks a null byte, strcpy() continues reading into the trailing padding of the 512-byte raw header on the stack. Once the padding is also unterminated, the read passes the end of the stack buffer and the write overruns the destination mtar_header_t. AddressSanitizer confirmed the condition as a stack-buffer-overflow READ of size 356.

Root Cause

The root cause is unsafe use of strcpy() on fixed-width binary fields that are not required to be null-terminated. The code treats the ustar field as a C string and trusts the source to contain a terminator. No bounded copy primitive such as memcpy() with the known field length, or strnlen() followed by a sized copy, is used. The destination structure on the stack therefore receives an attacker-controlled byte stream of unbounded length.

Attack Vector

A remote attacker crafts a TAR archive whose linkname field is fully populated with non-null bytes and whose adjacent header bytes also lack a null terminator. The attacker delivers the archive through any channel the victim application accepts, such as software updates, package handling, backup ingestion, or file upload endpoints. When the victim calls mtar_open(), mtar_read_header(), or mtar_find(), the parser triggers the out-of-bounds read and stack overflow. User interaction is required to open or parse the archive, but no privileges or authentication are needed.

The exploitation mechanism is described in the vulnerability summary. No verified public proof-of-concept code is referenced beyond the upstream source at the microtar GitHub repository and the affected line in src/microtar.c#L111.

Detection Methods for CVE-2026-55738

Indicators of Compromise

• Unexpected crashes or SIGSEGV signals in processes that invoke microtar APIs while parsing externally sourced archives.
• AddressSanitizer reports referencing raw_to_header at src/microtar.c:112 with stack-buffer-overflow READ.
• TAR archives whose 100-byte name or linkname fields contain no null byte, identifiable through static archive inspection.

Detection Strategies

• Build microtar consumers with AddressSanitizer in test environments and replay archives received from untrusted sources.
• Inventory binaries that statically link or vendor microtar.c using software composition analysis to locate vulnerable copies.
• Add a pre-parse validation step that rejects TAR headers where name[99] or linkname[99] is non-zero.

Monitoring Recommendations

• Alert on repeated abnormal terminations of services that ingest TAR archives, especially those exposed to network input.
• Capture core dumps from archive-processing workers and inspect for stack frames inside raw_to_header.
• Log archive metadata at ingestion points to retain forensic evidence of malformed headers.

How to Mitigate CVE-2026-55738

Immediate Actions Required

• Stop processing TAR archives from untrusted sources with applications that link rxi microtar 0.1.0.
• Identify all internal projects that vendor src/microtar.c and queue them for remediation.
• Apply a local patch that replaces the strcpy() calls in raw_to_header() with a bounded copy that respects the 100-byte field width and explicitly null-terminates the destination.

Patch Information

No upstream fixed release is referenced in the published advisory at the time of writing. Maintainers and downstream integrators should review the affected line at src/microtar.c#L111 and replace the unsafe strcpy() invocations with memcpy() bounded to sizeof(rh->name) and sizeof(rh->linkname), followed by explicit null termination at the final byte of the destination field.

Workarounds

• Validate incoming TAR archives before parsing and reject any header whose name or linkname field lacks a null terminator within the 100-byte slot.
• Isolate TAR parsing in a sandboxed process with seccomp or equivalent confinement so a crash or overflow cannot affect the parent.
• Compile microtar consumers with stack protectors, _FORTIFY_SOURCE=2, and position-independent executables to raise the cost of exploitation.

# Configuration example: defensive build flags for microtar consumers
CFLAGS="-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE -Wformat -Wformat-security"
LDFLAGS="-pie -Wl,-z,relro,-z,now"
# Run integration tests with AddressSanitizer enabled
CFLAGS_ASAN="$CFLAGS -fsanitize=address -fno-omit-frame-pointer"