CVE-2025-4517: Python tar extraction flaw allows file writes past path filters

A write-up on dev.to examines CVE-2025-4517, a critical arbitrary-file-write vulnerability in Python's tar extraction, and argues that verifying the fix takes more than checking a single interpreter on the build host.

How the filter is defeated

According to the post, the extraction check resolves each archive member's destination using os.path.realpath. A sufficiently long chain of symlinks can push the resolved path past a platform limit, at which point realpath returns an incorrect path. The filter can then accept a member that actually escapes the extraction directory, even when the application already uses the data or tar extraction filters intended to enforce the path boundary.

The fix, the post explains, normalizes link targets and switches to a strict resolution mode that allows missing paths. The work is referenced as CPython issue 135034 in the post's citations.

Fixed releases

The Python project published patched builds across six branches, the post states: 3.9.23, 3.10.18, 3.11.13, 3.12.11, 3.13.4 and 3.14.0b1. The practical consequence is that every deployment needs to be mapped to the specific branch and artifact it actually runs, rather than assumed to be current.

Verifying what actually runs

The central argument of the post is that a patched host interpreter offers no protection when a worker container still ships an older CPython build. The recommended inventory covers base images, sidecars, job images and packaged applications that embed Python, recording for each the image digest, branch, patch release and the source of the interpreter. A package metadata query issued from the build host is explicitly called out as insufficient on its own.

At runtime, the author advises printing the interpreter version from inside the container and confirming the code path the archive job actually exercises. Derived images should be rebuilt after their base image is updated. Applications that vendor CPython should be rebuilt from the fixed source, with build attestations preserved.

Limited exposure data

To gauge exposure, the author queried ZoomEye with app="Python" and received 60,035 matches, while a CVE-specific query returned zero. The post draws a sober conclusion from that gap: fingerprint coverage helps with discovery, but it cannot distinguish a service that actually parses attacker-supplied archives from an unrelated Python service, so raw match counts say little about real risk.

Interim mitigations

Until patched runtimes are deployed everywhere, the post recommends rejecting archive links that contain "..", inspecting archive members before extraction, and preventing worker processes from writing into application or credential paths.

Final verification should involve a crafted long-link archive tested against the deployed service in an isolated environment. The post also defines what a validation record should contain: the image digest, the running interpreter version, the extraction entry point and the test result. Its closing point is that a successful build with no runtime check does not close the issue.

Why it matters

Tar extraction has long been a recurring source of path-traversal bugs, and this one is notable because it defeats the data and tar filters that developers adopted precisely to contain such risks. Anyone unpacking untrusted archives — upload handlers, CI artifact pipelines, package mirrors — cannot assume their filter choice makes them safe on an unpatched interpreter.

The operational lesson is equally important: Python runtimes live in many places at once, from base images to sidecars to vendored builds. Patching the machine you can see is not the same as patching the fleet, and the only trustworthy check is one performed inside the container that actually does the work.