CVE-2026-4360

What it actually does

The flaw is an improper input-validation issue in tar archive extraction. When Tarfile.extract() is called with filter='data', the filter is not correctly applied to hardlink entries, so metadata on hardlinks can bypass the intended safety handling. A crafted tar archive can therefore cause extracted files or hardlinks to be written with unexpected uid/gid ownership values. The direct impact is limited integrity impact on the extracted filesystem contents; it does not inherently provide code execution, data disclosure, or availability loss unless the affected extraction workflow runs with elevated privileges or later trusts the ownership of extracted files.

Why it matters to the business

Systems that accept and extract untrusted tar files may create files with unintended ownership, which can weaken file-permission assumptions, disrupt application workflows, or contribute to privilege-boundary bypasses in build, packaging, backup, CI/CD, artifact-ingestion, or content-processing pipelines. The CVSS and EPSS values indicate low current likelihood and limited standalone impact, and it is not listed in CISA KEV or known ransomware use, but exposure is still important where archives are processed automatically or by privileged services.

How an attack unfolds

An attacker first needs a way to provide a tar archive to an application or service that extracts archive contents using the vulnerable Tarfile.extract() behavior with filter='data'. The attacker crafts the archive to include hardlink entries whose ownership metadata is intentionally set to unexpected uid/gid values. When the vulnerable extraction path processes the archive, the intended data filter is not properly applied to those hardlink entries, allowing ownership metadata to be applied in a way the caller expected the filter to prevent. If extraction occurs as a privileged user, in a sensitive directory, or in a pipeline that later makes security decisions based on file ownership, the attacker may be able to influence filesystem state and potentially chain the issue with other weaknesses. Exploitation requires attacker-supplied archive content and user or system interaction to extract it; there is no public exploit maturity reported in the provided data.

How to fix it

Upgrade the affected runtime or library package once a vendor-provided fixed version is available for the platform in use. No exact fixed versions were provided in the input, so remediation should be tracked through the relevant language/runtime vendor advisories and distribution security channels. Until patched, do not extract untrusted tar archives using vulnerable Tarfile.extract() behavior. Prefer extracting archives only in isolated, non-privileged sandboxes; never extract attacker-controlled archives as root or as a privileged service account; reject or strip hardlink entries from untrusted tar files before extraction; validate every archive member before extraction; and enforce post-extraction ownership normalization with a known-safe uid/gid. Where possible, replace direct extraction of untrusted tar files with a hardened extraction routine that rejects links, absolute paths, parent-directory traversal, special files, and unexpected ownership metadata.

How to confirm the fix worked

Inventory code paths and services that call Tarfile.extract() or related tar extraction routines on externally supplied archives, especially where filter='data' is used. Confirm that the deployed runtime or vendor package includes the fix once available. As a functional validation, create a controlled tar archive containing hardlink entries with non-default uid/gid metadata and extract it in a test environment using the same application path; the fixed or mitigated behavior should reject the unsafe member, ignore the unsafe metadata, or normalize ownership to the expected account. After patching or mitigation, verify that extraction is performed as a non-privileged user and that post-extraction files do not retain attacker-controlled uid/gid values.

Typical attack path

1. Identify an application, service, build process, or automation workflow that accepts tar archives from users or external sources.
2. Determine that the target extracts tar content using the affected Tarfile.extract() behavior with filter='data'.
3. Create a tar archive containing hardlink entries with crafted uid/gid ownership metadata.
4. Submit, upload, or otherwise cause the vulnerable workflow to extract the malicious archive.
5. Rely on the extraction bug to create files or hardlinks with unexpected ownership.
6. Abuse the resulting filesystem ownership state directly, or chain it with another misconfiguration or privileged workflow that trusts extracted file ownership.

How to detect it

There are no universal network indicators for this vulnerability because exploitation occurs through archive content processed by an application. To assess possible prior exploitation, review application logs for tar upload or extraction events involving untrusted sources, especially archives that contained hardlink entries. Examine filesystem artifacts in extraction directories for recently created files with unexpected uid/gid ownership, hardlink counts greater than one, or ownership that differs from the service account normally used by the extraction process. Review auditd, EDR, or filesystem monitoring logs for chown-like metadata changes or file creation events during archive extraction windows. If upload archives are retained, inspect them with tar-listing tools and look for hardlink entries plus suspicious numeric owners such as uid 0 or privileged service gids. Correlate suspicious archives with subsequent permission changes, failed access attempts, unexpected writable files, or downstream jobs that consumed the extracted files.

What your security team should do

• Prioritize review of internet-facing, user-facing, CI/CD, artifact-ingestion, backup, and content-processing systems that accept tar uploads or consume tar files from external sources.
• Patch the affected runtime or vendor package as soon as a fixed release is available through official channels.
• Apply compensating controls immediately for untrusted archive extraction: disable hardlink extraction, run extraction in a sandbox, and normalize file ownership after extraction.
• Search application repositories and automation scripts for Tarfile.extract(), Tarfile.extractall(), and filter='data' usage to identify potentially exposed code paths.
• Ensure services that process archives do not run as root or with broad filesystem write permissions.
• Add archive validation controls that reject hardlinks, symlinks, device files, absolute paths, parent-directory traversal, and unexpected ownership metadata.
• Monitor archive-upload and extraction workflows for unusual tar files containing hardlink entries or ownership metadata such as uid/gid 0.
• Because the vulnerability is not in KEV, has no reported ransomware use, and has low EPSS, treat it as lower urgency than actively exploited remote-code-execution flaws, but remediate promptly where privileged extraction of untrusted archives exists.