CVE-2025-6176

What it actually does

The flaw is an availability issue in brotli decompression handling. A remote HTTP server can return a small brotli-compressed response that expands to an extremely large amount of zero-filled data during decompression. The intended decompression-bomb protection does not adequately limit this brotli variant, so a vulnerable client can exhaust memory and crash, especially on systems with less than approximately 80 GB of available memory. The issue requires no attacker authentication and no user interaction beyond the vulnerable software making a request to an attacker-controlled or compromised server.

Why it matters to the business

Systems that crawl, fetch, index, or otherwise process untrusted remote HTTP responses can be crashed by a malicious server, causing job failures, queue backlogs, monitoring gaps, degraded data collection, and possible service disruption. The CVSS score indicates high availability impact, but EPSS is currently low and the issue is not listed in CISA KEV, so remediation should be prioritized for internet-facing crawlers, automated ingestion pipelines, and workloads that routinely contact untrusted domains.

How an attack unfolds

An attacker first identifies or lures a vulnerable crawler, client, or ingestion job into requesting content from an attacker-controlled HTTP endpoint. The server responds with headers indicating brotli compression, such as Content-Encoding: br, and serves a specially crafted compressed payload with a very high decompression ratio. The vulnerable decompression path accepts the response and begins expanding it in memory. Because the brotli decompression-bomb protection is ineffective for this case, memory consumption grows rapidly until the process raises an out-of-memory condition, is terminated by the operating system, or destabilizes the host. The result is denial of service rather than code execution or data theft.

How to fix it

Upgrade affected software to a version that contains the brotli decompression-bomb fix. For Scrapy deployments, upgrade beyond vulnerable versions up to and including 2.13.2 once the corrected release is available from the project or distribution vendor. For the Ubuntu package mappings provided with this advisory, apply the vendor-fixed packages: symfony on Ubuntu Pro 20.04 LTS fixed in 4.3.8+dfsg-1ubuntu1+esm2; symfony on Ubuntu 24.10 fixed in 6.4.5+dfsg-3ubuntu3; symfony on Ubuntu Pro 22.04 LTS fixed in 5.4.4+dfsg-1ubuntu8+esm1. Because the product metadata and description differ, validate both application dependencies and operating-system package advisories in asset inventories. If immediate upgrade is not possible, mitigate by disabling brotli response handling for untrusted destinations, removing br from Accept-Encoding where feasible, enforcing strict maximum decompressed response sizes, applying per-request memory and time limits, isolating crawler workers, and rate-limiting or blocking suspicious domains that trigger repeated memory exhaustion.

How to confirm the fix worked

Confirm installed versions are no longer within the vulnerable range using package managers, dependency lockfiles, container image scans, and runtime introspection. For Ubuntu packages, verify the installed package versions are at or above the listed fixed versions. For Python-based deployments, verify the dependency version in requirements files, lockfiles, virtual environments, and container images, and confirm rebuilt services are running the updated artifact. Test mitigation by requesting a controlled large-ratio brotli response in a non-production environment and confirming the client rejects, truncates, or safely limits decompression without abnormal memory growth. Also verify that outbound HTTP clients no longer advertise Accept-Encoding: br where brotli has been intentionally disabled.

Typical attack path

1. Set up or compromise an HTTP server that can return attacker-controlled brotli-compressed responses.
2. Create a highly compressed brotli payload that expands to very large zero-filled output.
3. Cause a vulnerable crawler, fetcher, or application client to request the malicious URL through normal crawling, ingestion, redirect, sitemap, queue, or user-submitted URL workflows.
4. Return the malicious response with brotli content encoding enabled.
5. Trigger excessive memory allocation during decompression.
6. Crash the vulnerable process or cause the operating system to kill it due to memory exhaustion.
7. Repeat requests as needed to keep the affected service unavailable or unstable.

How to detect it

Review application, crawler, proxy, EDR, and operating-system logs for crashes or memory exhaustion shortly after outbound HTTP requests to remote servers that returned brotli-compressed content. Useful sources include application logs from crawling or ingestion workers, web client debug logs, reverse proxy or egress proxy logs, container runtime events, Kubernetes pod termination reasons, Linux kernel logs, systemd journals, and memory metrics. Look for sequences where a worker requests a URL, receives Content-Encoding: br, then logs MemoryError, brotli decompression errors, process termination, OOMKilled, exit code 137, or kernel out-of-memory messages. Correlate repeated crashes with the same destination hostname, URL path, ASN, or redirect chain. Since this is a denial-of-service flaw, durable host artifacts may be limited; detection is primarily behavioral and log-based.

• Content-Encoding: br
• Accept-Encoding: br
• MemoryError
• brotli.error
• Out of memory: Killed process
• Killed process
• oom-killer
• OOMKilled
• exit code 137
• scrapy.core.downloader
• twisted.internet
• decompression bomb
• BrotliDecompress
• ContentDecodingError
• ResourceExhausted
• container killed due to memory usage

What your security team should do

• Prioritize remediation for crawlers, scanners, data ingestion services, link previewers, search indexers, and other systems that automatically fetch untrusted URLs.
• Inventory applications and containers using Scrapy or distro-packaged components referenced by the advisory, and reconcile the product metadata discrepancy before closing remediation.
• Apply the fixed vendor packages or upgrade application dependencies, then rebuild and redeploy affected containers and virtual environments.
• Temporarily disable brotli for untrusted outbound HTTP requests or enforce decompressed-size limits until all vulnerable clients are patched.
• Add worker-level memory limits and automatic restart controls so a single malicious response cannot destabilize a host or service pool.
• Monitor for repeated out-of-memory kills, MemoryError exceptions, and HTTP responses using Content-Encoding: br immediately before crawler crashes.
• Treat repeated crashes tied to the same remote host or URL as potentially malicious, even though there is no current KEV listing and public exploitation maturity is not established.