LOW 3.9

CVE-2026-15028: Libarchive Heap Overflow in PAX Header Parsing

A security flaw in libarchive allows an attacker to cause a heap overflow by crafting a specially designed tar archive file. The vulnerability exists in how the library handles PAX extended headers, specifically a malformed SUN.holesdata attribute used for sparse files. When a victim opens such a file, it can crash the system (denial of service) or potentially allow the attacker to execute arbitrary code. However, the vulnerability requires local access and user interaction, which limits its immediate threat scope.

Source data · NVD / CISA · public domain

CVSS
3.1 · 3.9 LOW · CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:L
Weaknesses (CWE)
CWE-122, CWE-805
Affected products
0 configuration(s)
Published / Modified
2026-07-10 / 2026-08-13

NVD description (verbatim)

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.

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-15028 is a heap buffer overflow vulnerability in libarchive triggered during PAX extended header parsing. The flaw resides in the library's handling of the SUN.holesdata sparse-file attribute within tar archives. Exploitation requires a specially crafted tar file and occurs when the attribute contains malformed data that violates expected buffer boundaries. The vulnerability maps to CWE-122 (Heap-based Buffer Overflow) and CWE-805 (Buffer Access with Incorrect Length Value), indicating improper bounds checking during header field processing.

Business impact

The primary business risk is denial of service: if libarchive processes are critical to your infrastructure (backup systems, software distribution, artifact extraction), a successful exploitation could interrupt operations. The secondary risk—arbitrary code execution—would be more severe but requires specific conditions to realize. Organizations relying on libarchive for automated archive processing, containerized deployments, or CI/CD pipelines should assess whether untrusted or user-supplied tar files pass through affected versions without validation.

Affected systems

Libarchive is widely used across UNIX/Linux systems, macOS, and software ecosystems that depend on tar archive handling. The vulnerability affects libarchive library users; specific product versions are not detailed in the available advisory. You must consult your vendor's security bulletins and libarchive's official changelog to identify which versions are vulnerable. Applications embedding or wrapping libarchive—such as backup utilities, package managers, and container tools—inherit this risk if running unpatched versions.

Exploitability

Exploitation is constrained by the CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:L), which indicates local attack vector, low complexity, and requirement for low privilege plus user interaction. An attacker cannot remotely trigger this flaw; they must first gain local system access and convince a user to open a malicious tar file. The low CVSS score (3.9) reflects these barriers. While remote code execution is theoretically possible, the practical exploitation path is narrow, making this a lower-priority threat compared to remotely exploitable heap overflows.

Remediation

Update libarchive to a patched version released after the vulnerability's discovery (check the official libarchive project repository and your OS/vendor security advisories for specific version numbers). For systems where immediate patching is infeasible, restrict access to archive processing to trusted users, implement file validation before extraction, and monitor for unusual tar files in your environment. If libarchive is embedded in third-party software, verify that vendors have released security updates.

Patch guidance

Consult your operating system vendor (Red Hat, Debian, Ubuntu, etc.) and the libarchive project's official security announcements for patched version identifiers. Typically, vendors release patched versions within weeks of public disclosure. Test patches in a non-production environment before deployment to ensure compatibility with dependent applications. Monitor the vendor advisory channels for backported fixes to older stable releases if your infrastructure requires them.

Detection guidance

Monitor file system access for suspicious tar file creation or extraction in directories accessed by libarchive processes. Log all calls to archive-related functions in applications using libarchive. Implement network detection rules to flag unexpected archive transfers to sensitive systems. Consider using file integrity monitoring (FIM) on critical archive processing directories. Host-based intrusion detection systems (HIDS) can alert on process crashes or segmentation faults that may indicate exploitation attempts, though these signals require context to confirm malicious intent.

Why prioritize this

Despite the moderate potential impact (DoS or RCE), this vulnerability receives a lower priority due to its constrained attack surface: local-only access requirement, user interaction needed, and low CVSS score. Organizations should prioritize patching only if they run libarchive on systems handling untrusted archive files from external sources or if libarchive is exposed via automated processing pipelines. If your environment strictly controls who can supply tar files and processes them in isolated contexts, risk is proportionally lower.

Risk score, explained

The CVSS 3.1 score of 3.9 (LOW) reflects the combination of local-only attack vector, low attack complexity, requirement for low privileges and user interaction, and limited scope of impact (confidentiality and availability only, no integrity impact). The heap overflow itself is serious, but the multiple preconditions—local access, user action, and the need to craft a specific malformed PAX header—reduce the overall risk profile compared to remotely exploitable memory corruption flaws.

Frequently asked questions

Can this vulnerability be exploited remotely?

No. The CVSS vector explicitly specifies AV:L (local attack vector), meaning the attacker must have already gained local system access. They cannot trigger the flaw through a network connection alone. They must also convince a local user to process the malicious tar file.

What is the difference between DoS and RCE in this context?

Denial of service (DoS) occurs when the heap overflow crashes the libarchive process or the application using it, making that service unavailable. Arbitrary code execution (RCE) would require the attacker to craft the malicious header in such a way that they can control heap memory content and redirect execution flow. While theoretically possible, RCE is harder to achieve and less likely than DoS in practical scenarios.

If we don't extract untrusted tar files, do we need to patch?

If your organization only processes tar archives from trusted, internal sources (your own builds, verified vendor distributions), your immediate risk is substantially lower. However, you should still apply patches during regular maintenance windows to reduce the risk of insider threats or supply chain compromise.

How can we detect if someone is trying to exploit this?

Monitor your systems for processes related to archive extraction (tar, bsdtar, file managers) crashing unexpectedly, especially when processing unusual or unexpected files. Implement file validation to reject tar files with suspicious or malformed headers before they reach libarchive. Review logs for attempts to extract files from untrusted sources.

This analysis is based on the CVE record published on 2026-07-10 and modified on 2026-08-13. No additional vendor product information or patch version numbers were available in the source data; verify all remediation steps against official vendor security advisories before deployment. CVSS scoring and severity classification reflect the published vector and are subject to organizational risk context adjustments. This explainer does not constitute professional security advice and should be reviewed alongside your organization's threat modeling and vulnerability management policies. No exploit code or proof-of-concept information is provided or endorsed herein. Source: NVD (public-domain), retrieved 2026-08-17. Analysis generated by SEC.co (claude-haiku-4-5).