CVE-2026-6100

What it actually does

This is a use-after-free condition in Python decompression objects used by lzma.LZMADecompressor, bz2.BZ2Decompressor, and gzip.GzipFile. If decompression encounters a memory allocation failure and raises MemoryError, the affected object may retain a dangling internal pointer. Programs that continue to reuse that same decompressor instance after the error can trigger unsafe memory access. In a favorable exploitation scenario, this could lead to memory corruption affecting confidentiality or integrity of the running process. Exploitation is constrained because the attacker must influence compressed input, cause or coincide with memory pressure, and rely on application behavior that reuses a decompressor object after MemoryError. One-shot helper functions such as lzma.decompress(), bz2.decompress(), gzip.decompress(), and zlib.decompress() are not affected because they create a fresh decompression object per call.

Why it matters to the business

Applications that process attacker-supplied compressed data with long-lived decompressor objects could be exposed to process compromise or data corruption under specific memory-pressure conditions. The practical risk is lower than many remotely reachable memory corruption flaws because exploitation requires an unusual error-handling pattern and memory allocation failure, EPSS is low, the issue is not in CISA KEV, and no public exploit maturity is reported. However, services that ingest compressed uploads, archives, telemetry, backups, messages, or API payloads at scale should treat this as a meaningful hardening issue because those systems are more likely to encounter untrusted compressed content and memory pressure.

How an attack unfolds

An attacker targets an application that accepts compressed data and uses one of the affected Python decompression classes directly rather than the one-shot decompression helper functions. The attacker sends crafted or oversized compressed input intended to consume memory or to arrive when the process is already under memory pressure. During decompression, a memory allocation fails and Python raises MemoryError. The vulnerable condition becomes reachable only if the application catches or otherwise survives that exception and later reuses the same decompressor instance. On reuse, the object may reference freed memory, creating a use-after-free condition. Depending on allocator behavior, surrounding heap state, and process protections, this may result in a crash, incorrect decompression behavior, memory disclosure, or corruption of process memory. Reliable exploitation is expected to be difficult because it depends on memory pressure, error handling, decompressor reuse, and heap layout.

How to fix it

Upgrade Python or the affected runtime distribution to a vendor release that includes the fix for this issue. No exact fixed versions were provided in the input, so use the fixed packages published by the operating system, language runtime vendor, container base image maintainer, or Python distribution in use. Rebuild and redeploy containers, virtual environments, serverless layers, embedded runtimes, and packaged applications that bundle Python. As a code-level mitigation, do not reuse instances of lzma.LZMADecompressor, bz2.BZ2Decompressor, or gzip.GzipFile after MemoryError or other fatal decompression errors; discard the object and create a new decompressor instance. Prefer one-shot helper APIs such as lzma.decompress(), bz2.decompress(), gzip.decompress(), or zlib.decompress() where appropriate. Add limits for compressed input size, decompressed output size, decompression ratio, request body size, and per-process memory consumption. Isolate decompression of untrusted content in worker processes where possible so failures can be safely terminated and restarted.

How to confirm the fix worked

Confirm that all Python runtimes, base images, OS packages, application bundles, and virtual environments have been updated to a release containing the vendor fix. Review dependency and container inventories for older Python builds that may be statically bundled or copied into application images. Inspect application code for direct use of lzma.LZMADecompressor, bz2.BZ2Decompressor, and gzip.GzipFile, especially patterns that retain decompressor objects across requests, files, messages, or retries. Verify that exception handling discards decompressor instances after MemoryError and creates a new instance for later work. Exercise regression tests that simulate decompression failures and memory-pressure conditions to confirm objects are not reused after failure. For externally exposed services, confirm request size limits, decompression ratio limits, and resource isolation controls are active.

Typical attack path

1. Identify a service or workflow that accepts attacker-controlled compressed data, such as uploads, API payloads, message attachments, archives, logs, or backup streams.
2. Determine or infer that the application uses lzma.LZMADecompressor, bz2.BZ2Decompressor, or gzip.GzipFile as a reusable object across multiple decompression operations.
3. Send compressed input designed to increase memory consumption or wait for naturally high memory pressure in the target process.
4. Trigger a decompression operation that fails with MemoryError.
5. Rely on the application continuing execution and reusing the same decompressor instance after the MemoryError.
6. Trigger subsequent decompression activity against the stale object to exercise the dangling pointer.
7. Attempt to convert the resulting memory corruption into process manipulation, information exposure, or integrity impact.

How to detect it

There are no known public exploit indicators or reported threat actors for this issue based on the provided data. Detection should focus on suspicious preconditions and post-exploitation symptoms rather than a definitive signature. Review application logs, Python exception logs, web/API access logs, upload-processing logs, message-consumer logs, crash reports, core dumps, container restart events, and endpoint telemetry for repeated MemoryError exceptions during lzma, bz2, or gzip processing. Correlate these events with requests or files from the same source, unusually large compressed inputs, high compression-ratio payloads, repeated decompression failures, abnormal worker memory growth, segmentation faults, corrupted output, or unexpected process behavior. If crashes occurred, preserve core dumps and memory artifacts and examine whether the stack trace involves Python decompression modules or gzip file handling after a prior MemoryError. Because successful exploitation may not leave a stable on-disk artifact, absence of IOCs does not rule out attempted exploitation.

What your security team should do

• Prioritize patching Python runtimes used by internet-facing services or workloads that process untrusted compressed data.
• Inventory applications that directly instantiate lzma.LZMADecompressor, bz2.BZ2Decompressor, or gzip.GzipFile instead of one-shot helper functions.
• Review decompression error handling and ensure decompressor objects are discarded after MemoryError or other fatal decompression exceptions.
• Apply defensive limits on compressed input size, decompressed output size, decompression ratios, and worker memory usage.
• Rebuild container images and redeploy applications so patched language runtimes are actually in use.
• Monitor for repeated MemoryError events in decompression paths, especially when correlated with external uploads, API requests, or message ingestion.
• Treat suspicious decompression-related crashes or MemoryError bursts as potential probing even though no known exploitation or KEV listing is currently reported.