RabbitMQ Server CVE-2026-66072

Requires the rabbitmq_stream plugin to be enabled on the broker AND an authenticated stream-protocol user holding read access to at least one stream (PR:L). Exploitation uses post-authentication subscribe or resolve_offset_spec frames, so no user interaction is needed but valid credentials are mandatory - this is not remotely exploitable against a default unauthenticated surface. It also requires sending many frames with distinct chunk_selector values to progressively exhaust the atom table (reflected as AT:P), rather than a single request; brokers without the stream plugin enabled are not affected.

This is a genuine but moderate-priority denial-of-service issue, not a critical remote-code flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H) scores 6.0 and is internally consistent with the description: network-reachable, low complexity, but requiring an authenticated stream user (PR:L) and a probabilistic attack requirement (AT:P) that reflects the need to repeatedly feed distinct values to exhaust the Erlang atom table rather than a single-shot crash. Impact is availability-only (VC:N/VI:N/VA:H) - the whole broker node crashes, which is cross-tenant since one VM serves all vhosts. No EPSS score, no CISA KEV listing, and no public exploit were provided, so exploitation status is 'no public exploit identified at time of analysis.' The real-world risk is bounded by the preconditions: the rabbitmq_stream plugin must be enabled and the attacker must already hold valid credentials with read access to a stream, so this is primarily an insider / compromised-credential availability threat rather than an internet-wide unauthenticated exposure. No conflicting signals were found in the input; the CVSS vector and description agree.

An authenticated stream-protocol client that already holds read access to any stream sends subscribe or resolve_offset_spec frames carrying crafted, ever-changing values in the 'chunk_selector' property. Because get_chunk_selector/1 calls binary_to_atom without a whitelist or existing-atom guard, each distinct value permanently interns a new atom; a flood of such frames exhausts the Erlang atom table and crashes the entire broker node, taking down all vhosts. No public proof-of-concept was provided.