CVE-2026-67408 in RabbitMQ
Summary
by MITRE • 09/25/2026
RabbitMQ is a messaging and streaming broker. From 4.1.0 until 4.3.3, 4.2.9, and 4.1.11, Stream Management Super-Stream Binding Keys Allocation Allows Low-Privilege Node Denial of Service. rabbitMQ 4.3.1 with rabbitmqstreammanagement enabled accepts PUT /api/stream/super-streams/{vhost}/{name} requests from an authenticated management user that can access the target vhost. When the request body contains the binding-keys field, the handler parses the attacker-controlled comma-separated string and builds the full stream-name list before checking whether the user has permission to configure the resulting streams. A low-privileged management user with vhost access but no configure, write, or read permission can therefore force large transient allocations before the resource permission check. In a 768 MB memory-limited container, one HTTP PUT with about 4.5 MB of JSON body killed the RabbitMQ container with Docker state exited true An authenticated low-privileged management user can kill a memory-limited RabbitMQ node with one HTTP This issue is fixed in versions 4.3.3, 4.2.9, and 4.1.11.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified involves a critical resource allocation flaw within the Stream Management component of RabbitMQ messaging broker software, specifically affecting versions ranging from 4.1.0 up to 4.3.3, as well as specific maintenance releases like 4.2.9 and 4.1.11. This issue stems from an improper order of operations during the processing of super-stream binding key configurations via the management HTTP API. When a user submits a PUT request to the /api/stream/super-streams endpoint with a large number of binding keys, the server-side handler prematurely parses the comma-separated string and attempts to build the full list of stream names before verifying whether the authenticated user possesses the necessary permissions to configure those specific streams. This architectural oversight allows an attacker who has been granted low-privileged management access to any virtual host to trigger substantial memory allocations on the broker node, regardless of their actual configuration rights for the target resources.
From a technical perspective, this flaw represents a classic case of resource exhaustion due to incorrect validation sequencing. The system allocates significant amounts of heap memory to construct internal data structures representing the potential streams before executing the access control check defined by RabbitMQ's permission model. In environments where RabbitMQ is deployed with constrained memory limits, such as in Docker containers or Kubernetes pods with strict resource quotas, this behavior can lead to immediate out-of-memory conditions. The attacker does not need administrative privileges; merely having read and write permissions for a virtual host is sufficient to exploit the flaw by sending a single HTTP PUT request containing an excessively large JSON body with thousands of binding keys. This action forces the Erlang runtime to allocate memory that exceeds available resources, causing the RabbitMQ process to crash or be terminated by the operating system's out-of-memory killer.
The operational impact of this vulnerability is severe, resulting in a Denial of Service against the affected RabbitMQ node and potentially impacting other services relying on message delivery through that broker. In tested scenarios involving a 768 MB memory-limited container, a single request with approximately 4.5 megabytes of JSON payload was sufficient to exhaust available memory and cause the container to exit unexpectedly. This disruption can lead to significant downtime for applications dependent on real-time messaging, causing data loss if messages are in flight or pending acknowledgment at the time of the crash. Furthermore, because the vulnerability requires only low-privileged access, it expands the attack surface significantly compared to vulnerabilities requiring admin-level credentials, making it a more likely target for malicious insiders or compromised service accounts with minimal permissions.
This issue is categorized under CWE-787: Out-of-bounds Write and CWE-400: Uncontrolled Resource Consumption within standard vulnerability classification frameworks. In terms of the MITRE ATT&CK framework, this exploit aligns with T1499: Endpoint Denial of Service, specifically leveraging resource exhaustion techniques to disrupt service availability. The attack vector is classified as Network-based (T1190) and requires Authentication (T1078), indicating that while it can be executed remotely over HTTP, the attacker must first obtain valid credentials for a management user account with at least read/write access to any virtual host on the target cluster.
To mitigate this vulnerability, organizations should immediately upgrade RabbitMQ to version 4.3.3, 4.2.9, or 4.1.11, where the validation logic has been corrected to check permissions before allocating resources for stream creation. In addition to upgrading, administrators should enforce strict resource limits on RabbitMQ deployments using container orchestration tools like Kubernetes or Docker Swarm to prevent a single process from consuming all available host memory. Implementing Web Application Firewalls with rate limiting and payload size restrictions can also provide an additional layer of defense by blocking excessively large HTTP requests before they reach the application logic. Regular auditing of user permissions is recommended to ensure that management users are granted only the minimum necessary privileges, thereby reducing the potential impact if credentials are compromised.