The CVE describes a path traversal in Python's tarfile extraction filters, but the official framing obscures a more serious architecture failure. The security filters validate the final resolved path before writing files—but directory creation happens earlier, using the raw untrusted path string. This creates a fundamental gap: operations execute based on untrusted input that was never validated.
The 'only empty directories' qualifier in the CVE description is doing inappropriate mitigation work. Empty directories outside the extraction boundary are controlled filesystem mutations from untrusted input, enabling directory enumeration and leaking information about the host structure. More critically, in any deployment where archives extract to a predictable location rather than a randomized temp directory, attackers gain the ability to plant arbitrary directory structures accessible to that process. This isn't a minor artifact—it's a separation between what gets validated and what actually executes.
The stated safe condition—using randomized extraction—shifts the burden onto every caller to implement sandboxing the library was designed to provide. When developers read 'contained extraction' and 'security filters,' they assume the library handles untrusted archives safely. The actual contract is weaker: only the final file write is contained. This is a recurring pattern—this is at least the fifth documented instance of partial traversal containment failure since CVE-2001-1267, with each fix addressing output containment without tracing intermediate operations.
The EPSS score of 0.00324 reflects near-term exploitability, not architectural debt. For a standard library primitive, the real risk is the downstream attack surface across every Python application calling tarfile.extract()—not a single exploitation event. Exploit conditions shift; the underlying design flaw persists.
The proper fix isn't randomized extraction—it's normalizing paths before any filesystem operations execute. Windows collapses '..' before the filesystem sees it, which is why this entire vulnerability class doesn't exist there. The fix should make the security filter do what developers expect: trace every operation against the boundary, not just validate the terminal state.