CVE-2026-67413: RabbitMQ JMS Topic Exchange DoS Vulnerability

CVE-2026-67413 Overview

CVE-2026-67413 affects RabbitMQ, an open-source messaging and streaming broker widely deployed for asynchronous application communication. The flaw resides in the optional rabbitmq_jms_topic_exchange plugin. Its x-jms-topic exchange accepts a client-controlled rjms_erlang_selector binding expression. The LIKE evaluator expands % and _ wildcards into overlapping PCRE fragments, then executes them through raw re:run/3 without match or recursion limits. An authenticated tenant with bind and publish permissions can craft pathological selectors that exhaust broker scheduler CPU, resulting in denial of service. The issue is classified as uncontrolled resource consumption [CWE-1333].

Critical Impact
An authenticated low-privilege tenant can submit a malicious JMS selector that pins the broker's Erlang scheduler and denies service to all queues on the node.

Affected Products

RabbitMQ Server 4.0.0 through 4.0.22
RabbitMQ Server 4.1.x prior to 4.1.14
RabbitMQ Server 4.2.x prior to 4.2.9 and 4.3.x prior to 4.3.3 (with rabbitmq_jms_topic_exchange plugin enabled)

Discovery Timeline

2026-09-25 - CVE-2026-67413 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-67413

Vulnerability Analysis

The rabbitmq_jms_topic_exchange plugin implements Java Message Service (JMS) selector semantics on top of AMQP topic routing. Clients attach selectors as binding arguments, and the broker evaluates them against each published message. The LIKE operator in JMS selectors supports % and _ wildcards, which the plugin translates into Perl-Compatible Regular Expression (PCRE) fragments.

Because the plugin accepted the compiled selector term directly from the client and then invoked re:run/3 without match_limit or match_limit_recursion options, a crafted expression could trigger catastrophic backtracking. The Erlang regex engine would spin on a single message indefinitely, consuming scheduler threads and starving other broker activity.

Root Cause

Two defects combine to produce the vulnerability. First, validate_binding/2 in rabbit_jms_topic_exchange.erl performed no sanitization of the ?RJMS_COMPILED_SELECTOR_ARG binding argument, trusting whatever Erlang term the client encoded. Second, the shared like/2 helper in rabbit_amqp_filter_sql.erl passed subjects to re:run/3 with only {capture, none}, omitting bounds on PCRE match and recursion steps.

Attack Vector

Exploitation requires valid broker credentials and permission to declare a binding against an x-jms-topic exchange, then publish a message that matches the targeted routing key. The attacker encodes an adversarial LIKE pattern, binds a queue using that selector, and publishes a payload engineered to force exponential backtracking. The affected scheduler stalls on each matching message, degrading or halting message delivery across tenants on the node.

erlang

%% Patch: deps/rabbitmq_jms_topic_exchange/src/rabbit_jms_topic_exchange.erl
%% Sanitize selectors before creating bindings
validate_binding(_X, #binding{args = Args}) ->
  case get_string_arg(Args, ?RJMS_COMPILED_SELECTOR_ARG) of
    error ->
      ok;
    Selector ->
      case decode_term(Selector) of
        {ok, _} ->
          ok;
        {error, Reason} ->
          {error, {binding_invalid,
                   "invalid JMS selector: ~tp", [Reason]}}
      end
  end.

Source: RabbitMQ Commit #20203c5

erlang

%% Patch: deps/rabbit/src/rabbit_amqp_filter_sql.erl
like(Subject, CompiledRe)
  when element(1, CompiledRe) =:= re_pattern ->
    try re:run(Subject, CompiledRe, [{capture, none},
                                     {match_limit, 50_000},
                                     {match_limit_recursion, 50_000}]) of
        match ->
            true;
        _ ->
            false
    end.

Source: RabbitMQ Commit #60de2fb

Detection Methods for CVE-2026-67413

Indicators of Compromise

Sudden sustained CPU saturation on one or more RabbitMQ scheduler threads with no corresponding growth in message throughput.
Binding declarations against x-jms-topic exchanges containing unusually long or deeply nested LIKE patterns with repeated % and _ wildcards.
Message delivery latency spikes or queue backlogs appearing shortly after a new JMS binding is created by a low-privilege tenant.

Detection Strategies

Audit rabbitmq.log and management plugin events for binding.create operations referencing the rjms_erlang_selector or compiled selector argument.
Compare the enabled plugins list across brokers using rabbitmq-plugins list -e to inventory where rabbitmq_jms_topic_exchange is active and in scope.
Baseline per-user bind and publish rates, then alert on sudden selector-heavy binding activity from accounts that previously had none.

Monitoring Recommendations

Export Erlang scheduler utilization and run queue length via Prometheus and alert on sustained saturation uncorrelated with publish rate.
Track channel.close and connection error events for timeouts affecting JMS topic consumers as a proxy for stalled selector evaluation.
Forward RabbitMQ audit and management logs to a centralized analytics backend so unusual binding arguments can be correlated with broker performance degradation.

How to Mitigate CVE-2026-67413

Immediate Actions Required

Upgrade RabbitMQ to 4.0.23, 4.1.14, 4.2.9, or 4.3.3, matching your current minor release line.
If the rabbitmq_jms_topic_exchange plugin is not required, disable it with rabbitmq-plugins disable rabbitmq_jms_topic_exchange to remove the attack surface.
Review existing bindings against x-jms-topic exchanges and remove any selectors created by untrusted or unexpected tenants.
Restrict configure and write permissions on virtual hosts that host JMS topic exchanges to trusted service accounts only.

Patch Information

The RabbitMQ team addressed the issue in RabbitMQ Release v4.2.9 and RabbitMQ Release v4.3.3, along with 4.0.23 and 4.1.14. The fixes introduce selector sanitization in validate_binding/2 and enforce match_limit and match_limit_recursion of 50_000 on all re:run/3 invocations in the LIKE evaluator. Full details are available in the RabbitMQ Security Advisory GHSA-chxf-3hfg-j8f7.

Workarounds

Disable the rabbitmq_jms_topic_exchange plugin on brokers where JMS semantics are not used.
Apply RabbitMQ permission policies to prevent untrusted users from binding to x-jms-topic exchanges until the upgrade is deployed.
Place rate limits on binding creation per user through the management API or an upstream proxy to blunt rapid abuse attempts.

bash

# Disable the vulnerable plugin and verify the upgraded version
rabbitmq-plugins disable rabbitmq_jms_topic_exchange
rabbitmqctl version

# Restrict a tenant to publish-only, blocking binding creation
rabbitmqctl set_permissions -p /prod app_user "^$" ".*" ".*"