RabbitMQ EUVD-2026-87241

Requires the rabbitmq_stream_management plugin to be enabled (non-default) and an authenticated management-UI user account that has access to the target vhost - but the user needs NO configure, write, or read permission (PR:L per the vector). The attack targets PUT /api/stream/super-streams/{vhost}/{name} with a binding-keys field, and reliable node death requires the broker to run under a constrained memory limit (the advisory demonstrates a 768 MB Docker container killed by one ~4.5 MB PUT); on hosts with ample memory the impact degrades to a transient spike rather than a guaranteed crash. Limiting factors: plugin must be enabled, valid management credentials required, and effective denial of service is strongly dependent on a low memory ceiling.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H, base 7.1) is internally consistent with the description: a network-reachable, low-complexity, low-privilege attack causing pure availability impact (a node crash) with no confidentiality or integrity effect. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so exploitation status is 'no public exploit identified at time of analysis' - this is a fresh GitHub-advisory-sourced DoS rather than a known exploited threat. The realistic priority is MODERATE-to-LOW despite the 7.1: two significant gating conditions temper it. First, the rabbitmq_stream_management plugin must be enabled (non-default). Second, the demonstrated node kill depended on a tight memory limit (768 MB container) - on a broker with generous memory the same 4.5 MB body causes a transient spike rather than a guaranteed crash, which is why the observed impact is so tied to the Docker deployment mentioned in the tags. One conflicting signal to verify: the description attributes the vulnerability to the attacker-controlled 'binding-keys' field, but the single provided commit diff (0f3defd1) only adds a MAX_PARTITIONS=1000 bound on the 'partitions' field - the binding-keys allocation fix is presumably in the second listed commit (eb11bc44), which was not supplied, so the exact patched code path for the described vector is not independently confirmed here.

An attacker who holds any management-UI account with access to a vhost - but without configure/write/read permission - sends a single HTTP PUT to /api/stream/super-streams/{vhost}/{name} with a ~4.5 MB JSON body whose binding-keys field is a huge comma-separated string. The handler parses the attacker string and materializes the full stream-name list before performing the resource permission check, driving a large transient allocation that OOM-kills a memory-limited (e.g. 768 MB Docker) RabbitMQ node. No public exploit code is identified, but the technique is trivially reproducible from the advisory description.