CVE-2026-17591: Libarchive: libarchive: use-after-free via aliased mac metadata copy
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.
Other sources
Libarchive: libarchive: use-after-free via aliased mac metadata copy
— Microsoft
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
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/libarchiveto a version that resolves this vulnerability.Fixed in 3.8.9-1 - Upgrade
Upgrade
debian/libarchiveto a version that resolves this vulnerability.Fixed in 3.8.10-2Fixed in 3.8.11-1 - Upgrade
Upgrade
libarchiveto a version that resolves this vulnerability.Patch PR #3318
Event History
Frequently Asked Questions
What application behavior is required for exploitation?
The application must use the vulnerable libarchive entry API and pass a source buffer to archive_entry_copy_mac_metadata() that aliases the internal Mac metadata buffer of the same archive_entry object. An attacker also needs the ability to read from and write input to the program using that API.
Is this remotely exploitable without any user involvement?
The provided vector identifies local attack access and required user interaction. It does not describe a network-only, unattended exploitation path.
How can I determine whether my build is affected?
The issue is reported to affect commit 4840347 and previous versions. No release version was tested or confirmed fixed, so release-version status cannot be determined from the available information alone.
What should be done if the affected code is present?
An upstream patch is available in pull request #3318. No confirmed fixed release version is provided, so teams should evaluate and apply the available upstream patch rather than relying on a release-version claim.