CVE-2026-9375

What it actually does

The flaw is a denial-of-service vulnerability in urllib3 2.6.3 when Brotli decompression is used through the streaming API with `preload_content=False`. Multiple decompression paths in `response.py` fail to enforce the intended `max_length` limit: buffer arithmetic can produce negative limits, decoder flushing can force an unlimited value, and one flush path omits a limit entirely. A malicious HTTP server can return a small Brotli-compressed response that expands to a very large payload during streaming, causing the client process to allocate excessive memory and potentially terminate with an out-of-memory condition. The impact is availability loss only; it does not directly provide code execution or data disclosure.

Why it matters to the business

Applications, services, automation jobs, security scanners, data importers, package clients, integrations, or libraries that fetch streamed HTTP content from untrusted or attacker-controlled servers may crash or be restarted repeatedly. This can disrupt background processing, ingestion pipelines, API integrations, monitoring tasks, and user-facing services that rely on Python HTTP clients. The risk is heightened where applications automatically fetch URLs supplied by users, third parties, feeds, webhooks, crawlers, or external APIs. Although the EPSS score is currently low and there is no known KEV listing or reported ransomware use, exploitation is network-accessible, requires no authentication, and can be triggered by a malicious server response.

How an attack unfolds

An attacker first needs a target application that uses urllib3 2.6.3 with Brotli support and streams HTTP responses using `preload_content=False`. The attacker then causes that application to request an attacker-controlled or compromised HTTP endpoint, for example through a user-supplied URL, webhook callback, feed ingestion source, crawler target, integration endpoint, or dependency that retrieves remote content. The malicious server replies with a Brotli-compressed response that advertises Brotli encoding and contains compressed data designed to expand to a very large size. Because vulnerable streaming decompression paths fail to apply the intended maximum output length, the client decompresses without an effective bound. Memory usage grows rapidly until the Python process raises memory errors, is terminated by the operating system OOM killer, or becomes unavailable due to resource exhaustion.

How to fix it

Upgrade urllib3 to a version that explicitly fixes this decompression limit bypass as soon as a fixed release is available from the project or your distribution vendor. If exact fixed versions are not yet available, apply compensating controls immediately: avoid using urllib3 2.6.3 with Brotli support for untrusted streaming responses; disable Brotli decoding where not required; avoid `preload_content=False` for untrusted sources unless strict application-level read limits are enforced; cap maximum response sizes before and after decompression; apply timeouts and memory/resource limits to worker processes or containers; and restrict outbound requests to trusted destinations where possible. Review transitive dependencies that bundle or call urllib3/requests-like HTTP streaming functionality, because the vulnerable behavior may be reachable through higher-level libraries.

How to confirm the fix worked

Confirm package inventory and runtime dependency resolution rather than relying only on lockfiles. Check deployed Python environments for urllib3 2.6.3 and installed Brotli support, including `brotli` or `brotlicffi`. Review code and dependency usage for streaming requests using `preload_content=False`, `stream=True`, direct `HTTPResponse.read()` usage, or ingestion of externally controlled URLs. Validate remediation by running a controlled test against a benign Brotli-compressed large-expansion response and confirming the client enforces size limits, fails safely, or rejects the response without excessive memory growth. Monitor memory usage during the test and confirm the process is not killed or restarted. Where a vendor fix has been applied, verify the installed urllib3 version at runtime using package metadata and application startup logs.

Typical attack path

1. Identify or induce a Python application to fetch streamed HTTP content from an attacker-controlled or compromised URL.
2. Ensure the target code path uses urllib3 2.6.3, Brotli support, and streaming mode with `preload_content=False`.
3. Serve an HTTP response with Brotli compression, typically including `Content-Encoding: br`.
4. Return a compressed payload that expands to a very large decompressed output.
5. Trigger vulnerable decoder flush/read paths that bypass or disable `max_length` enforcement.
6. Exhaust process or host memory, causing `MemoryError`, process termination, container restart, service crash, or degraded availability.

How to detect it

Look for evidence of availability attacks against Python services that perform outbound HTTP streaming. Relevant sources include application logs, dependency/debug logs from urllib3 or HTTP clients, reverse proxy or egress proxy logs, DNS logs, EDR telemetry, container orchestration events, kernel logs, and cloud workload metrics. Focus on sequences where a service makes an outbound request to an unusual or attacker-controlled host, receives a Brotli-encoded response, and then shows rapid memory growth, `MemoryError`, process termination, container OOM events, or repeated restarts. In Linux environments, review `dmesg`, `journalctl`, syslog, Kubernetes events, and container runtime logs for OOM-killer messages tied to Python processes. In application logs, search for exceptions or stack traces involving `urllib3.response`, Brotli decoding, streaming response reads, or abrupt worker termination. Network logs may show suspicious responses with `Content-Encoding: br`, unusually high decompressed-to-compressed size behavior if content inspection is available, or repeated requests to the same external endpoint followed by crashes. Because this vulnerability does not create a unique file artifact or persistent implant, detection is primarily behavioral and correlation-based.

• urllib3==2.6.3
• Content-Encoding: br
• preload_content=False
• stream=True
• MemoryError
• Out of memory: Killed process
• oom-kill
• OOMKilled
• Killed process python
• Killed process python3
• urllib3.response
• _flush_decoder
• flush_decoder
• brotli
• brotlicffi

What your security team should do

• Inventory Python applications and containers for urllib3 2.6.3 and Brotli-related packages, prioritizing internet-facing services, crawlers, URL fetchers, webhook processors, scanners, and ingestion pipelines.
• Identify code paths that fetch attacker-influenced URLs or third-party HTTP content using streaming mode, especially `preload_content=False` or higher-level `stream=True` behavior.
• Upgrade to a fixed urllib3 release when available; until then, pin away from the vulnerable version or disable Brotli support for untrusted HTTP responses.
• Add application-level maximum decompressed response-size controls and fail closed when limits are exceeded.
• Restrict outbound HTTP requests to approved domains or network zones where feasible to reduce exposure to malicious servers.
• Apply container, worker, or process memory limits and supervise restarts to contain blast radius, while avoiding restart loops that amplify operational impact.
• Add monitoring for sudden memory spikes, Python `MemoryError`, OOM-killer events, and repeated crashes in services that perform outbound HTTP streaming.
• Search historical logs for Brotli responses from unusual or newly observed external hosts immediately preceding memory exhaustion or process termination.