See how libarchive compares to other vendors in security performance
Heap-based buffer overflow in archivestringappendfromwcs() (archivestring.c) in libarchive-3.4.1dev allows remote attackers to cause a denial of service (out-of-bounds write in heap memory resulting into a crash) via a crafted archive file. NOTE: this only affects users who downloaded the development code from GitHub. Users of the product's official releases are unaffected.
A vulnerability has been identified in the libarchive library. This flaw can lead to a heap buffer over-read due to the size of a filter block potentially exceeding the Lempel-Ziv-Storer-Schieber (LZSS) window. This means the library may attempt to read beyond the allocated memory buffer, which can result in unpredictable program behavior, crashes (denial of service), or the disclosure of sensitive information from adjacent memory regions.
A vulnerability has been identified in the libarchive library. This flaw involves an 'off-by-one' miscalculation when handling prefixes and suffixes for file names. This can lead to a 1-byte write overflow. While seemingly small, such an overflow can corrupt adjacent memory, leading to unpredictable program behavior, crashes, or in specific circumstances, could be leveraged as a building block for more sophisticated exploitation. This bug affects libarchive versions prior to 3.8.0.
A vulnerability has been identified in the libarchive library. This flaw can be triggered when file streams are piped into bsdtar, potentially allowing for reading past the end of the file. This out-of-bounds read can lead to unintended consequences, including unpredictable program behavior, memory corruption, or a denial-of-service condition.
A vulnerability has been identified in the libarchive library. This flaw involves an integer overflow that can be triggered when processing a Web Archive (WARC) file that claims to have more than INT64MAX - 4 content bytes. An attacker could craft a malicious WARC archive to induce this overflow, potentially leading to unpredictable program behavior, memory corruption, or a denial-of-service condition within applications that process such archives using libarchive. This bug affects libarchive versions prior to 3.8.0.
A flaw was found in libarchive. This vulnerability allows a remote attacker to trigger a heap overflow by providing a specially crafted tar archive. The issue occurs during the parsing of a PAX extended header containing a malformed SUN.holesdata sparse-file attribute. Successful exploitation could lead to a denial of service, making the system unavailable, or potentially allow for arbitrary code execution, giving the attacker control over the affected system.
A flaw was found in libarchive. An attacker can cause a Denial of Service (DoS) or potential information disclosure due to a use-after-free vulnerability, which occurs when a program reads memory that has already been released. This issue arises when the archiveentrycopymacmetadata() function deallocates an internal buffer before completing a data copy. An attacker who can supply input to an application utilizing this function can trigger the flaw to crash the application or read uninitialized memory data.
A flaw was found in libarchive. A NULL pointer dereference vulnerability exists in the ACL parsing logic, specifically within the archiveaclfromtextnl() function. When processing a malformed ACL string (such as a bare "d" or "default" tag without subsequent fields), the function fails to perform adequate validation before advancing the pointer. An attacker can exploit this by providing a maliciously crafted archive, causing an application utilizing the libarchive API (such as bsdtar) to crash, resulting in a Denial of Service (DoS).
A signed integer overflow flaw was found in libarchive's ZIP writer. The issue occurs in the archivewritezipheader function in archivewritesetformatzip.c when writing a ZIP entry with a known file size while ZIP encryption (e.g., AES-256) is enabled. When the entry size is close to INT64MAX, adding the encryption overhead (additionalsize) to zip->entryuncompressedsize triggers a signed integer overflow, leading to undefined behavior per the C standard. This could result in incorrect Zip64 extension decisions or potential memory corruption.
The vulnerability is in the write path only and requires both ZIP encryption to be enabled and a file size near INT64MAX, making real-world exploitation unlikely.
Upstream issue: https://github.com/libarchive/libarchive/issues/3225 Upstream fix: https://github.com/libarchive/libarchive/pull/3228
A flaw was found in libarchive. An Undefined Behavior vulnerability exists in the zisofs decompression logic, caused by improper validation of a field (pzlog2bs) read from ISO9660 Rock Ridge extensions. A remote attacker can exploit this by supplying a specially crafted ISO file. This can lead to incorrect memory allocation and potential application crashes, resulting in a denial-of-service (DoS) condition.
An issue was discovered in libarchive bsdtar before version 3.8.1 in function applysubstitution in file tar/subst.c when processing crafted -s substitution rules. This can cause unbounded memory allocation and lead to denial of service (Out-of-Memory crash).
A vulnerability has been identified in the libarchive library, specifically within the archivereadformatrarseekdata() function. This flaw involves an integer overflow that can ultimately lead to a double-free condition. Exploiting a double-free vulnerability can result in memory corruption, enabling an attacker to execute arbitrary code or cause a denial-of-service condition.
A flaw was found in libarchive. On 32-bit systems, an integer overflow vulnerability exists in the zisofs block pointer allocation logic. A remote attacker can exploit this by providing a specially crafted ISO9660 image, which can lead to a heap buffer overflow. This could potentially allow for arbitrary code execution on the affected system.
A flaw was found in libarchive. This heap out-of-bounds read vulnerability exists in the RAR archive processing logic due to improper validation of the LZSS sliding window size after transitions between compression methods. A remote attacker can exploit this by providing a specially crafted RAR archive, leading to the disclosure of sensitive heap memory information without requiring authentication or user interaction.
An improper link resolution flaw can occur while extracting an archive leading to changing modes, times, access control lists, and flags of a file outside of the archive. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when trying to extract the archive. A local attacker may use this flaw to gain more privileges in a system.
libarchive. Multiple memory corruption issues existed in libarchive. These issues were addressed with improved input validation.
In libarchive 3.6.1, the software does not check for an error after calling calloc function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference or, in some cases, even arbitrary code execution.
Upstream patch: https://github.com/libarchive/libarchive/commit/fd180c36036df7181a64931264732a10ad8cd024
Libarchive v3.6.0 was discovered to contain an out-of-bounds read via the component zipxlzmaaloneinit.
Accessibility. A logging issue was addressed with improved data redaction.
executefilteraudio in archivereadsupportformatrar.c in libarchive before 3.7.5 allows out-of-bounds access via a crafted archive file because src can move beyond dst.
Libarchive Remote Code Execution Vulnerability
libarchive through 3.7.7 has a heap-based buffer over-read in headergnulonglink in archivereadsupportformattar.c via a TAR archive because it mishandles truncation in the middle of a GNU long linkname.
Double free in Windows Libarchive allows an unauthorized attacker to execute code over a network.
Last updated 25 August 2025
A double-free vulnerability exists in the libarchive RAR5 reader subsystem within archivereadsupportformatrar5.c where the state tracking pointer rar->cstate.filteredbuf can be linked to a temporary filter output block during archive decompression. When the unpacking engine subsequently processes an adjacent file or resets its internal state layout via initunpack(), it releases the allocation mapped to filteredbuf but fails to clear or nullify the underlying pointer variable. A specially crafted RAR5 archive can exploit this lingering dangling pointer by forcing a secondary release operation on the exact same memory address, triggering a standard memory-manager abort that immediately crashes the application and results in a Denial of Service (DoS).
Summary: The flaw occurs when the source buffer passed to archiveentrycopymacmetadata() points to the internal Mac metadata buffer of the same archiveentry object. The function frees the internal buffer before copying from it, causing a UAF read during memcpy().
Requirements to exploit: An attacker need ability of reading and writing to a program using vulnarable libarchive entry API
Component affected: https://github.com/libarchive/libarchive
Version affected: Commit hash 4840347 and previous versions. I didn't try on any release version.
Patch Available: Yes
Version fixed: No release version has been confirmed fixed the flaw.But have a patch in upstream by PR #3318: https://github.com/libarchive/libarchive/pull/3318
Upstream coordination: Upstream was notified publicly through the following GitHub issue: https://github.com/libarchive/libarchive/issues/3313 And a fix was submitted and merged: https://github.com/libarchive/libarchive/pull/3318
Impact: A successful exploitation will make the program read wrong data from a freed buffer and then have logic problem. In addition, it probably can benefit chunk metadata leak for potential control flow hijack.
Embargo: No
Suggested public date: N/A, since the issue is already public.
Acknowledgement: Mr.Xin
Steps to reproduce: 1. Build the POC.c (source file is in the attachments): /usr/bin/clang -O1 -g \ -fsanitize=address,undefined -fno-omit-frame-pointer \ -I/path/to/libarchive/libarchive \ /path/to/POC.c \ /path/to/libarchive/LibBuilds/libarchive/libarchive.a \ -lz -lbz2 -llzma -lzstd -lcrypto -lxml2 -lssl \ -licui18n -licuuc -licudata -lm -lresolv \ -o /output/path/POCExecutor
2. Run PoC LLVMSYMBOLIZERBIN=/path/to/llvm-symbolizer ASANOPTIONS="detectleaks=0:haltonerror=1:abortonerror=1:symbolize=1:externalsymbolizerpath=${LLVMSYMBOLIZERBIN}" \ UBSANOPTIONS=haltonerror=1:printstacktrace=1 \ /output/path/POCExecutor
Original report: https://github.com/libarchive/libarchive/issues/3313
Last updated 25 August 2025
libarchive version commit 379867ecb330b3a952fb7bfa7bffb7bbd5547205 onwards (release v3.3.0 onwards) contains a CWE-476: NULL Pointer Dereference vulnerability in ACL parser - libarchive/archiveacl.c, archiveaclfromtextl() that can result in Crash/DoS. This attack appear to be exploitable via the victim must open a specially crafted archive file.
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 archivecompressorgzipopen in archivewriteaddfiltergzip.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.)
A signed integer overflow flaw was found in libarchive's ZIP writer. The issue occurs in the archivewritezipheader function in archivewritesetformatzip.c when writing a ZIP entry with a known file size while ZIP encryption (e.g., AES-256) is enabled. When the entry size is close to INT64MAX, adding the encryption overhead (additionalsize) to zip->entryuncompressedsize triggers a signed integer overflow, leading to undefined behavior per the C standard. This could result in incorrect Zip64 extension decisions or potential memory corruption.
The vulnerability is in the write path only and requires both ZIP encryption to be enabled and a file size near INT64MAX, making real-world exploitation unlikely.
Upstream issue: https://github.com/libarchive/libarchive/issues/3225 Upstream fix: https://github.com/libarchive/libarchive/pull/3228