GHSA-r3qr-4h63-mvj2

Описание

Origin

This vulnerability was identified by Team RabbitMQ and/or other teams at Broadcom, not via a responsible disclosure from an external researcher.

Source references

deps/rabbitmq_jms_topic_exchange/src/rabbit_jms_topic_exchange.erl:189 · Resource exhaustion (atom table DoS)

Impact

An authenticated low-privilege AMQP user confined to one vhost can crash the entire broker node (cross-tenant DoS) in <100 bind calls.

Description

When a binding is created on an x-jms-topic exchange, add_binding/3 reads the rjms_erlang_selector argument and passes it through erl_scan:string/1 then erl_parse:parse_term/1. erl_scan:string/1 interns every atom literal it tokenizes. validate_binding/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.

Exploit scenario

Attacker with read on an x-jms-topic exchange + write on any queue (or configure to declare both in their own vhost) issues queue.bind with arguments={"rjms_erlang_selector": "[a0000001,a0000002,...]."}, packing ~14K fresh 8-char atom names per 128KB frame. After ~70 bind calls the 1,048,576-entry atom table is full and the VM aborts with system_limit.

Preconditions

• rabbitmq_jms_topic_exchange 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)

CVSS

CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (6.0, Moderate). Fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0.