RabbitMQ Server CVE-2026-66080

Exploitation requires three concrete preconditions all present simultaneously: (1) the rabbitmq_stream_management plugin must be explicitly enabled (not a default), (2) the caller must possess the RabbitMQ 'management' tag, and (3) the caller must have access to the target vhost. Given those, the attacker submits a stream partition request with an unbounded partition count (e.g. lists:seq(0, 500000000)), which validate_partitions accepts because it only enforces a lower bound of 1. Limiting factors: this is authenticated privileged access (management tag = PR:H), the vulnerable plugin is off by default, and impact is confined to availability (node crash / cross-tenant DoS) with no confidentiality or integrity effect.

This is a genuine but bounded risk, not a top-tier emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VA:H, 5.9 Medium) tells the real story: network-reachable and low-complexity, but gated behind PR:H - the caller must hold the RabbitMQ management tag and access to the target vhost - and AT:P reflects the non-default precondition that the rabbitmq_stream_management plugin be enabled. Impact is availability-only (VC:N/VI:N/VA:H): a single unbounded allocation (~8GB from lists:seq(0, 500000000)) drives the Erlang node to OOM, crashing the broker for all tenants on it. There is no EPSS score, no CISA KEV listing, and no public exploit code provided in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent - nothing here conflicts. Because the attacker already needs privileged management access, this is primarily an insider/compromised-credential or misconfigured-multitenant concern rather than an internet-wide worm risk. Prioritize patching where the stream_management plugin is enabled and management access is broadly delegated; deprioritize where the plugin is off or management is tightly held.

An attacker holding a RabbitMQ management-tagged account with access to a vhost on a broker that has the rabbitmq_stream_management plugin enabled sends a stream request specifying an enormous partition count. validate_partitions accepts it (only enforcing count >= 1), the broker attempts to allocate roughly 8GB in one shot, and the Erlang VM is killed by OOM, taking down messaging for every tenant on that node. No public proof-of-concept was provided in the intelligence, and exploitation requires authenticated privileged access (PR:H).