CVE-2026-67412 is a high severity (CVSS 7.1) authorization flaw in the RabbitMQ Federation plugin. It skips vhost access checks, so a policymaker on one vhost can read and drain messages from a vhost they cannot log in to. Fixed in 3.13.18, 4.0.24, 4.1.14, 4.2.9 and 4.3.3.
What's affected
Fixed versions in the record and the GitHub advisory (GHSA-42pc-678q-v8qj) are 4.3.3, 4.2.9, 4.1.14, 4.0.24 and 3.13.18. The advisory's affected ranges are 4.3.0 up to 4.3.3, 4.2.0 up to 4.2.9, 4.1.0 up to 4.1.14, 4.0.0 up to 4.0.24, and 3.13.0 up to 3.13.18.
Note that the 4.0 line was fixed in 4.0.24 here, while the related RabbitMQ issues CVE-2026-67407 and CVE-2026-67411 are fixed in 4.0.23. Use the newest 4.0 release so all of them are covered.
Severity differs. The record scores it 7.1 (High). The advisory labels it Moderate.
The scenario is multi tenant. Federation must be in use, and the attacker must be a user with the policymaker tag on one vhost.
How to check if you're exposed
rabbitmqctl version
rabbitmq-diagnostics server_version
Run these on each node. In containers, run them with docker exec or kubectl exec against the broker pod, and also check the image tag you deploy. Mixed version clusters during a rolling upgrade are common, so check every node, not just one.
Then check whether federation is enabled and who can set policies:
rabbitmq-plugins list | grep federation
rabbitmqctl list_users
If federation is not enabled, the plugin is not in play. If it is, note every user with the policymaker tag, and check which vhosts they can access. Per-vhost policymakers are the people the advisory describes.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade to 4.3.3, 4.2.9, 4.1.14, 4.0.24 or 3.13.18, or newer on your line.
- Disable the federation plugin on brokers that do not need it.
- Review which users hold the policymaker tag and remove it where it is not needed.
- Check federation upstream definitions for URIs pointing to vhosts that the definer should not reach.
- Note that the default acknowledgement mode consumes the source messages, so check for unexplained missing messages in sensitive queues.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The class is CWE-862, missing authorization. The vhost is RabbitMQ's tenancy boundary, and the policymaker role is documented as scoped to vhosts the user can log in to. The advisory says federation validated the upstream URI without checking vhost access, so the plugin acted with broader rights than the person who configured it.
The data loss angle is worth noting. With default settings the messages are consumed, not copied, so the harm is not only a read. The 4.2.9 release notes mention stricter validation of federation upstream URIs, which fits this fix. The record does not mark this CVE as known exploited.
Quick check
Does single tenant use matter here?
The risk is cross-vhost, so a broker with one vhost and trusted administrators has less exposure, but the upgrade is still advised.
What happens to the source messages?
With the default acknowledgement mode, the advisory says they are consumed and deleted from the source, not copied.
Sources
- https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-42pc-678q-v8qj
- https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.9
- Record: NVD entry for CVE-2026-67412 (score 7.1, HIGH)
Last reviewed: 18 October 2026.
