RabbitMQ CVE-2026-67220

Requires: (1) the rabbitmq_jms_topic_exchange plugin enabled - bundled with RabbitMQ and required for any JMS deployment, so present in JMS shops but not in brokers that do not use JMS (this is the AT:P attack requirement); (2) an authenticated AMQP user (PR:L) with read permission on an x-jms-topic exchange plus write permission on a queue, or configure permission to declare both; (3) use of a raw/arbitrary AMQP client rather than the Java JMS client, since the server does not enforce the client-side selector compilation. No end-user interaction is needed (UI:N) and the vector is network-reachable (AV:N). The main limiting factors are the plugin-enabled precondition and the authentication requirement - this is not exploitable against a default broker with the JMS plugin disabled, nor by an unauthenticated attacker.

This is a genuine but moderate-priority availability issue, not an overhyped high-CVSS case. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H, base 6.0) correctly isolates the impact to availability only - there is no confidentiality or integrity loss, and no scope change to a subsequent system (SC/SI/SA:N). The 'real' risk hinges on three factors that pull in different directions: (1) exploitation is cheap and reliable - an authenticated low-privilege AMQP user confined to a single vhost can crash the entire Erlang VM node in fewer than 100 bind calls, and because atoms are never garbage-collected the effect is a permanent, non-recoverable resource-exhaustion crash affecting ALL tenants/vhosts on that node (cross-tenant blast radius); (2) it requires authentication (PR:L) plus the rabbitmq_jms_topic_exchange plugin being enabled, captured as AT:P (attack requirement present); (3) there is no CISA KEV listing, no public exploit code, and no EPSS score supplied, so there is no signal of active or widespread exploitation. Net: prioritize patching where the JMS topic exchange plugin is in use and multi-tenant brokers are shared, but this is a privileged-insider/compromised-credential DoS rather than an unauthenticated internet-facing critical. The AT:P condition (plugin enabled) is the main real-world limiter; the description notes the plugin is bundled and required for any JMS deployment, so it is present in JMS shops but absent in brokers that do not use JMS.

An attacker with valid low-privilege AMQP credentials for one vhost (e.g., a compromised application account) connects with a raw AMQP client rather than the Java JMS client, bypassing the client-side selector compilation. They repeatedly create bindings on an x-jms-topic exchange, each carrying a long, unique rjms_erlang_selector string that erl_scan:string/1 tokenizes and permanently interns as new atoms; in under 100 such bind calls the Erlang atom table is exhausted and the entire broker node crashes, denying service to every tenant on it. No public exploit code is identified at time of analysis, but the mechanism is fully described in the GHSA advisory.