CVE-2026-67235 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15, The content-header BodySize (a uint64) was stored without validation against max_message_size. The size check ran only when assembly completed. By declaring body_size = 2^63-1 and then streaming fragments, a client ensured that check_msg_size never fired, so the accumulated body size went unbounded. A reader process accumulates memory until the memory alarm fires, degrading all publishers cluster-wide, or until the node runs out of memory. The memory alarm provides only partial mitigation, since it is reactive rather than preventive. AMQP 0-9-1 is the most widely used protocol, and any publisher can trigger this condition. Preconditions include Any authenticated AMQP 0-9-1 client with publish permission can exploit this.. This issue is fixed in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in RabbitMQ messaging broker software represents a critical flaw in the message ingestion pipeline related to memory management and input validation within the AMQP protocol implementation. Specifically affecting versions prior to 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15, this issue stems from a logic error in how the server processes the BodySize field of content headers during message assembly. The AMQP protocol allows clients to publish messages that are fragmented into multiple frames for transmission efficiency. In vulnerable versions, the RabbitMQ server fails to validate the declared body size against the configured max_message_size limit at the point where individual fragments arrive or as they begin accumulating. Instead, this validation check is deferred until the entire message assembly process completes. This architectural decision creates a window of opportunity for exploitation by malicious actors who can manipulate the initial header information to bypass immediate resource constraints.
An attacker with authenticated access and publish permissions on an AMQP 0-9-1 channel can exploit this flaw by setting the BodySize field in the content-header to its maximum possible unsigned integer value, specifically 2^63 minus one, while simultaneously streaming message fragments over time. Because the server does not enforce size limits during the accumulation phase, it continues to allocate memory for each incoming fragment without checking if the total exceeds system or queue thresholds. This results in an unbounded growth of memory usage on the node processing these messages. The vulnerability is particularly severe because AMQP 0-9-1 remains the most widely used protocol version for RabbitMQ deployments, and any authenticated publisher can trigger this condition regardless of their specific role beyond having basic publish rights.
The operational impact of this flaw is a significant denial-of-service scenario characterized by resource exhaustion on the affected node. As the reader process accumulates memory to store these oversized message fragments, it eventually triggers the server's internal memory alarm. While RabbitMQ includes mechanisms such as memory alarms and disk-free limits to protect system stability, these are reactive measures rather than preventive controls. Once a memory alarm fires, the broker begins to block all publishers across the entire cluster to prevent further resource consumption. This cascading effect degrades service availability for legitimate users and can lead to complete node failure if the out-of-memory condition is not resolved quickly. The lack of proactive validation means that even well-configured systems with strict max_message_size settings remain vulnerable until the message assembly completes, at which point it may be too late to prevent significant memory pressure or crash conditions.
This vulnerability aligns with CWE-787: Out-of-bounds Write and CWE-400: Uncontrolled Resource Consumption, as it involves improper validation of input leading to excessive resource allocation that can exhaust system limits. From a threat intelligence perspective, this exploitation technique maps to MITRE ATT&CK techniques related to Denial of Service via application layer attacks, specifically leveraging protocol-level ambiguities or implementation flaws to disrupt service availability. The attack vector is remote if authentication credentials are compromised or leaked, making it a high-risk issue for environments where RabbitMQ handles sensitive data or critical business workflows.
Mitigation requires immediate upgrading to patched versions including 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15, which implement proper validation of message sizes during the assembly process rather than only at completion. In environments where upgrading is not immediately feasible, administrators should enforce strict network-level access controls to ensure that only trusted clients can connect as publishers. Additionally, implementing rate limiting on publish operations and monitoring memory usage metrics closely can help detect anomalous behavior indicative of this exploitation attempt before it leads to a full denial-of-service event. Regular security audits of AMQP client implementations are also recommended to identify any custom code that might inadvertently bypass server-side validation logic or rely on assumptions about message size handling.