RabbitMQ CVE-2026-67413

Requires the OPTIONAL rabbitmq_jms_topic_exchange plugin to be explicitly enabled (not part of the default RabbitMQ configuration), and an affected version between 4.0.0 and the fixed 4.0.23/4.1.14/4.2.9/4.3.3. The attacker must be an authenticated tenant (PR:L) with permissions to create bindings on the x-jms-topic exchange and to publish messages that route through them. Exploitation is limited by needing a crafted pathological rjms_erlang_selector LIKE expression whose percent/underscore wildcards expand into overlapping PCRE fragments (the AT:P attack requirement). No user interaction is needed; impact is availability-only (broker scheduler CPU exhaustion affecting all tenants).

This is a genuine but modest-severity denial-of-service issue, not a high-priority emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H = 6.0) correctly models it as a network-reachable, authenticated (PR:L), availability-only flaw (VA:H, no confidentiality/integrity impact) with an attack requirement (AT:P) reflecting the need to craft a pathological selector - consistent with CWE-1333 (inefficient regular-expression complexity / ReDoS). No EPSS score, no CISA KEV listing, and no public exploit are present in the supplied data, so exploitation status is: no public exploit identified at time of analysis. The real limiting factor is that the flaw lives in the OPTIONAL, non-default rabbitmq_jms_topic_exchange plugin and requires an authenticated tenant with rights to bind and publish - so this is a self-hosted, tenant-abuse DoS scenario rather than a broadly exploitable internet-facing bug. No conflicting signals were found: the description (authenticated tenant, network broker) aligns with the PR:L/AV:N vector. The one metadata problem is a spurious 'Microsoft' vendor tag; RabbitMQ is an open-source Broadcom/VMware project written in Erlang.

An authenticated tenant on a RabbitMQ broker that has the rabbitmq_jms_topic_exchange plugin enabled creates an x-jms-topic binding carrying a malicious rjms_erlang_selector with a LIKE clause full of overlapping percent/underscore wildcards. When the tenant publishes messages that route through that binding, the selector's uncapped re:run/3 evaluation backtracks catastrophically, saturating broker scheduler CPU and denying service to all tenants. No public proof-of-concept is referenced in the available data.