CVE-2026-6100: Python Decompressor Use-After-Free Flaw

CVE-2026-6100 Overview

CVE-2026-6100 is a critical use-after-free (UAF) vulnerability affecting Python's compression/decompression modules, specifically lzma.LZMADecompressor, bz2.BZ2Decompressor, and gzip.GzipFile. The vulnerability occurs when a memory allocation fails with a MemoryError during decompression operations and the decompressor instance is subsequently reused. This scenario is most likely to occur when a system is under significant memory pressure.

When a MemoryError is raised during decompression, the affected modules fail to properly clean up internal pointers, leaving dangling references to freed memory. If the decompressor instance is then reused for another decompression call, the code may access the freed memory, leading to potential arbitrary code execution or memory corruption.

Critical Impact

Attackers can potentially achieve remote code execution by exploiting the use-after-free condition when Python applications reuse decompressor instances after memory allocation failures.

Affected Products

• Python CPython - lzma.LZMADecompressor module
• Python CPython - bz2.BZ2Decompressor module
• Python CPython - gzip.GzipFile module

Discovery Timeline

• April 13, 2026 - CVE-2026-6100 published to NVD
• April 14, 2026 - Last updated in NVD database

Technical Details for CVE-2026-6100

Vulnerability Analysis

This use-after-free vulnerability (CWE-416) exists in Python's core decompression functionality. The issue stems from improper memory management when handling error conditions during decompression operations. When the Python runtime encounters a MemoryError during the decompression process, the internal state of the decompressor object becomes corrupted because the code fails to properly nullify pointers to deallocated memory buffers.

The vulnerability is particularly concerning because it affects three widely-used compression libraries in the Python standard library. Applications that implement streaming decompression patterns—where a single decompressor instance handles multiple chunks of compressed data—are at heightened risk if they attempt error recovery by reusing the decompressor after a memory failure.

It's important to note that applications using the one-shot helper functions such as lzma.decompress(), bz2.decompress(), gzip.decompress(), and zlib.decompress() are not affected, as these functions create a new decompressor instance for each call.

Root Cause

The root cause is a failure to properly clean up internal state when memory allocation errors occur during decompression. When the Python runtime cannot allocate sufficient memory for the output buffer, the decompressor object retains pointers to memory that has been freed or was never properly allocated. The fix addresses this by ensuring dangling pointers are properly nullified in this specific error condition, preventing subsequent use of invalid memory references.

Attack Vector

The attack vector is network-based, requiring an attacker to trigger memory pressure conditions on a target system running a Python application that reuses decompressor instances. The attack scenario involves:

1. Identifying a Python application that uses streaming decompression with reused decompressor instances
2. Sending specially crafted compressed data that, combined with memory pressure, triggers a MemoryError
3. Continuing to send data to the application after the error, causing the reused decompressor to access freed memory
4. Exploiting the memory corruption to achieve code execution

The vulnerability manifests in the decompressor's error handling path when memory allocation fails. When a MemoryError is raised, internal buffer pointers are not properly cleaned up, leaving dangling references. If the decompressor instance is subsequently reused, these dangling pointers are dereferenced, potentially allowing an attacker to execute arbitrary code or corrupt memory. See the GitHub Issue #148395 for detailed technical analysis.

Detection Methods for CVE-2026-6100

Indicators of Compromise

• Unexpected Python process crashes with memory-related errors during decompression operations
• Application logs showing repeated MemoryError exceptions followed by abnormal behavior in compression-related code paths
• Unusual memory access patterns or segmentation faults in Python applications handling compressed data

Detection Strategies

• Monitor Python applications for MemoryError exceptions in decompression contexts, especially when followed by continued decompressor usage
• Implement application-level logging around decompressor instance creation and reuse patterns
• Use memory sanitizers (ASan, MSan) in development environments to detect use-after-free conditions during testing

Monitoring Recommendations

• Deploy runtime application monitoring to detect unusual exception patterns in compression-handling code
• Configure alerting for segmentation faults or memory corruption signals in Python processes handling compressed network data
• Review application code for patterns that reuse decompressor instances after catching exceptions

How to Mitigate CVE-2026-6100

Immediate Actions Required

• Update Python to a patched version that includes the security fixes for this vulnerability
• Review application code for decompressor instance reuse patterns, particularly around error handling
• Modify applications to create new decompressor instances rather than reusing existing ones after any error condition
• Consider using the one-shot decompression functions (lzma.decompress(), bz2.decompress(), gzip.decompress()) where practical

Patch Information

The Python development team has released patches addressing this vulnerability across multiple commits. The fixes ensure that dangling pointers are properly cleaned up when memory allocation fails during decompression. Organizations should update to patched Python versions as soon as they become available.

Relevant patch commits:

• GitHub CPython Commit 47128e64
• GitHub CPython Commit 6a5f79c8
• GitHub CPython Commit 8fc66aef
• GitHub CPython Commit c3cf71c3
• GitHub CPython Commit e20c6c96

Additional resources:

• GitHub Pull Request #148396
• Python Security Announce Thread

Workarounds

• Replace streaming decompression patterns with one-shot decompression using lzma.decompress(), bz2.decompress(), or gzip.decompress() functions
• Implement defensive coding practices that create new decompressor instances for each decompression operation rather than reusing existing instances
• Add exception handling that explicitly discards and recreates decompressor instances after any error, including MemoryError
• Consider implementing memory limits or resource constraints to reduce the likelihood of memory pressure conditions that trigger the vulnerability

# Safe decompression pattern - create new instance after any error
import lzma

def safe_streaming_decompress(compressed_chunks):
    """Safe pattern: never reuse decompressor after error"""
    decompressor = lzma.LZMADecompressor()
    results = []
    
    for chunk in compressed_chunks:
        try:
            results.append(decompressor.decompress(chunk))
        except MemoryError:
            # Critical: discard the decompressor and create a new one
            decompressor = lzma.LZMADecompressor()
            raise  # Re-raise to let caller handle the error
    
    return b''.join(results)