RabbitMQ Server CVE-2026-66071

Requires the rabbitmq_auth_backend_oauth2 plugin to be explicitly enabled (not the default auth backend), AND an IdP configured such that scope content - specifically 'tag:' scope values - can be influenced by the authenticating user. The attacker must hold or obtain validly-signed JWTs because signature verification precedes scope parsing; forged scopes are rejected. Exploitation further requires many repeated logins each carrying a distinct novel tag value to exhaust the bounded Erlang atom table. Limiting factors: non-default plugin, permissive-IdP dependency, and the need for a large volume of unique-tag authentications, which together significantly narrow the exploitable population.

This is a high-CVSS-looking but low-real-risk issue in practice. The provided CVSS 4.0 vector (6.0, AV:N/AC:L/AT:P/PR:L/UI:N/VA:H) correctly scopes it to a pure availability impact (VC:N/VI:N/VA:H) with an attack requirement (AT:P) and low privileges (PR:L). No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis.' Two strong mitigating preconditions materially lower real-world risk below what the base score suggests: (1) the vulnerable rabbitmq_auth_backend_oauth2 plugin must be explicitly enabled - it is NOT a default configuration - and (2) the identity provider must be configured to permit attacker-influenced scope values in signed JWTs. Critically, the token signature is verified BEFORE scope parsing, so an attacker cannot forge scopes; they can only leak atoms through an IdP that legitimately mints tokens with user-controllable 'tag:' scopes. I assess AC:H rather than the input's AC:L because successful exploitation requires both the non-default OAuth2 topology and repeated logins with many distinct novel tag values to exhaust the Erlang atom table. Net: a genuine unrecoverable DoS (BEAM VM crash affecting all tenants), but gated behind an uncommon configuration, making it a patch-on-schedule item rather than an emergency for most deployments.

In a RabbitMQ deployment using the OAuth2 auth backend with an IdP that lets users influence scope content, an attacker repeatedly authenticates with validly-signed JWTs each carrying a fresh, never-before-seen 'tag:' scope value. Each novel value is coerced to a permanent Erlang atom that is never garbage-collected; after enough distinct logins the atom table hits its hard limit and the BEAM VM crashes (system_limit), taking the broker down for all tenants. No public exploit code is identified at time of analysis.