CVE-2026-17591: Libarchive: libarchive: use-after-free via aliased mac metadata copy

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Published Oct 16, 2026

Updated

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

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

1 affected component

Libarchive libarchive<=4840347

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade libarchive to a version that resolves this vulnerability.
Patch PR #3318

Event History

Oct 16, 2026

Data Sourced

via Red Hat·04:53 PM

DescriptionSeverityAffected Software

CVE Published

via MITRE·10:03 PM

Data Sourced

via MITRE·10:03 PM

DescriptionSeverityWeakness

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.

CVE-2026-17591: Libarchive: libarchive: use-after-free via aliased mac metadata copy

Other sources

Affected Software

Remediation

Event History

Frequently Asked Questions

What application behavior is required for exploitation?

Is this remotely exploitable without any user involvement?

How can I determine whether my build is affected?

What should be done if the affected code is present?

Company

Resources

Contact

Frequently Asked Questions

What application behavior is required for exploitation?

Is this remotely exploitable without any user involvement?

How can I determine whether my build is affected?

What should be done if the affected code is present?