CVE-2026-67229: RabbitMQ: Admin-only atom exhaustion: atomize_keys on vhost metadata
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, addvhost/2 calls rabbitdatacoercion:atomizekeys/1 (the unsafe variant using binarytoatom) on the vhost metadata map. The 20 MB management body limit fits ~1M+ short keys. Admin-only. An administrator importing a crafted definitions file can crash the node in a single request: a vhosts entry with ~1M unique metadata keys exhausts the atom table during import. Preconditions include administrator tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.0
Event History
Frequently Asked Questions
Who can exploit this issue?
Exploitation requires administrator privileges. The attacker must be able to import a crafted RabbitMQ definitions file containing a vhost entry with a very large number of unique metadata keys.
Are default request-size limits sufficient to prevent exploitation?
No. The 20 MB management body limit can accommodate more than one million short metadata keys, which is sufficient to exhaust the atom table in a single import request.
What is the impact of a successful exploit?
A crafted definitions import can exhaust the Erlang atom table and crash the RabbitMQ node.
Which versions contain the fix?
The issue is fixed in RabbitMQ versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.