CVE-2026-77528: Autobahn Python WebSocket DoS Vulnerability

CVE-2026-77528 Overview

Autobahn Python, a WebSocket and Web Application Messaging Protocol (WAMP) implementation supporting Twisted and asyncio, contains a decompression-bomb vulnerability in versions prior to 26.7.1. WebSocket endpoints that accept the permessage-deflate extension enforce the maxMessagePayloadSize limit against the compressed frame length rather than the decompressed message size. A remote unauthenticated client can send a small compressed frame that inflates far beyond the configured application limit. The oversized message is then allocated, joined, validated, and passed to application callbacks, producing resource-exhaustion pressure on the server.

Critical Impact
Unauthenticated network attackers can trigger memory and CPU exhaustion by sending compressed WebSocket frames that expand past the configured payload limit, degrading service availability.

Affected Products

Autobahn Python versions prior to 26.7.1
WebSocket servers negotiating the permessage-deflate extension
WAMP endpoints built on Autobahn Python (Twisted and asyncio)

Discovery Timeline

2026-09-18 - CVE-2026-77528 published to the National Vulnerability Database
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-77528

Vulnerability Analysis

The flaw is a channel error for resource consumption, classified as [CWE-409]. Autobahn Python validated the maxMessagePayloadSize limit at the wire layer, before the permessage-deflate inflation step ran. Any frame smaller than the wire cap passed the check, regardless of its uncompressed size. Because deflate can achieve very high compression ratios on repetitive data, a compact frame of a few kilobytes can expand into hundreds of megabytes of application payload.

The decompressed buffer was then reassembled, UTF-8 validated, and dispatched to application callbacks. This behavior mirrors the classic decompression-bomb pattern previously tracked as CVE-2016-10544 in the same project.

Root Cause

Autobahn Python enforced maxMessagePayloadSize against the compressed on-the-wire frame length instead of the reassembled, inflated message size. The inflation path did not re-check the running uncompressed size against the configured cap. Additionally, the permessage-deflatemax_message_size receive cap used a bounded decompress(..., max_length) call that left remaining input in unconsumed_tail undrained, corrupting oversize messages instead of rejecting them cleanly with a zlib error.

Attack Vector

An unauthenticated remote attacker negotiates permessage-deflate during the WebSocket handshake. The attacker then sends a valid compressed frame whose wire size sits below maxFramePayloadSize and maxMessagePayloadSize. The server inflates the frame into a payload that exceeds available memory budgets, allocating and validating oversized data before the application receives it. Repeated frames amplify the pressure, driving memory and CPU exhaustion.

text

26.7.1
------

**Security**

* Fix WebSocket ``maxMessagePayloadSize`` being enforced against the compressed on-the-wire frame length instead of the uncompressed reassembled message size when permessage-compress (deflate/bzip2/snappy/brotli) is negotiated. A small compressed frame could inflate far beyond the configured limit and be delivered to the application (a decompression-bomb style denial-of-service; security advisory GHSA-hxp9-w8x3-p566, same class as CVE-2016-10544). The limit is now re-checked at the inflation site against the running uncompressed message size, and the connection is failed with close code 1009 (message too big) before delivery — for both the whole-message and streaming receive APIs and every compression backend.
* Fix the permessage-deflate ``max_message_size`` receive cap silently truncating an over-limit message and raising a zlib error instead of cleanly rejecting it: the bounded ``decompress(…, max_length)`` left the remaining input in ``unconsumed_tail`` undrained, so the message was corrupted rather than reported. Decompression is now bounded cumulatively across frames and raises ``PayloadExceededError`` as soon as the uncompressed size would exceed the cap (#1908)

Source: GitHub Commit 77d323a

Detection Methods for CVE-2026-77528

Indicators of Compromise

Sudden memory or CPU spikes in Autobahn-based WebSocket or WAMP processes shortly after handshake completion.
WebSocket connections that successfully negotiate permessage-deflate and immediately transmit small frames followed by process instability.
Application logs showing oversized message dispatch or out-of-memory errors on receive callbacks.

Detection Strategies

Monitor the ratio of compressed bytes received to uncompressed bytes delivered to application handlers; ratios greater than 100:1 warrant investigation.
Alert on zlib errors or truncated message events emitted by Autobahn receive paths on pre-patch builds.
Instrument WebSocket endpoints to log connection close code 1009 (message too big) frequency as a baseline for abuse detection.

Monitoring Recommendations

Track process resident set size (RSS) and garbage-collection pressure on Python workers hosting WebSocket endpoints.
Correlate network telemetry with application logs to identify low-volume clients producing disproportionate memory allocations.
Review reverse-proxy access logs for repeated short-lived WebSocket upgrades from the same source addresses.

How to Mitigate CVE-2026-77528

Immediate Actions Required

Upgrade Autobahn Python to version 26.7.1 or later on all Twisted and asyncio deployments.
Inventory internal services and dependencies that embed Autobahn Python, including Crossbar.io routers and WAMP components.
If patching cannot be scheduled immediately, disable permessage-deflate negotiation on exposed WebSocket endpoints.

Patch Information

The fix is delivered in Autobahn Python v26.7.1, published via GitHub Release v26.7.1. Details are documented in GitHub Security Advisory GHSA-hxp9-w8x3-p566 and implemented through Pull Request #1916. The patch re-checks maxMessagePayloadSize at the inflation site against the running uncompressed size and fails the connection with close code 1009 before application delivery.

Workarounds

Disable permessage-deflate on Autobahn WebSocket factories until the patch can be applied.
Place a WebSocket-aware reverse proxy in front of Autobahn endpoints and enforce strict message size limits after decompression.
Reduce maxFramePayloadSize to a conservative value to limit the amplification budget of any single compressed frame.

bash

# Example: upgrade Autobahn Python to the patched release
pip install --upgrade 'autobahn>=26.7.1'

# Verify the installed version
python -c "import autobahn; print(autobahn.__version__)"