CVE-2026-67413: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-67413 is an authenticated denial-of-service vulnerability in RabbitMQ's optional rabbitmq_jms_topic_exchange plugin, classified as "Authenticated RabbitMQ JMS Topic Selector Users Can Consume Broker CPU with an Unbounded LIKE Regular Expression." It affects RabbitMQ Server versions 4.0.0–4.0.22, 4.1.0–4.1.13, 4.2.0–4.2.8, and 4.3.0–4.3.2. The advisory was published on July 23, 2026, with patches released by September 25, 2026. It carries a CVSS v4.0 base score of 6.0 (Medium) (GitHub Advisory).

The root cause is CWE-1333 (Inefficient Regular Expression Complexity), a ReDoS class vulnerability in sjx_evaluator.erl within the rabbitmq_jms_topic_exchange plugin. The LIKE evaluator in the plugin converts client-supplied % wildcards to .* and _ wildcards to . PCRE fragments, then executes the resulting pattern via raw re:run/3 without {match_limit, ...} or {match_limit_recursion, ...} options — bypassing the broker's own rabbit_re:run/3 helper that enforces a 50,000-step limit. An authenticated AMQP user with standard vhost permissions can bind an x-jms-topic exchange using a pathological selector such as {'like', {ident, <<"p">>}, <<"%_" repeated 300 times followed by "X">>}, no_escape} and repeatedly publish a non-matching header value (e.g., 1,200 bytes of "a"), forcing the regex engine to explore exponentially many failed alternatives synchronously on the broker's message-routing path. The vulnerability was reproduced end-to-end against RabbitMQ 4.3.1, demonstrating a 157x slowdown in publisher-confirm latency (0.082 s vs. 0.000525 s for a control) (GitHub Advisory).

Successful exploitation degrades broker availability by consuming Erlang scheduler CPU during message routing, delaying publisher confirms and competing with unrelated broker workloads on the same node. An attacker can amplify the effect by using multiple bindings, channels, or connections to publish more messages. The vulnerability does not provide message disclosure, privilege escalation, or code execution — its impact is limited to availability degradation of the affected RabbitMQ node (GitHub Advisory).

A proof-of-concept exploit (Python script manual_minimal_poc.py) is publicly available in the GitHub Security Advisory, with numbered reproduction steps and downloadable PoC scripts that demonstrate the DoS against a live RabbitMQ instance (GitHub Advisory). Exploitation requires an authenticated AMQP account with ordinary vhost configure, write, and read permissions — no elevated tags are needed. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.003 (0.3%), reflecting low probability of near-term exploitation.

1. Obtain credentials: Acquire an authenticated AMQP account on the target RabbitMQ broker with standard vhost permissions (configure, write, read). No administrative tags are required.
2. Verify plugin is enabled: Confirm the rabbitmq_jms_topic_exchange plugin is active on the target broker (e.g., via the management API at /api/plugins or rabbitmq-plugins list).
3. Set up environment: Install the AMQP client library (pip install pika==1.4.1) and prepare the PoC script from the advisory.
4. Bind with pathological selector: Using an AMQP 0-9-1 connection, declare an x-jms-topic exchange and bind a queue with the rjms_erlang_selector argument set to a crafted LIKE expression, e.g., {'like', {ident, <<"p">>}, <<"%_" * 300 ++ "X">>}, no_escape} (601 bytes). This creates overlapping .* and . PCRE fragments.
5. Publish non-matching messages: Repeatedly publish messages with a header value of 1,200 bytes of "a" (which cannot match the trailing X), forcing the regex engine to exhaustively backtrack through all failed alternatives on the broker's routing path.
6. Amplify the attack: Open additional channels, connections, or bindings to multiply CPU consumption across the broker's scheduler threads.
7. Observe impact: Monitor publisher-confirm latency (expected ~157x increase vs. baseline) and broker CPU utilization via the management API or rabbitmqctl to confirm availability degradation (GitHub Advisory).

• Network: Sustained AMQP connections from a single client publishing high volumes of messages to an x-jms-topic exchange with unusually long header values; repeated publisher-confirm requests with abnormally high latency.
• Logs: RabbitMQ broker logs showing elevated message routing times or scheduler warnings; management API metrics reporting CPU spikes correlated with specific exchange bindings.
• Process: Erlang VM scheduler utilization consistently near 100% on the broker node without a corresponding increase in message throughput; rabbitmqctl status showing high run-queue depth.
• Configuration: Presence of x-jms-topic exchange bindings with rjms_erlang_selector arguments containing long repetitions of %_ patterns (detectable via rabbitmqctl list_bindings or the management API /api/bindings).

Upgrade RabbitMQ Server to a patched version: 4.0.23, 4.1.14, 4.2.9, or 4.3.3, depending on the currently deployed branch. The fix introduces match and recursion limits ({match_limit, 50_000} and {match_limit_recursion, 50_000}) to re:run/3 calls in the LIKE evaluator, and replaces the standard Erlang term parser with a new restricted sjx_parser module that only accepts a known-safe set of atoms (GitHub Commit, GitHub Commit). As a workaround, disable the rabbitmq_jms_topic_exchange plugin if it is not required, or restrict AMQP bind and publish permissions on x-jms-topic exchanges to trusted users only (GitHub Advisory).