CVE-2026-67240 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, pattern_to_regex maps % -> .*? and _ -> ., then compiles ^...$ with only [unicode]; re:run is called with only [{capture, none}] - no explicit match_limit. A pattern like %_%_..._%X becomes ^.*?..*?.....*?.X$ with overlapping lazy quantifiers. The whole-expression cap is ?MAX_EXPRESSION_LENGTH=4096 chars / ?MAX_TOKENS=200; a LIKE string literal is one token, so ~2000 %_ pairs fit. SQL filters are accepted unconditionally at rabbit_amqp_session.erl:3264 (no feature flag). Evaluated per-message at rabbit_stream_queue.erl:1439. OTP's default 10M match_limit caps each match at ~100-200 ms (not seconds), and the re NIF yields to the scheduler. An authenticated AMQP 1.0 consumer with read+write on a stream queue can cause ~100-200 ms of CPU per delivered message via a crafted LIKE filter, multiplied across thousands of messages and parallel sessions - a substantial backtracking-driven CPU amplification. Preconditions include AMQP 1.0 with stream queues in use Attacker can attach a receiver with a filter (read permission) and publish messages with long property values (write permission). This issue is fixed in versions 4.2.7 and 4.3.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ, widely deployed as a messaging and streaming broker for enterprise integration patterns, contains a critical algorithmic complexity vulnerability within its AMQP 1.0 stream queue filtering mechanism. The flaw resides in the implementation of pattern matching logic used to evaluate LIKE filters against message properties. Specifically, prior to versions 4.2.7 and 4.3.1, the system converts wildcard characters into regular expression equivalents where percent signs map to non-greedy quantifiers for any character sequence and underscores map to single-character matches. These patterns are compiled with unicode support but lack explicit match limits during execution via the re:run function which is invoked with capture set to none. This configuration creates a scenario where crafted input can trigger excessive backtracking within the regular expression engine, leading to significant computational overhead without necessarily resulting in successful matches or data exfiltration.
The technical core of this vulnerability involves the interaction between unbounded regex quantifiers and RabbitMQ's internal tokenization limits. When an attacker constructs a LIKE filter containing approximately two thousand alternating percent and underscore characters, it translates into a regular expression pattern featuring overlapping lazy quantifiers such as ^.?..?.....*?.X$. Although OTP enforces a default match limit of ten million operations per regex execution to prevent infinite loops in general contexts, this cap is insufficient to mitigate the specific backtracking behavior induced by these crafted patterns. Each individual message evaluation can consume between one hundred and two hundred milliseconds of CPU time due to the exponential nature of the backtracking required to resolve the ambiguous quantifier sequences. This duration is substantial relative to typical high-throughput messaging scenarios where messages are processed in rapid succession, effectively creating a denial-of-service condition through resource exhaustion rather than system crash or memory corruption.
From an operational perspective, this vulnerability allows for a sustained CPU amplification attack that degrades broker performance and impacts other tenants sharing the same node. An authenticated attacker with read permissions on a stream queue can attach a receiver equipped with a malicious filter, while simultaneously publishing messages with long property values using write permissions. The system evaluates these filters per message at specific internal code paths within rabbit_amqp_session.erl and rabbit_stream_queue.erl. Because AMQP 1.0 support is enabled unconditionally without requiring explicit feature flags for this functionality, the attack surface is broad. The cumulative effect of processing thousands of messages with crafted properties across parallel sessions results in a substantial increase in CPU utilization, potentially causing latency spikes, message delivery delays, and eventual service degradation for legitimate consumers relying on the broker for time-sensitive data transmission.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption leading to denial-of-service conditions, specifically manifesting as algorithmic complexity attacks where input triggers worst-case performance characteristics in underlying libraries. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1496, Resource Hijacking, where an adversary leverages computational resources for disruptive purposes rather than persistence or exfiltration. The attack vector requires network access and valid credentials, classifying it as a remote authenticated attack that exploits the trust model inherent in AMQP 1.0 stream queue configurations. Mitigation strategies must prioritize upgrading to patched versions of RabbitMQ where this logic has been corrected to either restrict filter complexity or enforce stricter match limits tailored for high-throughput environments. Additionally, administrators should review access controls on stream queues and consider implementing rate limiting or filtering rules at the network perimeter if possible to reduce exposure until patches are applied.