CVE-2025-64031 in libarchive
Summary
by MITRE • 09/14/2026
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.)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified as GHSA-92wx-p669-8gr9 represents a critical heap-based buffer overflow within libarchive versions 3.8.x prior to release 3.8.2, specifically affecting the gzip compression filter implementation. This flaw is located in the archive_compressor_gzip_open function found in the source file archive_write_add_filter_gzip.c and directly impacts utilities such as bsdtar that rely on this library for data archiving operations. The root cause of the vulnerability lies in the unsafe handling of the original-filename field during the initialization of the gzip compressor. When a user specifies an original filename to be stored within the gzip header metadata, libarchive utilizes standard C string functions without adequate bounds checking. Specifically, the code employs strcpy to copy the provided filename into a fixed-size buffer allocated on the heap. Because there is no validation ensuring that the length of the input string fits within the destination buffer's capacity, an oversized original-filename value will overwrite adjacent memory regions on the heap.
This type of vulnerability falls squarely under CWE-120, which classifies buffer copies without checking size limits as a classic cause of memory corruption issues. The exploitation scenario described is considered marginally plausible because it requires specific conditions to be met for successful attack execution. Unlike vulnerabilities where input data directly influences internal structures through parsing logic, this flaw involves the original-filename field which is typically not derived from the compressed or archived content itself but rather supplied as a metadata parameter by the user invoking the tool. Consequently, an attacker must have some level of control over the arguments passed to libarchive or bsdtar. This could occur in scenarios where automated backup systems accept filenames provided by external sources without sanitization, or when processing archives generated by untrusted parties that include maliciously crafted gzip headers expecting subsequent operations to re-archive them with specific metadata settings.
The operational impact of this heap-based buffer overflow is severe and multifaceted. By overwriting adjacent heap memory, an attacker can corrupt internal data structures used by the library, such as function pointers or object vtables. This corruption allows for arbitrary code execution with the privileges of the process running libarchive. In environments where bsdtar is run with elevated permissions to manage system backups or perform administrative tasks, successful exploitation could lead to full system compromise. Furthermore, even if immediate remote code execution is not achieved due to modern memory protection mechanisms like ASLR and DEP, heap corruption can cause denial of service through application crashes or data integrity issues in the resulting archive files. The lack of input validation means that any sufficiently long string provided as an original filename serves as a potential vector for exploitation.
Mitigation strategies must address both immediate remediation and longer-term defensive coding practices. The primary defense is to upgrade libarchive to version 3.8.2 or later, where this specific buffer overflow has been patched by replacing the unsafe strcpy call with a bounds-checked alternative such as strncpy or strlcpy, ensuring that only the allowed number of characters are copied into the fixed-size buffer. For organizations unable to immediately update their dependencies, implementing strict input validation on any external sources providing filenames for archival operations is essential. This includes enforcing maximum length limits consistent with the internal buffer sizes used by libarchive and rejecting inputs that exceed these thresholds before they reach the compression module. Additionally, developers should adopt secure coding standards such as those outlined in CWE-134 regarding uncontrolled format strings or memory allocation issues to prevent similar vulnerabilities in future development cycles. Regular security audits of third-party library usage within critical infrastructure are recommended to identify and remediate other potential weaknesses related to unsafe string handling functions.