CVE-2026-67240

Received Received - Intake

ReDoS in RabbitMQ Stream Queue via AMQP 1.0 Filter

Publication date: 2026-09-23

Last updated on: 2026-09-23

Assigner: GitHub, Inc.

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-23

Last Modified

2026-09-23

Generated

2026-09-24

AI Q&A

2026-09-24

EPSS Evaluated

N/A

NVD

CVE-2026-67240

EUVD

EUVD-2026-85636

Affected Vendors & Products

Vendor	Product	Version / Range
rabbitmq	rabbitmq	to 4.3.1 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-1333	The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles.

Attack-Flow Graph

Executive Summary

RabbitMQ versions before 4.2.7 and 4.3.1 have a flaw in pattern_to_regex that converts % to .*? and _ to ., then compiles regex with no match_limit. A crafted LIKE filter with many %_ pairs causes excessive backtracking, consuming ~100-200 ms CPU per message. Attackers with AMQP 1.0 read+write permissions can exploit this via stream queues.

Impact Analysis

An attacker could degrade system performance by forcing high CPU usage per message, potentially leading to service slowdowns or outages. Systems using RabbitMQ with AMQP 1.0 and stream queues are at risk if not patched.

Mitigation Strategies

Upgrade RabbitMQ to versions 4.2.7 or 4.3.1 or later to address the vulnerability. Disable AMQP 1.0 stream queues if not required. Restrict AMQP 1.0 consumer permissions to prevent unauthorized filter usage. Monitor CPU usage for unusual spikes during message processing.

Hi! I’m here to help you understand CVE-2026-67240. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70