CVE-2026-42497

What it actually does

Archive::Tar before 3.08 incorrectly processes hardlink entries during tar extraction. The vulnerable _make_special_file() path passes the tar header linkname directly to link() without rejecting absolute paths or parent-directory traversal sequences. An attacker-controlled archive can therefore create a hardlink inside the extraction directory that points to a file outside that directory. Because the hardlink shares the same inode as the target file, subsequent writes, chmod, chown, and utime operations applied to the extracted entry can modify the external file’s contents, ownership, permissions, or timestamps. The primary impact is arbitrary file integrity compromise in the context of the process performing extraction.

Why it matters to the business

Any application or automated workflow that extracts untrusted tar archives with vulnerable Archive::Tar versions can be used to tamper with files outside the intended upload or unpack directory. This can lead to altered application files, modified configuration, corrupted data, privilege-boundary bypass within the extractor’s filesystem permissions, and operational disruption. The EPSS score is currently low and stable, there is no known KEV listing or ransomware association, and no public exploit maturity is indicated, but the issue remains important for systems that automatically unpack archives received over a network.

How an attack unfolds

An attacker prepares a tar archive containing a hardlink entry whose linkname references a sensitive or operationally important file outside the intended extraction directory, such as by using an absolute path or ../ traversal. The attacker submits the archive to a service, job runner, CI pipeline, package-processing system, or other Perl-based workflow that uses a vulnerable Archive::Tar release to extract it. During extraction, Archive::Tar creates the hardlink without validating that the referenced target stays within the extraction root. Because the extracted hardlink and the outside file share an inode, later extraction actions against the archive member can change the outside file. Depending on the archive contents and extractor privileges, the attacker can cause unauthorized changes to file content, ownership, permissions, or timestamps. Successful exploitation requires the extraction process to have filesystem rights to hardlink to or modify the chosen target, and platform hardlink protections may limit some target choices.

How to fix it

Upgrade Archive::Tar to version 3.08 or later, or install the equivalent patched package from the operating system or Perl distribution vendor. If immediate upgrade is not possible, do not extract untrusted tar files with vulnerable Archive::Tar versions; disable or reject hardlink entries in tar archives; reject tar members whose paths or linknames are absolute or contain parent-directory traversal; extract archives in a locked-down sandbox or disposable container; run extraction as a dedicated low-privilege user; and ensure extraction directories reside on isolated filesystems where hardlinks to sensitive files are not possible. Treat any application-level archive validation as defense in depth, not a substitute for upgrading the library.

How to confirm the fix worked

Confirm the installed Archive::Tar version is 3.08 or later using package inventory, SBOM tooling, vendor package metadata, or a runtime check such as perl -MArchive::Tar -e 'print $Archive::Tar::VERSION'. Identify bundled or vendored Perl dependencies as well as system packages, because applications may ship their own module copies. Test representative extraction workflows with a benign proof-of-concept archive containing a hardlink whose linkname is absolute or includes ../ and verify that extraction rejects it or prevents any change outside the target extraction directory. Also confirm that mitigations block hardlink entries and that extraction runs with least privilege in production-like configurations.

Typical attack path

1. Identify an application or workflow that accepts or retrieves tar archives from an untrusted or attacker-influenced source.
2. Craft a tar archive containing hardlink entries with linkname values that are absolute paths or include ../ traversal outside the extraction directory.
3. Optionally include subsequent archive entries or metadata intended to write through the hardlink or change mode, owner, group, or timestamps.
4. Deliver the archive to the vulnerable extraction workflow.
5. Vulnerable Archive::Tar creates a hardlink inside the extraction directory pointing to the external target file.
6. Extraction continues and writes or metadata operations applied to the extracted name affect the external file’s inode.
7. The attacker achieves unauthorized file modification within the privileges and filesystem constraints of the extraction process.

How to detect it

To determine whether exploitation already occurred, review application logs, upload records, job-runner logs, CI logs, package-ingestion logs, and file-processing service logs for tar archives extracted by Perl Archive::Tar before the patched version. Preserve and inspect suspicious archives with tar-listing tools that show hardlink metadata, looking for hardlink entries whose link targets are absolute paths or contain ../ traversal. On Linux and Unix systems, correlate extraction timestamps with file integrity monitoring, auditd, EDR, or filesystem telemetry showing link or linkat system calls made by perl or an application process where the source path is outside the extraction directory and the destination path is inside it. Look for unexpected chmod, chown, utime, or content modifications to files outside extraction roots immediately after archive extraction. If centralized telemetry records process command lines or module loads, search for Perl processes using Archive::Tar in workflows that handled externally supplied archives. There are no universal network indicators because exploitation is embedded in the archive format and the target path is environment-specific.

• Archive::Tar
• _make_special_file
• linkname=/
• linkname=../
• typeflag=1
• perl -MArchive::Tar
• tar: hard link to `/
• tar: hard link to `../
• ../
• /etc/passwd
• /etc/shadow
• /root/.ssh/authorized_keys

What your security team should do

• Inventory all systems, containers, CI runners, package-processing services, upload handlers, and automation jobs that use Perl Archive::Tar to extract tar archives.
• Prioritize patching internet-facing or automated archive-processing workflows to Archive::Tar 3.08 or later, even though current EPSS and known exploitation signals are low.
• Add archive validation controls that reject hardlink entries with absolute paths or ../ traversal in both member names and linkname fields.
• Run archive extraction under a dedicated low-privilege account inside a sandbox, container, or isolated filesystem with minimal access to sensitive files.
• Review recent archive-processing activity for suspicious hardlink entries and unexpected file metadata or content changes outside extraction directories.
• Update secure coding guidance for archive extraction to require canonical path validation for filenames and link targets, and to treat hardlinks similarly to symlinks for traversal risk.