RabbitMQ Server CVE-2026-67240

Exploitation requires all of: (1) AMQP 1.0 protocol in use with stream queues configured; (2) SQL filter expressions accepted on stream consumers (per the description these are accepted unconditionally at rabbit_amqp_session.erl:3264 with no feature flag when stream queues are used); (3) an authenticated account (PR:L) holding BOTH read permission (to attach a receiver with a filter) and write permission (to publish messages with long property values) on the target stream queue. Limiting factors: the attacker must already be authenticated and authorized on the stream; impact is bounded CPU amplification (~100-200 ms per delivered message, scheduler-yielding, capped by OTP's 10M match_limit) rather than a node crash or hang; and deployments not using AMQP 1.0 stream queues with SQL filters are unaffected.

This is a low-priority issue whose signals are internally consistent and point away from urgency. The vendor CVSS 4.0 score is 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N) with only VA:L - an availability-integrity-confidentiality profile of N/N/Low, i.e. CPU amplification, not a crash or data exposure. Crucially the description itself explains why the ceiling is low: OTP's default 10M match_limit caps each regex match at ~100-200 ms and the re NIF yields to the scheduler, so this is backtracking-driven CPU burn amplified across many messages/sessions rather than a single-request outage or unbounded hang. AT:P (Present) correctly reflects that exploitation is gated on specific preconditions - AMQP 1.0 with stream queues in use and SQL LIKE filters accepted. There is no EPSS score, no CISA KEV listing, and no public exploit code - no public exploit identified at time of analysis. There are no conflicting signals here: this is a genuinely low-severity, config-and-authentication-gated resource-consumption bug, not a high-CVSS-but-low-real-risk mismatch. The CWE-1333 (inefficient regular expression complexity / ReDoS) classification matches the pattern_to_regex overlapping-lazy-quantifier root cause. Priority should be routine patching to 4.2.7/4.3.1, not emergency response.

An attacker who already holds a valid RabbitMQ account with read and write permissions on a stream queue attaches an AMQP 1.0 receiver carrying a crafted SQL LIKE filter (e.g. a ~2000-pair %_%_..._%X pattern) and publishes messages with long property values. Each delivered message forces ~100-200 ms of catastrophic-backtracking CPU during per-message filter evaluation, and the attacker multiplies this across thousands of messages and parallel sessions to degrade node CPU. No public exploit code is identified at time of analysis.