CVE-2026-66073

Executive Summary

CVE-2026-66073 is an unauthenticated-adjacent resource exhaustion vulnerability in the RabbitMQ message broker's management API, affecting versions 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6. A user holding only the management tag and access to a single vhost can trigger unbounded atom table growth by submitting unique values in the node JSON field of queue, exchange, or binding endpoints. Approximately 900,000 such requests exhaust the Erlang VM's atom table, causing the VM to terminate via the systemlimit mechanism, resulting in total loss of service for all tenants.

Technical Analysis

The vulnerability resides in the RabbitMQ management plugin's HTTP API handling of the node JSON field. When a client issues a PUT request to /api/queues/:vhost/:name (as well as the exchanges and bindings endpoints), the supplied node value is passed through rabbit_nodes:make and subsequently list_to_atom without first verifying that the value corresponds to an actual cluster member. The Erlang runtime maintains a global atom table that is never garbage collected; every unique atom created persists for the lifetime of the VM. Because no cluster membership check precedes the atom creation, each distinct node value permanently leaks one atom.

The NVD description notes that a March 2026 refactoring (commit ea61ce2563) introduced safe helpers in rabbit_mgmt_nodes.erl—parse_node_name, safe_atom, and require_node_name, using binary_to_existing_atom—and corrected several callers including QQ replica operations, wmauth_attempts, wmnodememory_ets, get_sort_reverse, and rabbit_federation_mgmt. However, the get_node/1 function in rabbit_mgmt_util.erl (lines 880–885), the primary vector used by direct_request/6, was not remediated. This oversight leaves a direct path from management API input to uncontrolled atom creation.

The attack surface is the management HTTP API, typically exposed on port 15672. The vulnerability class is CWE-400 (Uncontrolled Resource Consumption), specifically integer/resource exhaustion of a fixed-size runtime table. The precondition is modest: any authenticated user with the management tag and at least one vhost. The NVD text explicitly labels this "the lowest privilege" tier available in RabbitMQ's permission model, meaning no administrative, policymaker, or monitoring rights are required.

Impact materializes once approximately 900,000 unique atom-inserting requests are processed. At that threshold the Erlang VM's atom table reaches its limit, and the VM crashes via systemlimit. Because the atom table is per-VM and not per-vhost, a single malicious tenant can take down the entire broker, affecting every vhost, queue, exchange, and connected client on that node.

No public proof-of-concept, Nuclei template, or exploit code is known at the time of writing. The CVSS score is listed as N/A in the source data. The derived vector above reflects the characteristics described: network-reachable, low complexity, low privileges required, no user interaction, and high availability impact.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the specifics disclosed in the NVD description.

1. Reconnaissance / target identification. An attacker scans for RabbitMQ management interfaces, commonly on TCP port 15672, or identifies an internal broker via Shodan using product:"RabbitMQ Management". The attacker must already possess valid credentials for an account carrying the management tag and access to at least one vhost—achievable through credential reuse, a compromised application credential, or a low-privilege insider.

2. Triggering the flaw class. The attacker sends PUT requests to /api/queues/:vhost/:name (the exchanges and bindings endpoints behave equivalently, per the description) with a JSON body containing a node field set to a previously unseen value. Because get_node/1 in rabbit_mgmt_util.erl routes the value through rabbit_nodes:make and list_to_atom without a cluster membership check, each unique node string creates a new permanent atom.

3. Payload / execution method. The "payload" is not executable code but a high-cardinality sequence of unique node values. The attacker automates requests with distinct strings (for example, incrementing or randomized tokens) so that no value repeats. Each request leaks exactly one atom; no malformed or crafted syntax is required beyond a unique string. Roughly 900,000 requests are sufficient per the NVD description.

4. Post-exploitation impact. Upon crossing the atom table limit, the Erlang VM terminates via systemlimit. All tenants, queues, exchanges, bindings, and connected producers/consumers on the broker lose service simultaneously. Repeated cycles can sustain a denial-of-service condition as long as the attacker retains valid low-privilege credentials.

Impact Assessment

The primary impact is availability. A single low-privileged tenant can induce a full broker outage affecting unrelated tenants, a classic multi-tenant blast-radius escalation. Systems dependent on RabbitMQ for message delivery—order processing, event pipelines, microservice communication, and streaming workloads—will experience stalled or dropped messages. Recovery requires restarting the Erlang VM, which may itself incur downtime and message durability concerns depending on configuration. CWE-400 and the high availability subscore (A:H) in the derived vector reflect a complete loss of service. Confidentiality and integrity are not directly impacted by the described mechanism. Because exploitation needs only the lowest privilege tier, the risk is elevated in shared or hosted RabbitMQ environments where tenants are isolated logically but share the same runtime VM.

Detection Guidance

Sigma Rule

