RabbitMQ up to 4.2.6/4.3.0 Like Filter rabbit_amqp_session.erl incorrect regex

Summaryinfo

A vulnerability marked as problematic has been reported in RabbitMQ up to 4.2.6/4.3.0. The affected element is an unknown function of the file rabbit_amqp_session.erl of the component Like Filter. The manipulation leads to incorrect regex. This vulnerability is uniquely identified as CVE-2026-67240. The attack is possible to be carried out remotely. No exploit exists. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability was found in RabbitMQ up to 4.2.6/4.3.0 and classified as problematic. This issue affects an unknown code of the file rabbit_amqp_session.erl of the component Like Filter. The manipulation with an unknown input leads to a incorrect regex vulnerability. Using CWE to declare the problem leads to CWE-185. The product specifies a regular expression in a way that causes data to be improperly matched or compared. Impacted is availability. The summary by CVE is:

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.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-67240 since 07/28/2026. The exploitation is known to be easy. The attack may be initiated remotely. Technical details are known, but no exploit is available.

Upgrading to version 4.2.7 or 4.3.1 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Name

• RabbitMQ

Version

• 4.0
• 4.1
• 4.2
• 4.2.0
• 4.2.1
• 4.2.2
• 4.2.3
• 4.2.4
• 4.2.5
• 4.2.6
• 4.3.0

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion