RabbitMQ CVE-2026-67238

Requires an authenticated AMQP 0-9-1 connection to any vhost (any credential, any permission level). Exploitation uses queue names or routing keys beginning with the 'amq.rabbitmq.reply-to.' prefix (RabbitMQ's direct reply-to feature), whose ETF-encoded pid node-name field is passed to binary_to_atom. The attack requires sending on the order of 1,000,000 distinct-node-name requests to exhaust the atom table. The key limiting factor is rate limiting: a per-connection or per-user rate limit low enough to make ~1M operations infeasible neutralizes the attack, as does restricting AMQP access to fully trusted clients. No user interaction and no admin privileges are needed; impact is total broker crash across all vhosts. Affected versions are prior to 4.2.7 and 4.3.1.

This is a credible, actionable availability risk against a widely-deployed message broker, though not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VA:H, VC:N/VI:N) correctly frames it: network-reachable, low complexity, but requiring an authenticated AMQP session (PR:L), with pure availability impact - no confidentiality or integrity loss. The 7.1 (HIGH) score is driven entirely by VA:H (full broker VM crash affecting all vhosts and all connections). No EPSS score, no CISA KEV entry, and no public exploit code are present in the provided data, so exploitation status is: no public exploit identified at time of analysis. The one signal that could depress real-world exploitation is the operational bar - an attacker must sustain ~1,000,000 requests, which is trivial in raw compute but noisy and rate-limitable; AC:L/AT:N are arguably generous given that a sufficiently low per-connection rate limit defeats the attack. Net: a real patch-worthy DoS for any RabbitMQ exposed to semi-trusted or multi-tenant authenticated clients, but lower urgency than an unauthenticated or code-execution flaw. Missing data: no EPSS, no KEV, no POC - none of which are errors, just absence of amplifying signals.

An attacker holding any valid AMQP 0-9-1 credential (e.g. a low-privilege tenant or a compromised application account) opens a connection to any vhost and issues ~1M operations using queue names or routing keys beginning with 'amq.rabbitmq.reply-to.', each carrying a unique attacker-chosen node-name in the ETF-encoded pid. Each request creates a new, never-reclaimed atom via binary_to_atom, exhausting the fixed Erlang atom table and crashing the entire broker VM - taking down all vhosts and all connections. No public exploit code is identified, but the technique is fully described in the advisory and the request pattern is cheap and scriptable.