title: RabbitMQ Management API Atom Exhaustion Attempt
id: 6f4b1c2a-9d3e-4a71-8c55-0b2f7e9a1d44
status: experimental
description: Detects high-volume PUT requests to RabbitMQ management API endpoints with unique node fields, indicative of CVE-2026-66073 atom table exhaustion.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-66073
author: Valters IT Threat Intelligence
date: 2026/06/01
logsource:
  category: webserver
  product: rabbitmq
detection:
  selection_method:
    http.method: 'PUT'
  selection_uri:
    http.url|contains:
      - '/api/queues/'
      - '/api/exchanges/'
      - '/api/bindings/'
  selection_field:
    http.request.body|contains: '"node"'
  condition: selection_method and selection_uri and selection_field
fields:
  - client_ip
  - http.url
  - http.request.body
falsepositives:
  - Legitimate cluster administration tooling updating node assignments
level: high

YARA Rule

rule CVE_2026_66073_RabbitMQ_Atom_Exhaustion
{
    meta:
        description = "Detects tooling or payloads targeting RabbitMQ management API node field atom exhaustion"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-66073"
        date = "2026-06-01"
        severity = "high"

    strings:
        $ep1 = "/api/queues/" ascii nocase
        $ep2 = "/api/exchanges/" ascii nocase
        $ep3 = "/api/bindings/" ascii nocase
        $fld = "\"node\"" ascii nocase
        $m1  = "PUT /api/" ascii nocase

    condition:
        uint32(0) != 0x504b0304 and
        (any of ($ep1, $ep2, $ep3)) and $fld and $m1
}

Suricata IDS Rule

alert http any any -> any 15672 (msg:"CVE-2026-66073 RabbitMQ Management API Node Atom Exhaustion Attempt"; flow:established,to_server; http.method; content:"PUT"; http.uri; content:"/api/queues/"; http.request_body; content:"\"node\""; threshold:type both, track by_src, count 100, seconds 60; classtype:attempted-dos; sid:2026660730; rev:1; metadata:created_at 2026_06_01, cve CVE-2026-66073;)

Elastic Detection

sequence by source.ip with maxspan=60s
  [http where http.request.method == "PUT" and
   (http.request.uri : "/api/queues/*" or http.request.uri : "/api/exchanges/*" or http.request.uri : "/api/bindings/*") and
   http.request.body : "*\"node\"*"]
| stats count() as attempts by source.ip
| where attempts > 100

Splunk SPL Query

index=rabbitmq OR index=web sourcetype=rabbitmq:management OR sourcetype=access_combined
  http_method=PUT (uri="/api/queues/*" OR uri="/api/exchanges/*" OR uri="/api/bindings/*")
  request_body="*\"node\"*"
| stats count AS attempt_count values(uri) AS endpoints dc(request_body) AS unique_bodies BY clientip
| where attempt_count > 100 AND unique_bodies > 50
| sort - attempt_count

Wazuh OSSEC Rule

<group name="rabbitmq,web,attack,">
  <rule id="100730" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <match>PUT</match>
    <regex>\/api\/(queues|exchanges|bindings)\/</regex>
    <description>CVE-2026-66073: RabbitMQ management API PUT with node field - possible atom table exhaustion</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
  <rule id="100731" level="14" frequency="100" timeframe="60">
    <if_matched_sid>100730</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-66073: High-volume RabbitMQ atom exhaustion attempts from same source</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations. Restrict network access to the management API (default port 15672) to trusted administrative networks only; never expose it to untrusted tenants or the internet. Reduce the number of accounts bearing the management tag, and audit vhost permissions to remove access for users who do not require management operations. Enable rate limiting or a reverse proxy in front of the management interface to cap request volume per source. Monitor atom table growth if runtime metrics are available, and alert on sustained high-cardinality API writes.

2. Patch/upgrade steps. The NVD description states the issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6. Upgrade to the appropriate fixed release for your branch. The fix aligns rabbit_mgmt_util.erl get_node/1 with the safe helpers (parse_node_name, safe_atom, require_node_name) introduced in the March 2026 refactoring, applying cluster membership validation before atom creation. Verify the installed version after upgrade and confirm remediation in a staging environment first, since no independent patch artifact has been confirmed by tracked sources.

3. Long-term hardening. Adopt least-privilege RBAC and segregate tenants across distinct broker VMs where isolation is contractually required. Place management interfaces behind VPN or zero-trust proxies. Implement continuous version monitoring for RabbitMQ security advisories and subscribe to vendor release channels so future fixes are applied promptly. Because the Erlang atom table is a finite, non-GC resource, treat any API path that converts external input into atoms as a critical hardening target during code review.

References

• NVD — CVE-2026-66073: https://nvd.nist.gov/vuln/detail/CVE-2026-66073
• CWE-400 Uncontrolled Resource Consumption: https://cwe.mitre.org/data/definitions/400.html
• MITRE ATT&CK T1499 Endpoint Denial of Service: https://attack.mitre.org/techniques/T1499/
• RabbitMQ official documentation and release notes: https://www.rabbitmq.com/
• Erlang atom table and system limits reference: https://www.erlang.org/doc/