RabbitMQ's Atom table can be exhausted by sending a large number of distinct node values via the management API endpoints such as /api/queues/:vhost/:name. Each requested node value is converted into a new atom without checking cluster membership, permanently leaking an atom. Repeated requests eventually exceed the system limit and crash the Erlang virtual machine, causing the broker to stop. The downtime affects all tenants using the broker, resulting in a denial of service.

The vulnerable versions are RabbitMQ server 3.13.0 through 3.13.14, 4.0.0 through 4.0.19, 4.1.0 through 4.1.10, and 4.2.0 through 4.2.5. Versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6 contain the fix and are not affected.

The vulnerability has a CVSS score of 6, indicating medium severity, and has no current EPSS data or KEV listing, suggesting it is not highly targeted or exploited yet. An attacker who is authenticated with a management‑level user and has access to at least one virtual host can exploit the issue by repeatedly issuing PUT requests to the management API with unique node values. The exploit does not require elevated privileges beyond those of normal management users; it leverages the privileged endpoint to trigger permanent atom leaks, leading to a crash of the broker and denial of service. Despite the lack of widespread exploitation evidence, the impact on availability makes it a significant risk in active environments.