Use-after-free

CVE-2026-6100 is a real memory-safety flaw in CPython's decompression paths: a MemoryError during lzma.LZMADecompressor, bz2.BZ2Decompressor, and in newer branches the internal zlib decompressor can leave a stale input pointer behind. If application code then reuses the same decompressor object after the exception, a later decompress() call can read or write through freed memory. The CVE record marks CPython versions < 3.15.0 as affected, with branch fixes landing for 3.14, 3.13, and 3.11; Debian also shows backports for selected distro packages.

In vendor scoring this was labeled CRITICAL in Python's advisory stream, and NVD now displays a PSF CVSS-B 9.1, but that overstates enterprise urgency. The deciding friction is not network reachability; it is the compound prerequisite chain: attacker-controlled compressed input, enough heap pressure to force MemoryError, application logic that catches the exception, and unsafe object reuse after failure. That is a narrow, code-pattern-specific exploit path, not a broad internet-scale wormable condition.

Why this verdict

• Downward adjustment: requires attacker-controlled decompression in app code — this is not a generic 'Python installed = remotely reachable' bug.
• Downward adjustment: requires MemoryError first — the attacker must create real memory pressure, which many gateways, quotas, and container limits disrupt before controlled exploitation.
• Downward adjustment: requires decompressor reuse after failure — this implies a specific coding anti-pattern, and many applications tear down request state or rebuild the object after exceptions.
• Downward adjustment: no KEV / no public exploitation evidence / low EPSS — there is no current threat-intel amplifier pushing this into emergency territory.
• Upward adjustment: memory corruption in ubiquitous runtime — when the bad pattern does exist on a network-facing Python service, impact can move beyond DoS into read/write corruption and potential code execution.

Why not higher?

Because this is not broadly reachable by default. The exploit chain depends on several compounding prerequisites that sharply reduce the exposed population: untrusted compressed input, induced memory pressure, exception survival, and object reuse. That is miles away from a one-request unauthenticated RCE.

Why not lower?

Because the underlying flaw is still memory corruption inside a widely deployed interpreter, not a harmless correctness bug. If an exposed Python service processes attacker-controlled compressed streams with long-lived decompressor objects, the impact ceiling is serious enough that this should stay above backlog-only hygiene.

1. Block or cap hostile compressed inputs — Enforce upload/body/decompression limits at the edge and in the app so attackers cannot easily manufacture the memory-pressure precondition. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but do this earlier on internet-facing parsers handling untrusted archives.
2. Kill decompressor reuse after exceptions — Audit code paths that keep LZMADecompressor, BZ2Decompressor, or gzip/zlib stateful objects alive across requests or chunks. If any decompression error or MemoryError occurs, discard the object and create a fresh one; implement this during normal engineering remediation, well before the 365-day patch window closes.
3. Prefer one-shot helper APIs — Where streaming semantics are unnecessary, use lzma.decompress(), bz2.decompress(), gzip.decompress(), or zlib.decompress() because the advisory explicitly says these are not affected. Roll this into secure-code cleanup during the same remediation cycle.
4. Monitor for precursor memory faults — Alert on worker OOMs, repeated MemoryError, crash loops, and abnormal decompression failures in Python services that ingest compressed content. This will not prove exploitation, but it gives you an early warning on the exact precondition chain this CVE needs.

Run this on the target host with the same interpreter used by the workload, for example: python3 cve_2026_6100_check.py or /opt/app/venv/bin/python cve_2026_6100_check.py. It needs no elevated privileges. The script performs a version-based assessment only; distro backports and custom vendor rebuilds may return UNKNOWN.

#!/usr/bin/env python3
# CVE-2026-6100 version-based checker for CPython
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import platform
import re
import sys


def parse_version(v):
    m = re.match(r'^(\d+)\.(\d+)\.(\d+)', v)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def out(state, msg, code):
    print(f"{state}: {msg}")
    sys.exit(code)


impl = platform.python_implementation()
raw_version = platform.python_version()
ver = parse_version(raw_version)
full = sys.version.replace('\n', ' ')

if impl != 'CPython':
    out('UNKNOWN', f'Interpreter is {impl}, not CPython; advisory scope differs by implementation. Version: {raw_version}', 2)

if ver is None:
    out('UNKNOWN', f'Could not parse Python version: {raw_version}', 2)

major, minor, patch = ver

# Known upstream-fixed thresholds confirmed from retrieved sources:
# - 3.14.5 includes gh-148395 in changelog
# - 3.15.0 and later are not affected per CNA lessThan 3.15.0
# Older maintained distro branches may be backported, but generic upstream
# version-only logic cannot verify that safely.

if (major, minor) >= (3, 15):
    out('PATCHED', f'CPython {raw_version} is not affected by the CNA range (< 3.15.0).', 0)

if (major, minor) == (3, 14):
    if patch >= 5:
        out('PATCHED', f'CPython {raw_version} is at or above 3.14.5, which includes the gh-148395 fix.', 0)
    out('VULNERABLE', f'CPython {raw_version} is below 3.14.5.', 1)

# For 3.13/3.12/3.11/3.10/3.9 and vendor-packaged Python builds, backports vary.
# Debian and enterprise distros have issued backported fixes without uniform
# upstream version numbers we can trust from platform.python_version() alone.
if (major, minor) in {(3, 13), (3, 12), (3, 11), (3, 10), (3, 9)}:
    msg = (
        f'CPython {raw_version} may be vulnerable unless your vendor backported the fix. '
        f'Python version string alone is insufficient to verify this build. sys.version={full}'
    )
    out('UNKNOWN', msg, 2)

if major < 3:
    out('UNKNOWN', f'Legacy Python {raw_version}; check vendor advisory/backports manually. sys.version={full}', 2)

out('UNKNOWN', f'Unrecognized CPython branch {raw_version}. sys.version={full}', 2)

Sources

1. NVD CVE detail
2. Openwall oss-security forwarding Python advisory
3. CPython issue #148395
4. CPython fix commit for 3.14 branch
5. CPython fix commit for 3.13 branch
6. CPython fix commit for 3.11 branch
7. Debian security tracker
8. CISA Known Exploited Vulnerabilities Catalog