CVE-2026-67240: RabbitMQ: ReDoS via AMQP 1.0 SQL filter LIKE wildcard

Severity: medium (CVSS 6.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.3% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-09-23 · updated 2026-10-30
Weakness: CWE-1333

Description

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.

Affected products

rabbitmq-server: from 4.2.0 before 4.2.7; from 4.3.0 before 4.3.1 — fixed in 4.2.7, 4.3.1
rabbitmq-server: from 4.2.0, < 4.2.7; from 4.3.0, < 4.3.1

How to fix

Upgrade to a fixed version: rabbitmq-server 4.2.7, 4.3.1. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-67240 or the next vulnerability affects your stack