CVE-2026-67220: RabbitMQ x-jms-topic Exchange DoS Vulnerability

CVE-2026-67220 Overview

CVE-2026-67220 is a denial of service vulnerability in RabbitMQ, an open-source messaging and streaming broker. The flaw resides in the rabbitmq_jms_topic_exchange plugin, which processes selector strings supplied by clients when creating bindings on x-jms-topic exchanges. The plugin passes selector input to erl_scan:string/1, which interns every atom literal it tokenizes. Because atoms in the Erlang VM are never garbage collected, an authenticated low-privilege AMQP user can exhaust the global atom table with fewer than 100 bind operations. The result is a cross-tenant broker crash affecting all vhosts on the node. This vulnerability is tracked under CWE-400: Uncontrolled Resource Consumption.

Critical Impact
An authenticated low-privilege AMQP user scoped to a single vhost can crash the entire RabbitMQ broker node, producing a cross-tenant denial of service in fewer than 100 bind calls.

Affected Products

RabbitMQ Server versions prior to 3.13.15
RabbitMQ Server 4.0.x prior to 4.0.20, 4.1.x prior to 4.1.11, 4.2.x prior to 4.2.6
Deployments with the rabbitmq_jms_topic_exchange plugin enabled (required for any JMS workload)

Discovery Timeline

2026-09-23 - CVE-2026-67220 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-67220

Vulnerability Analysis

RabbitMQ's JMS topic exchange plugin implements SQL-like message selectors defined by the Java Message Service specification. When a binding is created against an x-jms-topic exchange, the plugin's add_binding/3 function reads the rjms_erlang_selector binding argument and pipes it through erl_scan:string/1 followed by erl_parse:parse_term/1.

The Erlang tokenizer interns every atom literal it encounters into a process-wide atom table. That table is bounded (default 1,048,576 entries), never shrinks, and its entries are never reclaimed. Reaching the limit terminates the Erlang runtime, taking down the broker node and every tenant hosted on it.

The plugin's validate_binding/2 callback is a no-op returning ok, no length cap is enforced on the selector string, and the surrounding try/catch around parsing cannot reclaim atoms that have already been interned during tokenization.

Root Cause

The root cause is uncontrolled resource consumption in the selector parsing path. Client-supplied text is fed to a tokenizer that mutates a non-reclaimable global resource before any validation runs. The Java JMS client normally compiles selectors on the client side and never sends raw expressions, but the server does not enforce that contract. A raw AMQP 0-9-1 client can therefore submit arbitrary selector strings containing unique atom literals on each bind.

Attack Vector

An attacker requires an authenticated AMQP account with read permission on an x-jms-topic exchange and write permission on a queue, or configure permission to declare both. The attacker issues repeated queue.bind calls, each supplying a rjms_erlang_selector argument whose text contains a large batch of previously unseen atom literals. After enough bind operations, the atom table reaches capacity and the Erlang VM aborts. Refer to GitHub Security Advisory GHSA-r3qr-4h63-mvj2 for the vendor description of the exploitation path.

// No verified public exploit code is available. The vulnerability
// mechanism is described in prose above. See the vendor advisory
// for parser-level technical detail.

Detection Methods for CVE-2026-67220

Indicators of Compromise

Sustained growth in the Erlang atom table size reported by erlang:memory(atom_used) or the RabbitMQ management metrics endpoint.
Unusual volume of queue.bind operations against x-jms-topic exchanges originating from a single authenticated user or connection.
Broker node crashes accompanied by system_limit errors referencing atom table exhaustion in the RabbitMQ log.

Detection Strategies

Baseline normal binding rates per user and vhost, then alert on deviations targeting JMS topic exchanges.
Inspect binding arguments for oversized or high-entropy rjms_erlang_selector values that would not be produced by a compiled JMS client.
Correlate authentication events with binding operations to identify low-privilege accounts issuing rapid bind sequences.

Monitoring Recommendations

Scrape rabbitmq_erlang_atoms_used from the Prometheus exporter and alert when the value trends toward the configured +t limit.
Enable RabbitMQ audit logging for AMQP method frames and forward broker logs to a centralized data lake for retention and query.
Monitor per-connection channel-level bind rates and flag connections exceeding sensible operational thresholds.

How to Mitigate CVE-2026-67220

Immediate Actions Required

Upgrade RabbitMQ Server to a fixed release: 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0.
If patching is deferred, disable the rabbitmq_jms_topic_exchange plugin on brokers that do not host JMS workloads.
Audit AMQP user permissions and remove read, write, or configure access to x-jms-topic exchanges for accounts that do not need it.

Patch Information

The RabbitMQ maintainers addressed CVE-2026-67220 in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. Release notes and upgrade guidance are available in the RabbitMQ Server v4.2.6 release notes and cross-referenced in GHSA-r3qr-4h63-mvj2.

Workarounds

Disable the JMS topic exchange plugin using rabbitmq-plugins disable rabbitmq_jms_topic_exchange where JMS is not required.
Restrict AMQP account permissions so untrusted tenants cannot bind against x-jms-topic exchanges.
Place a proxy or policy layer in front of RabbitMQ to reject queue.bind frames containing rjms_erlang_selector arguments from untrusted sources.

bash

# Disable the vulnerable plugin on nodes that do not require JMS
rabbitmq-plugins disable rabbitmq_jms_topic_exchange

# Revoke access to x-jms-topic exchanges for low-trust users
rabbitmqctl set_permissions -p /tenant-a untrusted_user "^$" "^$" "^$"