CVE-2026-11972: 
Python Interpreter vulnerability analysis and mitigation

CVE-2026-11972 is a Denial of Service vulnerability in Python's tarfile standard library module affecting CPython versions prior to 3.15.0 (with backports needed for 3.10–3.14). When a tar archive is opened in streaming mode (mode="r|") and the tarfile._Stream.seek() method is called, it fails to check the return value of read() and does not break out of its loop upon reaching EOF. This allows a malformed archive with a declared-but-absent large file to cause the parser to spin in an effectively infinite loop. The vulnerability was disclosed on June 23, 2026, and carries a CVSS v4.0 base score of 8.2 (High), assigned by the Python Software Foundation (GitHub Advisory, CPython Issue).

The root cause lies in the tarfile._Stream.seek() method in Lib/tarfile.py, which computes the number of blocks to read in order to advance the stream position, then iterates through them without checking whether read() returns empty data (i.e., EOF). The relevant CWEs are CWE-252 (Unchecked Return Value), CWE-606 (Unchecked Input for Loop Condition), and CWE-770 (Allocation of Resources Without Limits or Throttling). An attacker can craft a tar archive header declaring an extremely large file size (e.g., tinfo.size = 1 << 64) but providing no actual data; when the streaming-mode parser attempts to seek past this entry, it enters a loop reading zero-byte blocks indefinitely. The fix, merged in PR #151982, adds a check if not data: break inside the seek loop (CPython PR, CPython Issue).

Successful exploitation causes the affected Python process to enter an infinite (or extremely long) CPU-consuming loop, resulting in a complete denial of service for any application that processes untrusted tar archives in streaming mode. There is no impact on confidentiality or data integrity — the vulnerability is purely an availability issue. Services that accept user-supplied tar archives (e.g., upload handlers, CI/CD pipelines, backup tools) are at greatest risk of being hung or crashed, potentially requiring manual intervention to restore service (GitHub Advisory).

1. Identify a target application: Find a Python application that accepts user-supplied tar archives and processes them using tarfile.open() in streaming mode (mode="r|" or mode="r|gz", etc.).
2. Craft a malicious archive: Create a tar archive header for a file with an extremely large declared size (e.g., tinfo.size = 1 << 64) but write no actual file data — only the header block.
3. Submit the archive: Upload or otherwise deliver the malformed archive to the target application's tar-processing endpoint or function.
4. Trigger the infinite loop: When the application calls tar.getmembers() or iterates over the archive, tarfile._Stream.seek() attempts to advance past the declared file size by reading blocks in a loop, but since no data exists, each read() returns empty bytes without breaking the loop, causing the process to hang indefinitely and consume CPU resources (CPython Issue, CPython PR).

• Process: Python process with 100% CPU utilization that does not terminate; process stack traces showing repeated calls within tarfile._Stream.seek() or tarfile._Stream.read().
• Logs: Application-level timeouts or watchdog alerts triggered during tar archive processing; absence of completion log entries for archive parsing operations that were initiated.
• File System: Presence of unusually small or malformed .tar, .tar.gz, .tar.bz2, or .tar.xz files submitted by external users that contain headers with implausibly large file sizes but minimal actual data.
• Network: Repeated submission of small archive files (a few hundred bytes) to upload or processing endpoints, particularly if followed by service unresponsiveness.

The Python Software Foundation has released patches backported to all actively maintained branches: CPython 3.10 (commit eb63c0f), 3.11 (commit 7f0dc59), 3.12 (commit e86666c), 3.13 (commit 3f031d4), 3.14 (commit e86666c), and 3.15 (commit 4ce6bf7). Users should upgrade to patched releases of their respective Python branch as soon as they become available. As an interim workaround, avoid using tarfile in streaming mode (mode="r|") when processing archives from untrusted sources; implement application-level timeouts around tarfile parsing operations; and validate or size-limit submitted archives before processing (CPython PR, GitHub Advisory).

Red Hat issued security advisories (RHSA-2026:35806 and RHSA-2026:35812) addressing this vulnerability in their products, and the Yocto Project security mailing list discussed it in the context of embedded Linux distributions. The vulnerability was also tracked by the OSV database (PSF-2026-31) and Debian. Community reaction has been relatively muted given the absence of active exploitation, though the issue was flagged as a security concern during code review, prompting its classification under the Security news directory in CPython's changelog.