External risk intelligence

Python Decompressor Reuse Use-After-Free Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-6100

The vulnerability resides in low-level compression libraries within the Python standard library. It requires specific, non-standard implementation patterns—specifically the reuse of decompressor objects after a memory error. While these libraries can be used in internet-facing applications, the flaw is not exposed by default and requires unusual application-level logic to manifest.

Use After Free

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This vulnerability affects Python's compression libraries, specifically when handling memory errors during decompression. If a decompressor instance is reused after a memory allocation failure, it could lead to a use-after-free condition, potentially impacting system stability or security. The issue is triggered under specific memory pressure scenarios and requires a particular pattern of library use.

Flaw in Python compression libraries.
Requires specific reuse after error.
Confirm relevance and exposure.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by causing a memory allocation failure during decompression, then reusing the same decompressor instance. This scenario is more likely when the system is under memory pressure. If successful, the vulnerability could allow for code execution.

Entry: Re-use decompressor after error.
Trigger: Memory allocation fails during decompression.
Risk: Potential for code execution.

Live Threat

Current exploitation, exposure, and threat context

A use-after-free vulnerability could arise in specific Python decompression modules if memory allocation fails and the decompressor instance is subsequently reused. This condition is only possible under memory pressure when decompressor instances are re-used across multiple decompression calls after a `MemoryError`.

Decompressor instance memory
Re-use after memory error
Potential for program instability

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts applications that re-use Python's `lzma`, `bz2`, or `gzip` decompressor objects after a memory allocation failure. Identifying where these specific decompressor patterns are used, assessing their reachability and criticality, and then engaging the responsible development or platform teams for remediation planning is the immediate first step.

Application owners should manage the issue.
Verify decompressor reuse after memory errors.
Plan remediation based on identified risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the software affected by CVE-2026-6100?

This vulnerability affects specific modules within the Python standard library, namely lzma, bz2, and gzip. Developers use these built-in tools to handle data compression and decompression tasks within their applications. The issue involves how these components manage memory internally when processing data.

What is the weakness class behind this vulnerability?

CVE-2026-6100 involves a use-after-free weakness (CWE-416). In plain terms, this happens when a program continues to use a pointer to a memory location after that memory has been freed or invalidated. In this case, the error occurs if a compression object hits a memory allocation failure and the program incorrectly tries to use that same object again.

How is this vulnerability triggered in an application?

The flaw triggers only if an application creates a decompressor instance and explicitly reuses it after a MemoryError has already occurred during a previous decompression attempt. It is not triggered if you use one-shot helper functions like lzma.decompress() or gzip.decompress(), which create fresh instances each time. Furthermore, if the decompressor is discarded rather than reused after an error, the code remains safe.

Is my system at risk according to Halo Surface Signal?

Halo Surface Signal indicates that this vulnerability is unlikely to be exploitable in most environments. While the libraries are common, the flaw is not exposed by default. It requires an unusual, specific application-level pattern—reusing a failed decompressor instance—which typically does not occur in standard or well-written programs.

What should I do if I run Python applications?

First, identify if your custom code or third-party dependencies instantiate and persist decompressor objects across multiple calls. If your application handles high-stress scenarios where MemoryErrors might occur, verify that your error handling logic discards or resets these instances immediately upon failure instead of attempting to reuse them. Consult with your development team to audit these specific object patterns.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.