GHSA-PJH6-C8MG-3X7M
Vulnerability from github – Published: 2026-10-28 21:10 – Updated: 2026-10-28 21:10Summary
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 decompress_message_data(..., max_output_len=...). deflate and bzip2 stop at that budget. PerMessageBrotli.decompress_message_data (compress_brotli.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, output_buffer_limit=N), so the backend can stop at max_output_len 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; compress_brotli.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 poc_autobahn.py
# 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(is_server=True, server_no_context_takeover=False, client_no_context_takeover=False)
pmce.start_decompress_message()
print(len(frame), "bytes on the wire; peak RSS before:", resource.getrusage(resource.RUSAGE_SELF).ru_maxrss >> 10, "MiB")
try:
pmce.decompress_message_data(frame, max_output_len=1 << 20) # remaining budget: 1 MiB
except Exception as e:
print(type(e).__name__, "| peak RSS after:", resource.getrusage(resource.RUSAGE_SELF).ru_maxrss >> 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": [
{
"package": {
"ecosystem": "PyPI",
"name": "autobahn"
},
"ranges": [
{
"events": [
{
"introduced": "26.7.1"
},
{
"fixed": "26.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-116579"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-28T21:10:17Z",
"nvd_published_at": "2026-10-26T21:18:15Z",
"severity": "MODERATE"
},
"details": "### Summary\n\npermessage-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.\n\n### Details\n\nIn 26.7.1 the receive path passes the remaining `maxMessagePayloadSize` budget to `decompress_message_data(..., max_output_len=...)`. deflate and bzip2 stop at that budget. `PerMessageBrotli.decompress_message_data` (`compress_brotli.py`) instead calls `self._decompressor.process(data)` with no limit and compares the length afterwards, so the whole frame is inflated first.\n\nThe 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.\n\nAn 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.\n\nbrotli \u2265 1.2.0 has `Decompressor.process(data, output_buffer_limit=N)`, so the backend can stop at `max_output_len` like deflate and bzip2 (and the extra\u0027s floor can be raised to `brotli\u003e=1.2.0`).\n\nTested on autobahn 26.7.1 (latest) with brotli 1.2.0; `compress_brotli.py` on master is unchanged. This affects servers that enable permessage-brotli (opt-in, needs the `compress` extra).\n\n### Proof of concept\n\nHow to run the PoC\n```\npython3 -m venv venv \u0026\u0026 . venv/bin/activate\npip install autobahn==26.7.1 brotli==1.2.0\npython3 poc_autobahn.py\n```\n\n```python\n# PoC: autobahn 26.7.1 permessage-brotli inflates a whole frame before maxMessagePayloadSize is checked.\nimport brotli, resource\nfrom autobahn.websocket.compress import PerMessageBrotli\n\nc = brotli.Compressor() # build a 256 MiB-of-zeros frame without holding the plaintext\nframe = b\"\".join(c.process(b\"\\0\" * (1 \u003c\u003c 20)) for _ in range(256)) + c.finish()\npmce = PerMessageBrotli(is_server=True, server_no_context_takeover=False, client_no_context_takeover=False)\npmce.start_decompress_message()\nprint(len(frame), \"bytes on the wire; peak RSS before:\", resource.getrusage(resource.RUSAGE_SELF).ru_maxrss \u003e\u003e 10, \"MiB\")\ntry:\n pmce.decompress_message_data(frame, max_output_len=1 \u003c\u003c 20) # remaining budget: 1 MiB\nexcept Exception as e:\n print(type(e).__name__, \"| peak RSS after:\", resource.getrusage(resource.RUSAGE_SELF).ru_maxrss \u003e\u003e 10, \"MiB\")\n```\n\nOutput:\n```\n421 bytes on the wire; peak RSS before: 36 MiB\nPayloadExceededError | peak RSS after: 545 MiB\n```\n\n### Impact\n\nAn 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.\n\nCredit goes to Adrian Korwel.",
"id": "GHSA-pjh6-c8mg-3x7m",
"modified": "2026-10-28T21:10:17Z",
"published": "2026-10-28T21:10:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/crossbario/autobahn-python/security/advisories/GHSA-pjh6-c8mg-3x7m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116579"
},
{
"type": "WEB",
"url": "https://github.com/crossbario/autobahn-python/pull/1987"
},
{
"type": "WEB",
"url": "https://github.com/crossbario/autobahn-python/commit/a41442bbee4f6126a8ce1bb892840124c24d16f1"
},
{
"type": "PACKAGE",
"url": "https://github.com/crossbario/autobahn-python"
},
{
"type": "WEB",
"url": "https://github.com/crossbario/autobahn-python/releases/tag/v26_10_1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Autobahn Python: permessage-brotli inflates a whole frame before maxMessagePayloadSize is checked (incomplete fix of GHSA-hxp9-w8x3-p566)"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.