CVE-2026-67220: RabbitMQ: JMS topic exchange erl_scan atom exhaustion
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0, When a binding is created on an x-jms-topic exchange, addbinding/3 reads the rjmserlangselector argument and passes it through erlscan:string/1 then erlparse:parseterm/1. erlscan:string/1 interns every atom literal it tokenizes. validatebinding/2 is a no-op (-> ok.), there is no length cap, and the surrounding try/catch cannot reclaim atoms. The Java JMS client compiles selectors client-side, but the server does not enforce this , a raw AMQP client can send arbitrary selector strings. An authenticated low-privilege AMQP user confined to one vhost can crash the entire broker node (cross-tenant DoS) in <100 bind calls. Preconditions include rabbitmqjmstopicexchange plugin enabled (bundled; required for any JMS deployment) Authenticated AMQP user with read on an x-jms-topic exchange + write on a queue (or configure to declare both). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.0
Event History
Frequently Asked Questions
Who can exploit this issue in a RabbitMQ deployment?
An authenticated low-privilege AMQP user can exploit it if the rabbitmq_jms_topic_exchange plugin is enabled and the user has read permission on an x-jms-topic exchange plus write permission on a queue. A user with configure permission can also meet the prerequisite by declaring the exchange and queue.
Is a Java JMS client required to trigger the problem?
No. Although Java JMS clients compile selectors client-side, the broker does not enforce that behavior. A raw AMQP client can submit arbitrary selector strings in a binding request.
What is the operational impact?
Fewer than 100 binding requests can exhaust Erlang atoms and crash the entire broker node. A user restricted to a single vhost can therefore cause a cross-tenant denial of service.
What configurations are affected?
The issue requires the rabbitmq_jms_topic_exchange plugin and use of an x-jms-topic exchange. The plugin is bundled and is required for JMS deployments, but the described attack also requires an authenticated user with the relevant exchange and queue permissions.
Which versions contain the fix?
The issue is fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.