CVE-2026-9669

What it actually does

This is a buffer overflow in applications that use bz2.BZ2Decompressor to process untrusted bzip2-compressed input. After a decompression error, the decompressor object can remain in an invalid internal state. If application code catches the OSError and retries decompression using that same object, attacker-controlled input can cause out-of-bounds writes to a stack buffer. The described impact is process crash and denial of service; there is no indicated confidentiality or integrity impact in the provided scoring, and exploitation requires a specific retry pattern in the application.

Why it matters to the business

An exposed service, API, worker, ingestion pipeline, file-processing feature, or messaging component that accepts compressed data could be crashed by a crafted payload, disrupting availability. Because exploitation requires uncommon application behavior and there is no known public exploit or KEV listing, broad emergency response is not indicated, but internet-facing or business-critical systems that decompress untrusted bzip2 data should be prioritized.

How an attack unfolds

An attacker first identifies an application path that accepts bzip2-compressed content and processes it with bz2.BZ2Decompressor. They send malformed compressed data designed to trigger a decompression OSError. The attack only proceeds if the application catches that exception and retries decompression using the same decompressor instance rather than creating a fresh object. Under those conditions, the decompressor resumes from corrupted internal state and writes outside the bounds of a stack buffer, typically terminating the process. No active exploitation, ransomware use, or named threat actor activity is indicated by the provided intelligence.

How to fix it

Upgrade to a vendor-fixed runtime or library version when available for the affected platform. No exact fixed versions were provided in the input, so consult the relevant language/runtime and operating-system vendor advisories for patched releases. As a defensive coding mitigation, never reuse a bz2.BZ2Decompressor instance after any decompression error; discard it and create a new decompressor object. For services that accept compressed content, enforce input size limits, decompression timeouts, request rate limits, sandboxing, worker isolation, and automatic process restart. If bzip2 support is not required on externally supplied data, disable or reject bzip2-compressed uploads and messages.

How to confirm the fix worked

Confirm that deployed runtimes and packages are at vendor-fixed versions once advisories provide them. Review code paths that use bz2.BZ2Decompressor and verify that decompressor objects are not reused after OSError or any decompression failure. Add regression tests using malformed bzip2 input to ensure the application returns a controlled error and does not retry with the same decompressor instance or crash. For exposed services, perform safe negative testing in a non-production environment with invalid bzip2 payloads and confirm process stability, logging, and graceful error handling.

Typical attack path

1. Find an exposed application feature that accepts or retrieves bzip2-compressed data from untrusted sources.
2. Submit crafted malformed bzip2 input that causes a decompression OSError.
3. Rely on application error-handling logic that catches the error and retries using the same bz2.BZ2Decompressor object.
4. Trigger decompression from an invalid internal state.
5. Cause an out-of-bounds stack write, resulting in a crash or service disruption.

How to detect it

Look for signs of attempted exploitation in application logs, crash telemetry, process supervisors, container restart events, and operating-system logs. Useful patterns include repeated bzip2 decompression errors followed by process termination, segmentation faults, core dumps, container restarts, worker deaths, or sudden 5xx spikes on endpoints that accept compressed uploads or messages. Correlate malformed or failed bzip2 processing events with source IPs, user agents, authenticated users, filenames, object keys, queue message IDs, or request IDs. If core dumps are available, inspect stack traces for bz2 or decompression-related frames. Absence of these artifacts does not prove safety because many applications suppress decompression exceptions or disable core dumps.

• bz2.BZ2Decompressor
• OSError
• Invalid data stream
• Data integrity error when decompressing data
• Compressed file ended before the end-of-stream marker was reached
• Segmentation fault
• SIGSEGV
• core dumped
• BZ2_bzDecompress
• bzip2

What your security team should do

• Inventory services, APIs, batch jobs, and ingestion pipelines that process bzip2-compressed data from users, partners, queues, object storage, email, or the internet.
• Prioritize internet-facing and business-critical components that use bz2.BZ2Decompressor or equivalent runtime bindings.
• Ask engineering teams to patch the runtime/library when fixed versions are available from the vendor.
• Implement an immediate code-level mitigation: discard decompressor objects after any decompression exception and instantiate a new object for retries.
• Add resource limits and isolation around decompression workers to reduce denial-of-service impact.
• Monitor for repeated decompression exceptions followed by process crashes, especially from the same source IP, user, file, queue message, or upload path.
• Because EPSS is low, the issue is not in KEV, and exploit maturity is listed as none, handle through prioritized patch management rather than emergency incident response unless affected systems are exposed and critical.