CVE-2026-66073

Analyzed Analyzed - Analysis Complete

Atom Table Exhaustion in RabbitMQ via Management API

Publication date: 2026-09-25

Last updated on: 2026-10-08

Assigner: GitHub, Inc.

Description

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, Atom table exhaustion via management API node field. pUT /api/queues/:vhost/:name (and the exchanges and bindings endpoints) accepts a node JSON field. The value goes through rabbitnodes:make → listtoatom with no cluster membership check first. Each unique value permanently leaks one atom. A March 2026 refactoring (ea61ce2563) introduced safe helpers in rabbitmgmtnodes.erl (parsenodename, safeatom, and requirenodename, using binarytoexistingatom) and fixed several callers (QQ replica ops, wmauthattempts, wmnodememoryets, getsortreverse, and rabbitfederationmgmt), but getnode/1 in rabbitmgmtutil.erl:880-885, the primary vector used by directrequest/6, was not Roughly 900K requests crash the VM via systemlimit, and all tenants lose Any user with the management tag and one vhost, the lowest privilege This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-25

Last Modified

2026-10-08

Generated

2026-10-16

AI Q&A

2026-09-25

EPSS Evaluated

2026-10-14

NVD

CVE-2026-66073

EUVD

EUVD-2026-87149

Affected Vendors & Products

Vendor	Product	Version / Range
broadcom	rabbitmq_server	From 3.13.0 (inc) to 3.13.15 (exc)
broadcom	rabbitmq_server	From 4.0.0 (inc) to 4.0.20 (exc)
broadcom	rabbitmq_server	From 4.1.0 (inc) to 4.1.11 (exc)
broadcom	rabbitmq_server	From 4.2.0 (inc) to 4.2.6 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-400	The product does not properly control the allocation and maintenance of a limited resource.

Attack-Flow Graph

Executive Summary

RabbitMQ versions 3.13.0 to 3.13.15 and 4.0.20 to 4.2.6 are vulnerable to atom table exhaustion via the management API. The vulnerability occurs when the node field in API requests like PUT /api/queues/:vhost/:name is processed without checking cluster membership. Each unique node value permanently leaks one atom, leading to system crashes after roughly 900K requests.

Detection Guidance

This vulnerability can be detected by monitoring for excessive API requests to RabbitMQ management endpoints like /api/queues/:vhost/:name, /api/exchanges, or /api/bindings. Check for repeated requests with unique node field values that may cause atom table exhaustion. Monitor system logs for crashes or performance degradation in RabbitMQ.

Impact Analysis

The vulnerability can crash the RabbitMQ VM via system limit exhaustion, causing all tenants to lose access. Any user with the management tag and access to one vhost can exploit this, even with low privileges, to disrupt service availability.

Compliance Impact

This vulnerability could lead to denial of service (DoS) conditions, causing system unavailability. For GDPR, this may impact availability of personal data processing systems, potentially violating Article 32 (security of processing). For HIPAA, it could disrupt critical healthcare operations, affecting availability of protected health information systems.

Mitigation Strategies

Upgrade RabbitMQ to a patched version (3.13.15, 4.0.20, 4.1.11, or 4.2.6) immediately. Temporarily restrict access to the management API endpoints by IP or disable the management plugin if not required. Monitor API request rates and block suspicious traffic patterns.

Hi! I’m here to help you understand CVE-2026-66073. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70