CVE-2026-7774

What it actually does

The flaw is a path traversal bypass in Python-style tar archive extraction when tarfile.extractall() is used with tarfile.data_filter. A malicious archive can include crafted hard link or symbolic link entries, including empty or directory-like link names, that alter how later archive members are resolved. As a result, files that appear to be constrained to the intended extraction directory can be written outside that directory with the privileges of the process performing extraction. The impact is primarily unauthorized file write; depending on what paths are writable, this can enable configuration tampering, application file replacement, persistence, or code execution when overwritten files are later loaded or executed.

Why it matters to the business

Organizations that accept or process untrusted tar archives could have files overwritten outside the expected upload or extraction location. This can disrupt applications, corrupt data, alter configuration, or create a path to code execution if an attacker can place files where the application or operating system will later use them. The current EPSS value is low and the issue is not listed in CISA KEV, but the bug is straightforward to trigger in vulnerable archive-processing workflows and should be prioritized anywhere archives are accepted from users, partners, package feeds, CI/CD jobs, or automated ingestion pipelines.

How an attack unfolds

An attacker prepares a tar archive with a sequence of entries designed to manipulate extraction path resolution. The archive includes crafted link entries, such as symlinks with empty, ambiguous, or directory-like names, so that subsequent archive members are redirected outside the extraction root even though a data filter is in use. The attacker then causes a vulnerable service, script, build job, import function, or administrative tool to call tarfile.extractall() on that archive. If the extracting process has permission to write to the targeted external path, the archive writes attacker-controlled content outside the intended destination. The attacker’s practical outcome depends on the target path: overwriting application files may change behavior, writing configuration may weaken security controls, placing files in startup or plugin locations may create persistence, and replacing code or templates may lead to execution during later normal operations.

How to fix it

Upgrade the affected runtime or library version once the vendor-provided fix is available for the platform in use. No exact fixed versions were provided in the input, so remediation teams should consult the relevant Python/runtime, operating system package, container base image, or distribution advisory and deploy the patched package across all systems that process tar archives. As defense in depth, avoid extracting untrusted tar archives with tarfile.extractall() unless using a corrected implementation and strict validation. Extract archives into a newly created, dedicated directory with least-privileged permissions; reject symlinks, hard links, absolute paths, empty names, parent-directory components, device nodes, and entries whose resolved canonical path is outside the extraction root; and perform path validation after link resolution, not just string normalization. Run archive extraction in a sandbox or container with no access to sensitive host paths, and avoid running extraction as a privileged user.

How to confirm the fix worked

Confirm that all runtimes, distribution packages, and container images used for archive extraction have been updated to a vendor version that includes the tarfile.data_filter bypass fix. Inventory code paths that call tarfile.extractall(), especially those that process uploaded, downloaded, or partner-supplied tar archives, and verify they either use a patched implementation or enforce independent safe-extraction checks. Test representative systems with a benign proof-of-concept tar archive designed to attempt an outside-directory write and confirm that extraction is blocked and no file is created outside the target directory. Validate sandboxing by confirming the extraction process cannot write to application directories, startup locations, system configuration paths, or other sensitive destinations.

Typical attack path

1. Identify an application, automation job, or service that accepts or retrieves tar archives from an untrusted or semi-trusted source.
2. Craft a tar archive containing malicious link entries that bypass tarfile.data_filter path restrictions.
3. Place subsequent archive members in the tar so they resolve through the crafted link outside the intended extraction directory.
4. Submit, upload, or otherwise cause the vulnerable workflow to process the archive with tarfile.extractall().
5. Rely on the privileges of the extracting process to write attacker-controlled files to an external writable path.
6. Trigger or wait for the overwritten file to be consumed, loaded, executed, or used by the application or host.

How to detect it

Look for evidence that archive extraction created or modified files outside expected extraction directories. Useful sources include application upload/import logs, job runner logs, CI/CD logs, file integrity monitoring, endpoint detection telemetry, auditd or equivalent filesystem audit logs, container runtime logs, and object-storage access logs for submitted archives. Hunt for tar extraction activity followed by writes to application code directories, configuration directories, service startup paths, cron/systemd locations, web roots, plugin directories, SSH authorized_keys files, or other sensitive paths that are not normal extraction destinations. Review suspicious archives for unusual tar metadata such as symlink or hard-link entries, empty names, names that resolve to directories, absolute paths, parent-directory components, and later entries that rely on earlier links. Because no public exploit maturity or named threat actor activity was provided, detection should focus on anomalous file-write behavior and malicious archive structure rather than actor-specific indicators.

What your security team should do

• Prioritize patching internet-facing, user-facing, CI/CD, package-processing, and automated ingestion systems that extract tar archives from untrusted sources.
• Create an inventory of applications, scripts, build jobs, and services that call tarfile.extractall() or equivalent tar extraction wrappers.
• Temporarily disable or quarantine tar archive ingestion from untrusted sources where immediate patching is not possible.
• Add application-level safeguards that reject symlinks, hard links, absolute paths, empty path names, parent-directory traversal, and any entry resolving outside the extraction directory.
• Run archive extraction under a dedicated low-privilege account inside a sandboxed working directory with no write access to application code, configuration, credential, or startup paths.
• Review recent archive uploads and extraction activity for unexpected writes outside normal extraction directories.
• Add regression tests for malicious tar link/path cases to prevent reintroduction of unsafe extraction behavior.