GHSA-XWWF-M8FG-P9Q2
Vulnerability from github – Published: 2026-09-17 17:03 – Updated: 2026-09-17 17:03Summary
A Denial of Service (DoS) vulnerability exists in the AMQP client's connection negotiation logic. The AMQP specification explicitly mandates a strict minimum frame size of 4096 bytes to prevent pathological packet fragmentation. While the library defines a frameMinSize = 4096 constant, the connection negotiation loop fails to enforce this boundary, blindly accepting whatever maximum frame size (FrameMax) the server advertises during the handshake.
If a client connects to a malicious or compromised AMQP broker that advertises an extremely low FrameMax (such as 1 byte), the negotiation succeeds. Consequently, every subsequent message transmission is forced to splinter into thousands or millions of single-byte frames, causing massive CPU overhead, thread contention, and a near-instantaneous application freeze.
Vulnerability Details
Mechanism
During the connection establishment phase, the client and server negotiate connection parameters—including maximum channel count, heartbeat intervals, and maximum frame sizes. The vulnerability is located where the client accepts the server's tuning parameters:
// Connection negotiation logic maps server values directly without validation
if serverSettings.FrameMax > 0 {
// VULNERABILITY: Lacks a floor validation check against frameMinSize (4096)
c.config.FrameMax = serverSettings.FrameMax
}
Because there is no conditional check asserting that serverSettings.FrameMax >= frameMinSize, a value below the protocol specification floor is successfully registered. When the application later passes data payloads to the frame writer, the chunking algorithm splits the payload using the negotiated FrameMax value as its chunk window divisor.
Impact
When FrameMax is set to an absurdly low threshold (e.g., 1 to 10 bytes):
* A standard 10 KiB message payload requires tens of thousands of individual write operations and frame headers.
* The system's CPU becomes entirely bound by frame serialization, memory allocation for frame structures, and context switching within the network output loops.
* This results in an application-layer Denial of Service (DoS) affecting not just the specific AMQP connection, but potentially the entire host system due to CPU resource starvation.
Attack Vector
An attacker who compromises an upstream AMQP broker, performs a Man-in-the-Middle (MitM) interception, or tricks an application into connecting to an unauthorized external rogue broker can trigger this vulnerability:
- Rogue Handshake: The client application connects to an AMQP endpoint controlled by the attacker.
- Malicious Parameter Tuning: During the
connection.tunephase, the rogue server returns aFrameMaxvalue of1. - Resource Exhaustion Trigger: The client completes the handshake successfully. As soon as the client attempts to publish a message or process traffic, the internal loop fragments the data into single-byte frames, spiking the host's CPU usage to 100% and disabling the application thread.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rabbitmq/amqp091-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77403"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T17:03:50Z",
"nvd_published_at": "2026-09-16T15:17:46Z",
"severity": "HIGH"
},
"details": "## Summary\nA Denial of Service (DoS) vulnerability exists in the AMQP client\u0027s connection negotiation logic. The AMQP specification explicitly mandates a strict minimum frame size of 4096 bytes to prevent pathological packet fragmentation. While the library defines a `frameMinSize = 4096` constant, the connection negotiation loop fails to enforce this boundary, blindly accepting whatever maximum frame size (`FrameMax`) the server advertises during the handshake.\n\nIf a client connects to a malicious or compromised AMQP broker that advertises an extremely low `FrameMax` (such as 1 byte), the negotiation succeeds. Consequently, every subsequent message transmission is forced to splinter into thousands or millions of single-byte frames, causing massive CPU overhead, thread contention, and a near-instantaneous application freeze.\n\n---\n\n## Vulnerability Details\n\n### Mechanism\nDuring the connection establishment phase, the client and server negotiate connection parameters\u2014including maximum channel count, heartbeat intervals, and maximum frame sizes. The vulnerability is located where the client accepts the server\u0027s tuning parameters:\n\n```go\n// Connection negotiation logic maps server values directly without validation\nif serverSettings.FrameMax \u003e 0 {\n // VULNERABILITY: Lacks a floor validation check against frameMinSize (4096)\n c.config.FrameMax = serverSettings.FrameMax \n}\n```\n\nBecause there is no conditional check asserting that `serverSettings.FrameMax \u003e= frameMinSize`, a value below the protocol specification floor is successfully registered. When the application later passes data payloads to the frame writer, the chunking algorithm splits the payload using the negotiated `FrameMax` value as its chunk window divisor.\n\n### Impact\nWhen `FrameMax` is set to an absurdly low threshold (e.g., 1 to 10 bytes):\n* A standard 10 KiB message payload requires tens of thousands of individual write operations and frame headers.\n* The system\u0027s CPU becomes entirely bound by frame serialization, memory allocation for frame structures, and context switching within the network output loops.\n* This results in an application-layer Denial of Service (DoS) affecting not just the specific AMQP connection, but potentially the entire host system due to CPU resource starvation.\n\n---\n\n## Attack Vector\nAn attacker who compromises an upstream AMQP broker, performs a Man-in-the-Middle (MitM) interception, or tricks an application into connecting to an unauthorized external rogue broker can trigger this vulnerability:\n\n1. **Rogue Handshake:** The client application connects to an AMQP endpoint controlled by the attacker.\n2. **Malicious Parameter Tuning:** During the `connection.tune` phase, the rogue server returns a `FrameMax` value of `1`.\n3. **Resource Exhaustion Trigger:** The client completes the handshake successfully. As soon as the client attempts to publish a message or process traffic, the internal loop fragments the data into single-byte frames, spiking the host\u0027s CPU usage to 100% and disabling the application thread.",
"id": "GHSA-xwwf-m8fg-p9q2",
"modified": "2026-09-17T17:03:50Z",
"published": "2026-09-17T17:03:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-xwwf-m8fg-p9q2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77403"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/pull/353"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/commit/2e0a919b89f337dbf58db2bb34ab206dac354a06"
},
{
"type": "PACKAGE",
"url": "https://github.com/rabbitmq/amqp091-go"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/amqp091-go/releases/tag/v1.13.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
"type": "CVSS_V4"
}
],
"summary": "RabbitMQ amqp091-go: Denial of Service via Sub-Spec Frame Size Negotiation"
}
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.
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.