CVE-2026-67240: RabbitMQ: ReDoS via AMQP 1.0 SQL filter LIKE wildcard
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, patterntoregex maps % -> .? and -> ., then compiles ^...$ with only [unicode]; re:run is called with only [{capture, none}] - no explicit matchlimit. A pattern like %%...%X becomes ^.?..?.....?.X$ with overlapping lazy quantifiers. The whole-expression cap is ?MAXEXPRESSIONLENGTH=4096 chars / ?MAXTOKENS=200; a LIKE string literal is one token, so ~2000 % pairs fit. SQL filters are accepted unconditionally at rabbitamqpsession.erl:3264 (no feature flag). Evaluated per-message at rabbitstreamqueue.erl:1439. OTP's default 10M matchlimit 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.7 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.1
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Exposure requires AMQP 1.0 and stream queues to be in use. SQL filters are accepted unconditionally for AMQP 1.0 sessions, so there is no feature flag described that disables this filter capability.
What access does an attacker need to cause the CPU amplification?
An attacker needs to authenticate as an AMQP 1.0 consumer and have read permission to attach a receiver with a filter, plus write permission to publish messages with long property values to a stream queue. The impact is amplified by many delivered messages and parallel sessions.
How severe can an individual regex evaluation be?
OTP's default match_limit caps an individual match at roughly 100–200 ms rather than seconds, and the regex NIF yields to the scheduler. However, crafted LIKE patterns can trigger this cost for each delivered message, creating substantial aggregate CPU use.
What versions contain the fix?
The issue is fixed in RabbitMQ versions 4.2.7 and 4.3.1. Versions before those releases are described as affected.