CVE-2026-67240: RabbitMQ AMQP 1.0 DOS Vulnerability

CVE-2026-67240 Overview

CVE-2026-67240 is a regular expression denial of service (ReDoS) vulnerability in RabbitMQ, an open source messaging and streaming broker. The flaw affects the pattern_to_regex function used to translate SQL LIKE filters into Erlang regular expressions for AMQP 1.0 stream queue consumers. Crafted LIKE patterns containing many %_ pairs produce regular expressions with overlapping lazy quantifiers, forcing catastrophic backtracking during matching. An authenticated AMQP 1.0 consumer with read and write permissions on a stream queue can amplify CPU consumption across many messages and parallel sessions. The issue is fixed in versions 4.2.7 and 4.3.1.

Critical Impact
Authenticated AMQP 1.0 clients can consume roughly 100-200 ms of broker CPU per delivered message via crafted LIKE filters, enabling sustained CPU exhaustion across streams.

Affected Products

RabbitMQ server versions prior to 4.2.7 (4.2.x branch)
RabbitMQ server versions prior to 4.3.1 (4.3.x branch)
Deployments exposing AMQP 1.0 with stream queues and SQL filter expressions enabled

Discovery Timeline

2026-09-23 - CVE-2026-67240 published to the National Vulnerability Database
2026-09-23 - CVE-2026-67240 last modified in NVD

Technical Details for CVE-2026-67240

Vulnerability Analysis

The vulnerability is classified as [CWE-1333] Inefficient Regular Expression Complexity. RabbitMQ accepts SQL filter expressions on AMQP 1.0 stream queue consumers and converts LIKE patterns into regular expressions before matching them against message properties. The conversion maps % to .*? and _ to ., then wraps the result with anchors and compiles it in [unicode] mode. A pattern containing repeated %_ pairs produces a regex with many overlapping lazy quantifiers, which triggers exponential backtracking in the Erlang re engine for non-matching inputs.

Matching runs against every delivered message inside rabbit_stream_queue.erl:1439. Under OTP's default match_limit of 10 million, each match consumes roughly 100-200 ms of CPU. An attacker who publishes messages with long property values and attaches a consumer with a malicious filter multiplies that cost across thousands of messages and parallel sessions.

Root Cause

The pattern_to_regex function does not bound the number of quantifiers generated from a LIKE literal. The whole-expression cap of MAX_EXPRESSION_LENGTH=4096 characters and MAX_TOKENS=200 treats a single LIKE string as one token, so approximately 2000 %_ pairs fit inside one filter. The compiled regex is passed to re:run with only [{capture, none}] and no explicit match_limit, leaving the engine to run until OTP's default ceiling.

Attack Vector

The filter is accepted unconditionally at rabbit_amqp_session.erl:3264 without a feature flag gate. An authenticated AMQP 1.0 client with read and write permissions on a stream queue attaches a receiver carrying a malicious LIKE filter, then publishes messages whose property values force the regex engine into backtracking. Each delivery attempt burns broker CPU, and the cost scales linearly with message count and parallel consumer sessions.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-59c5-553c-57m2 for maintainer analysis.

Detection Methods for CVE-2026-67240

Indicators of Compromise

Sustained high CPU utilization on RabbitMQ broker nodes tied to beam.smp scheduler threads handling stream queue consumers
AMQP 1.0 attach frames from consumers specifying SQL filter expressions containing large numbers of % and _ wildcards
Growth in per-message processing latency on stream queues without a corresponding change in publish rate

Detection Strategies

Inspect AMQP 1.0 receiver attach frames and log the length and wildcard density of any LIKE filter expressions supplied by clients
Correlate broker CPU spikes with the connections and users that recently attached filtered consumers to stream queues
Baseline normal filter shapes for each application and alert when a consumer submits filters exceeding the observed length or wildcard count

Monitoring Recommendations

Track scheduler utilization, run queue length, and message delivery latency via the RabbitMQ management plugin and Prometheus exporter
Audit authentication logs for AMQP 1.0 users with read and write permissions on stream queues, and review whether those permissions are still required
Forward broker logs and metrics into a centralized analytics platform to correlate connection metadata with CPU anomalies across cluster nodes

How to Mitigate CVE-2026-67240

Immediate Actions Required

Upgrade RabbitMQ to version 4.2.7 on the 4.2.x branch or 4.3.1 on the 4.3.x branch
Review AMQP 1.0 user permissions and revoke read or write access to stream queues where filtering is not required
Rate-limit or disconnect authenticated clients observed submitting oversized LIKE filter patterns

Patch Information

The fix is included in RabbitMQ v4.2.7 and v4.3.1. Details of the underlying change are documented in the GitHub Security Advisory GHSA-59c5-553c-57m2.

Workarounds

Restrict AMQP 1.0 access so that only trusted, service-account clients can attach consumers to stream queues
Disable stream queue usage where feasible, or route stream traffic through a broker version that includes the patch
Place a policy-aware proxy in front of RabbitMQ to reject attach frames whose SQL filter expressions exceed a conservative length or wildcard density

bash

# Verify installed RabbitMQ version and confirm patched release
rabbitmqctl version

# Example: list AMQP 1.0 users with permissions on a virtual host
rabbitmqctl list_permissions -p /

# Revoke access for an account that no longer needs stream queue access
rabbitmqctl clear_permissions -p / suspect_user