Description

libarchive 3.8.x before 3.8.2 has a strcpy heap-based buffer overflow in the gzip writer via the original-filename field to archive_compressor_gzip_open in archive_write_add_filter_gzip.c, aka GHSA-92wx-p669-8gr9. This relates to bsdtar. Exploitation envisions a marginally plausible scenario in which original-filename is obtained from an untrusted party. (original-filename is not derived from the input data.)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.5",
  "pubDate": "2026-09-14T01:16:26.190Z",
  "pubdate": "2026-09-14T01:16:26.190Z",
  "executiveSummary": "A heap-based buffer overflow vulnerability has been identified in the gzip writer component of libarchive versions 3.8.x before 3.8.2. The vulnerability exists within the archive_compressor_gzip_open function in the file archive_write_add_filter_gzip.c. This flaw is tracked under GHSA-92wx-p669-8gr9.\nThe vulnerability occurs due to the insecure usage of the strcpy function when processing the original-filename field during gzip compression. If an attacker can influence the original-filename value provided to the compression filter, they can trigger a heap-based buffer overflow. This can lead to memory corruption, potentially resulting in application crashes or, theoretically, the execution of arbitrary code with the privileges of the process executing libarchive, such as bsdtar.\nThe exploitation scenario is considered marginally plausible, requiring the application to ingest an untrusted original-filename parameter. The impact is significant for environments that use libarchive to process user-supplied metadata in compression routines, as it compromises the integrity and availability of the host application.",
  "technicalDetails": "The vulnerability resides in the gzip compression filter implementation within libarchive, specifically in the archive_write_add_filter_gzip.c source file. The root cause is a classic heap-based buffer overflow triggered by the unsafe use of the strcpy function when handling the original-filename metadata field within the archive_compressor_gzip_open function.\nIn standard gzip compression workflows, the compressor may include the original filename as part of the gzip header. The implementation in libarchive fails to perform adequate bounds checking on the input string before copying it into a fixed-size heap-allocated buffer. Because strcpy does not verify the destination buffer size against the source length, a string exceeding the allocated buffer capacity results in an out-of-bounds write operation on the heap.\nThe attack flow requires an attacker to successfully inject a malicious or oversized string into the original-filename field that is subsequently passed to the gzip compression filter. While the provided documentation notes that the original-filename is not typically derived from raw input data within an archive, any interface or application using libarchive that allows external input to define or influence this metadata field is susceptible. Upon processing, the strcpy operation will continue copying bytes beyond the allocated memory segment, overwriting adjacent heap chunks.\nThe impact of this heap corruption is severe; by overwriting heap metadata (such as chunk headers or application-specific pointers) or adjacent data objects, an attacker may influence the control flow of the application. Depending on the memory layout and the specific target application utilizing libarchive, this could lead to arbitrary code execution (ACE). As libarchive is a foundational component for tools like bsdtar, the attack surface includes any system utility or third-party software that bundles or links against the vulnerable version of the library. Exploitation does not necessarily require authentication or specific privilege levels if the application handles untrusted input directly, though the success of code execution may be mitigated by modern platform-level exploit mitigations like ASLR, DEP/NX, and heap cookies."
}