GHSA-pjh6-c8mg-3x7m: Medium severity pip/autobahn vulnerability
Summary
permessage-brotli inflates each frame fully before checking maxMessagePayloadSize, so one 421-byte frame makes the server allocate about 545 MiB even with a 1 MiB message limit (brotli expands about 1,000,000:1). Any unauthenticated client can exhaust server memory this way on servers that enable permessage-brotli. This bypasses the GHSA-hxp9-w8x3-p566 fix.
Details
In 26.7.1 the receive path passes the remaining maxMessagePayloadSize budget to decompressmessagedata(..., maxoutputlen=...). deflate and bzip2 stop at that budget. PerMessageBrotli.decompressmessagedata (compressbrotli.py) instead calls self.decompressor.process(data) with no limit and compares the length afterwards, so the whole frame is inflated first.
The code comment and changelog say this is still "bounded on the wire by maxFramePayloadSize", but brotli reaches about 1,000,000:1 (841 bytes inflate to 1 GiB), so that bound means little. A 421-byte frame against a 1 MiB budget peaks at 545 MiB before the 1009 rejection.
An autobahn asyncio server on 127.0.0.1 accepting permessage-brotli, with maxFramePayloadSize=64 KiB and maxMessagePayloadSize=1 MiB, received one small brotli frame from an autobahn client and peaked at 545 MiB (baseline 28 MiB). A few concurrent connections can exhaust memory.
brotli ≥ 1.2.0 has Decompressor.process(data, outputbufferlimit=N), so the backend can stop at maxoutputlen like deflate and bzip2 (and the extra's floor can be raised to brotli>=1.2.0).
Tested on autobahn 26.7.1 (latest) with brotli 1.2.0; compressbrotli.py on master is unchanged. This affects servers that enable permessage-brotli (opt-in, needs the compress extra).
Proof of concept
How to run the PoC python3 -m venv venv && . venv/bin/activate pip install autobahn==26.7.1 brotli==1.2.0 python3 pocautobahn.py
python PoC: autobahn 26.7.1 permessage-brotli inflates a whole frame before maxMessagePayloadSize is checked. import brotli, resource from autobahn.websocket.compress import PerMessageBrotli
c = brotli.Compressor() # build a 256 MiB-of-zeros frame without holding the plaintext frame = b"".join(c.process(b"\0" (1 << 20)) for in range(256)) + c.finish() pmce = PerMessageBrotli(isserver=True, servernocontexttakeover=False, clientnocontexttakeover=False) pmce.startdecompressmessage() print(len(frame), "bytes on the wire; peak RSS before:", resource.getrusage(resource.RUSAGESELF).rumaxrss >> 10, "MiB") try: pmce.decompressmessagedata(frame, maxoutputlen=1 << 20) # remaining budget: 1 MiB except Exception as e: print(type(e).name, "| peak RSS after:", resource.getrusage(resource.RUSAGESELF).rumaxrss >> 10, "MiB")
Output: 421 bytes on the wire; peak RSS before: 36 MiB PayloadExceededError | peak RSS after: 545 MiB
Impact
An unauthenticated WebSocket client can make a server that enabled permessage-brotli allocate hundreds of MB or more per tiny frame, regardless of the configured maxMessagePayloadSize. That is the memory-exhaustion DoS GHSA-hxp9-w8x3-p566 was meant to prevent.
Credit goes to Adrian Korwel.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/autobahnto a version that resolves this vulnerability.Fixed in 26.10.1 - Upgrade
Upgrade
brotlito a version that resolves this vulnerability.Fixed in 1.2.0 - Configuration
Pass output_buffer_limit=max_output_len to self._decompressor.process(data) so decompression stops at the remaining maxMessagePayloadSize budget instead of inflating the whole frame first.
Autobahn permessage-brotli Decompressor.process output_buffer_limit = max_output_len
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service issue?
Autobahn servers that enable the permessage-brotli WebSocket extension are exposed. The issue can be triggered even when maxMessagePayloadSize is set to 1 MiB and maxFramePayloadSize is set to 64 KiB.
What does an attacker need to exploit it?
An attacker only needs to connect as an unauthenticated client and send a small, highly compressible Brotli-compressed WebSocket frame. No user interaction or prior privileges are required.
Why do configured message-size limits not prevent the memory exhaustion?
The permessage-brotli receive path fully decompresses a frame before comparing its size with the remaining maxMessagePayloadSize budget. The server rejects the oversized message afterward with code 1009, but memory has already been allocated during decompression.
How severe can the memory allocation be from a small frame?
The advisory reports that a 421-byte frame can cause roughly 545 MiB of peak memory allocation with a 1 MiB message limit. Brotli can expand data by about 1,000,000:1, so wire-size frame limits provide little protection.