CVE-2025-69223

What it actually does

The vulnerability allows a malicious client to send a specially crafted compressed archive or compressed HTTP payload that expands to a much larger size when processed by an aiohttp-based server. If the application or framework path decompresses the input without adequate expansion-ratio, size, memory, or time limits, a small request can consume disproportionate CPU, memory, disk, or event-loop capacity. The result is denial of service: worker starvation, process crashes, elevated latency, failed requests, or service unavailability. The issue is availability-focused; it does not directly imply code execution or data disclosure based on the provided information.

Why it matters to the business

Publicly reachable aiohttp services that accept compressed uploads or compressed request bodies may be disrupted by low-cost requests, causing outages, degraded API performance, failed customer transactions, and operational incident response effort. The CVSS score indicates high availability impact, but the currently low EPSS score, lack of known exploited status, and no reported exploit maturity suggest prioritizing remediation through normal high-severity patch cycles unless the service is internet-facing, business-critical, or already experiencing unexplained resource exhaustion.

How an attack unfolds

An attacker identifies an endpoint backed by aiohttp that accepts compressed uploads, archive files, or compressed request bodies. They craft a zip bomb or equivalent high-expansion compressed payload that is small on the wire but expands massively when decompressed. The attacker sends the payload repeatedly or concurrently to vulnerable endpoints. During request handling, the server decompresses or processes the payload and consumes excessive memory, CPU, disk, or event-loop time. With enough requests, aiohttp workers slow down, crash, or become unavailable, causing legitimate users to experience timeouts, 5xx responses, or service interruption. No authentication may be required if the affected upload or ingestion endpoint is publicly accessible, although authenticated upload functionality can also be abused.

How to fix it

Upgrade affected aiohttp and downstream packages to fixed versions as provided by the vendor or distribution. For aio-libs/aiohttp from Git, use commit 41f01ed680b7efc8f97677df45731b80328aad6c or a later release containing that fix. For Debian packages listed in the advisory, apply the relevant fixed package versions: Debian 11 fixed in 5.10.113-1; Debian 12 fixed in 5.17.3-1; Debian 13 fixed in 5.17.3-1. In addition to patching, enforce layered limits: maximum request body size, maximum uploaded file size, maximum decompressed size, decompression ratio limits, request timeouts, per-client rate limits, concurrency limits, and reverse-proxy body-size caps. Reject nested archives and unsupported compression formats where not required. If compressed uploads are necessary, decompress in a sandboxed worker with strict memory, CPU, disk, and timeout controls rather than in the main event loop.

How to confirm the fix worked

Confirm deployed aiohttp versions or distribution packages include the fixed version or commit. Review dependency lockfiles, container images, virtual environments, OS packages, and SBOMs for vulnerable aiohttp or affected distribution package versions. Test that endpoints accepting compressed input enforce size, expansion-ratio, and timeout limits by using benign oversized test payloads in a controlled environment; the expected result is fast rejection with a controlled 4xx response, not high memory growth, process restart, or long event-loop blockage. Validate reverse proxy and application-layer limits are both active. Monitor service behavior after patching for reduced memory spikes, fewer request timeouts, and absence of worker crashes during compressed upload handling.

Typical attack path

1. Discover an aiohttp-backed service with endpoints that accept file uploads, archive processing, or compressed HTTP request bodies.
2. Confirm that the endpoint processes compressed input such as ZIP, gzip, deflate, or similar formats.
3. Create a high-expansion payload that is small in transfer size but decompresses to a very large amount of data.
4. Send the payload to the vulnerable endpoint, often with concurrent requests to amplify resource pressure.
5. Cause excessive CPU, memory, disk, or event-loop consumption during decompression or request processing.
6. Observe service degradation, process crashes, timeouts, HTTP 5xx responses, or complete denial of service.

How to detect it

To determine whether exploitation may have occurred, correlate application access logs, aiohttp application logs, reverse-proxy logs, system resource telemetry, and process supervisor logs. Look for small inbound requests or uploads with compression-related headers or archive file types followed by abnormal memory growth, CPU saturation, event-loop latency, worker restarts, request timeouts, or bursts of HTTP 500/502/503/504 responses. Pay particular attention to endpoints that handle uploads, imports, archive extraction, or compressed request bodies. In web access logs, hunt for repeated POST or PUT requests with unusually small Content-Length values that coincide with long request durations or backend failures. In application logs, search for decompression errors, MemoryError exceptions, asyncio timeout messages, aiohttp request-handling exceptions, and process terminations. In host telemetry, review OOM killer events, container restarts, cgroup memory-limit kills, elevated disk usage in temporary directories, and sudden increases in CPU or event-loop lag. Because exploitation may not leave a unique payload signature, detection should focus on compression-related requests temporally linked to resource exhaustion and service instability.

• Content-Encoding: gzip
• Content-Encoding: deflate
• Content-Encoding: br
• Content-Type: application/zip
• Content-Type: application/gzip
• .zip
• MemoryError
• asyncio.exceptions.TimeoutError
• aiohttp.web_protocol
• Error handling request
• Cannot write to closing transport
• Killed process
• Out of memory
• oom-killer
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504
• Request Entity Too Large
• No space left on device

What your security team should do

• Inventory internet-facing and internal aiohttp services, especially upload, ingestion, import, archive-processing, and API endpoints that accept compressed request bodies.
• Prioritize patching public or business-critical aiohttp services even though the current EPSS is low and the issue is not listed as known exploited.
• Upgrade to the fixed aiohttp commit or vendor package versions and rebuild/redeploy containers or virtual environments that bundle vulnerable dependencies.
• Add or verify request body size limits, decompressed-size limits, compression-ratio checks, request timeouts, rate limits, and worker resource limits.
• Place high-risk upload endpoints behind a reverse proxy or API gateway with strict body-size and request-rate enforcement.
• Temporarily disable compressed uploads, archive ingestion, or automatic decompression where not business-essential until patching and limits are confirmed.
• Add monitoring and alerting for sudden increases in memory use, CPU use, event-loop latency, 5xx rates, request timeouts, and worker restarts on aiohttp services.
• Review recent logs for suspicious small compressed uploads followed by resource exhaustion or application crashes.