CVE-2026-59881

What it actually does

The WebSocket client accepts and attempts to decompress frames with the RSV1 bit set even when the permessage-deflate extension was never negotiated, causing unexpected CPU and memory consumption on the client.

Why it matters to the business

Clients connecting to untrusted or compromised WebSocket servers may experience denial of service through resource exhaustion, disrupting dependent Python applications and services.

How an attack unfolds

An attacker hosts a malicious WebSocket server that immediately sends frames with the RSV1 bit set. A vulnerable aiohttp client connects to the server and begins processing the frames, triggering repeated decompression attempts that exhaust CPU and memory.

How to fix it

Upgrade aiohttp to version 3.14.2 or later. If immediate upgrade is not possible, avoid connecting to untrusted WebSocket endpoints.

How to confirm the fix worked

Confirm the installed aiohttp version is 3.14.2 or newer; test by connecting to a server that sends RSV1 frames and verify resource usage remains stable.

Typical attack path

1. Attacker deploys a WebSocket server that sends RSV1-marked frames without negotiating permessage-deflate
2. Victim application initiates a WebSocket connection using the vulnerable aiohttp client
3. Server responds with crafted frames containing the RSV1 bit
4. Client performs unnecessary decompression, leading to sustained resource consumption

How to detect it

Review application logs and system metrics for sudden spikes in CPU or memory usage immediately after WebSocket connections; correlate with aiohttp client activity.

What your security team should do

• Upgrade all aiohttp installations to 3.14.2 or later as the primary remediation
• Restrict WebSocket client connections to trusted endpoints only
• Monitor Python processes using aiohttp for anomalous CPU or memory spikes