RabbitMQ up to 4.3.2 Federation improper authorization

Summaryinfo

A vulnerability identified as critical has been detected in RabbitMQ up to 3.13.17/4.0.23/4.1.13/4.2.8/4.3.2. Impacted is an unknown function of the component Federation. Performing a manipulation results in improper authorization. This vulnerability is cataloged as CVE-2026-67412. It is possible to initiate the attack remotely. There is no exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in RabbitMQ up to 3.13.17/4.0.23/4.1.13/4.2.8/4.3.2. This affects some unknown functionality of the component Federation. The manipulation with an unknown input leads to a improper authorization vulnerability. CWE is classifying the issue as CWE-285. The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9 , 4.1.14, 4.0.24, and 3.13.18, Federation upstream in RabbitMQ skips vhost authorization allowing cross-vhost message access. what the bug lets you do. A policymaker on one vhost reads and drains messages out of another vhost it has no permission on. With the default ack-mode the source messages are consumed (deleted), not copied. Why that should not 1. Federation validates the upstream URI without any vhost-access Cross-vhost message read/drain from a per-vhost policymaker, breaking vhost tenancy This issue is fixed in versions 4.3.3, 4.2.9 , 4.1.14, 4.0.24, and 3.13.18.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-67412 since 07/29/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. Neither technical details nor an exploit are publicly available. MITRE ATT&CK project uses the attack technique T1548.002 for this issue.

Upgrading to version 3.13.18, 4.0.24, 4.1.14, 4.2.9 or 4.3.3 eliminates this vulnerability.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Name

• RabbitMQ

Version

• 3.13.0
• 3.13.1
• 3.13.2
• 3.13.3
• 3.13.4
• 3.13.5
• 3.13.6
• 3.13.7
• 3.13.8
• 3.13.9
• 3.13.10
• 3.13.11
• 3.13.12
• 3.13.13
• 3.13.14
• 3.13.15
• 3.13.16
• 3.13.17
• 4.0.0
• 4.0.1
• 4.0.2
• 4.0.3
• 4.0.4
• 4.0.5
• 4.0.6
• 4.0.7
• 4.0.8
• 4.0.9
• 4.0.10
• 4.0.11
• 4.0.12
• 4.0.13
• 4.0.14
• 4.0.15
• 4.0.16
• 4.0.17
• 4.0.18
• 4.0.19
• 4.0.20
• 4.0.21
• 4.0.22
• 4.0.23
• 4.1.0
• 4.1.1
• 4.1.2
• 4.1.3
• 4.1.4
• 4.1.5
• 4.1.6
• 4.1.7
• 4.1.8
• 4.1.9
• 4.1.10
• 4.1.11
• 4.1.12
• 4.1.13
• 4.2.0
• 4.2.1
• 4.2.2
• 4.2.3
• 4.2.4
• 4.2.5
• 4.2.6
• 4.2.7
• 4.2.8
• 4.3.0
• 4.3.1
• 4.3.2

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion