CVE-2026-67412

Executive Summary

CVE-2026-67412 is an authorization bypass (CWE-862) in RabbitMQ's Federation plugin that permits a user holding policymaker privileges on one virtual host (vhost) to read and drain messages from an upstream vhost they are not authorized to access. The flaw stems from Federation validating the upstream connection URI without enforcing vhost-level access controls, breaking the multi-tenant isolation model RabbitMQ relies on for cross-team segmentation. Affected deployments are RabbitMQ 3.13.0 through 3.13.17, 4.0.0 through 4.0.23, 4.1.0 through 4.1.13, 4.2.0 through 4.2.8, and 4.3.0 through 4.3.2; fixed releases are 4.3.3, 4.2.9, 4.1.14, 4.0.24, and 3.13.18.

Technical Analysis

RabbitMQ organizes messaging resources into vhosts, which act as hard authorization boundaries: users are granted permissions (configure/write/read) per vhost, and a user with no grants on a given vhost should be unable to consume, publish to, or even inspect its queues and exchanges. The Federation plugin lets a broker link to an "upstream" broker and replicate message flow between them, defined by an upstream URI and an upstream set.

In vulnerable versions, this is the core defect: Federation validates the configured upstream URI but performs no vhost-access check against the connecting user's permission set on the upstream vhost. This is a classic missing-authorization-check condition (CWE-862) — the code path assumes that the presence of a valid, able-to-connect upstream URI is sufficient authority to establish a federation link, and it does not intersect that authority with the caller's per-vhost permission grants.

The consequence, exactly as described in the NVD entry: a policymaker on one vhost reads and drains messages out of another vhost it has no permission on. The trigger is the federation link itself, which can be declared by a user who holds the policymaker role on the local vhost. Because the vulnerable code validates only the upstream URI (host, port, credentials) and not the connecting principal's access rights to the target vhost, the link is established and message flow begins across the tenancy boundary.

The impact is compounded by the default acknowledgment mode. With the default ack-mode, federation consumes the source messages — they are deleted from the upstream queue rather than copied. This converts a confidentiality violation (unauthorized read of another tenant's messages) into a destructive integrity/availability event: messages belonging to the victim vhost are irreversibly removed from the source as a side effect of the cross-vhost drain. The vulnerability is therefore both a confidentiality breach and a message-loss / denial-of-messaging issue against the victim tenant.

The attack surface is the federation upstream configuration and management plane. Any principal that can define or modify an upstream / upstream set on its own vhost — typically a "policymaker" or administrator scoped to a single vhost — can reach the vulnerable path. The flaw requires network reachability to the target broker's AMQP listener and valid credentials for an account that is at least locally privileged on the attacker's own vhost.

No public proof-of-concept, exploit code, Nuclei template, or exploitation-in-the-wild evidence was identified for this CVE. CVSS score and vector are not published (N/A); the vector above is a reasoned assignment reflecting network reachability, low privileges required (a per-vhost policymaker), no user interaction, changed scope (the boundary between vhosts is crossed), and high confidentiality impact. EPSS has not been scored by FIRST.org and must not be inferred.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (missing authorization check on federation upstream) and the behavior stated in the NVD description. No specific function, class, endpoint, or parameter names are asserted beyond what the description provides.

1. Reconnaissance / target identification. The attacker identifies a RabbitMQ cluster with multiple vhosts in use and the federation plugin enabled. This is inferable from deployment topology, exposed management interfaces (HTTP management on 15672 by default, AMQP on 5672, AMQPS on 5671), and from any RabbitMQ instance the attacker already legitimately interacts with. The attacker needs a foothold account that is a policymaker on at least one vhost. Such an account is often granted to application teams, integration owners, or CI/CD automation and is therefore a realistic "low-privileged but non-trivial" starting position rather than a true unauthenticated entry point.

2. Triggering the flaw. From the vhost the attacker controls, the attacker defines an upstream (or modifies an upstream set) whose upstream URI points at the broker and vhost they wish to reach. Because the vulnerable Federation code path validates the upstream URI without any vhost-access check, the broker establishes the federation link despite the attacker holding no permission on the target vhost. On a patched broker, this same action would be declined because the connecting principal lacks grants on the destination vhost.

3. Execution at the vulnerability-class level. Once the link is established and federation begins drawing messages, messages are transferred from the victim vhost's queues into the attacker's vhost over AMQP. With the default ack-mode, the transfer is destructive at the source: each message federated out is acknowledged and deleted from the upstream queue, not duplicated.

4. Post-exploitation impact. The attacker can read the drained message content — which may contain credentials, tokens, PCI/PII payloads, order data, or other sensitive business events, depending on the victim queue — and the victim tenant loses those messages from the source broker. Depending on queue semantics and consumer expectations, this can cause silent data loss, broken downstream processing, and hard-to-attribute message gaps. The attacker may repeat link creation across multiple target vhosts to broaden collection or to systematically drain queues. Because the action uses the broker's own federation machinery and the attacker's own legitimate policymaker credentials, activity blends into expected messaging traffic and may not trigger conventional authentication-failure alarms.

Impact Assessment

Business impact is high for any RabbitMQ deployment that uses vhosts as a tenancy or trust boundary. The direct effect is unauthorized cross-tenant disclosure of message payloads plus destructive draining of the victim vhost's queues under default acknowledgment settings. In regulated environments (financial services, healthcare, government) this can constitute a confidentiality breach of regulated data and a reportable incident, and because messages are deleted rather than copied, it also risks data-integrity and availability failures for the victim workload.

Blast radius is bounded by the reachability of the federation upstream from the attacker's vhost and the queues that flow over the link, but the attacker only needs one such policymaker account to begin, and can potentially enumerate and target multiple vhosts. Systems affected are the broker cluster itself (all vhosts that share a broker with the attacker's vhost and that the attacker's federation link can reach) and every downstream consumer or application whose correctness depends on the drained queues.

CVSS subscores from the assigned vector: Attack Vector Network (the flaw is reachable over the network to the AMQP listener). Attack Complexity Low (no special conditions beyond enabling federation and holding a local policymaker role). Privileges Required Low (a scoped policymaker on the attacker's own vhost, not global admin). User Interaction None. Scope Changed (the authorization boundary between vhosts is violated). Confidentiality High (full message contents readable), Integrity None as scored in the vector, Availability None as scored — noting that data destruction at the victim source is a real operational consequence that sits between integrity and availability. The value of this vulnerability for an adversary is primarily intelligence collection with an incidental destructive side effect.

Detection Guidance

Detection should focus on the federation control plane — creation or modification of upstreams and upstream sets, particularly where the upstream targets a vhost the acting principal has no grants on — and on abnormal cross-vhost message flow and source queue drain.

Sigma Rule

title: RabbitMQ Federation Upstream Created or Modified Targeting Foreign Vhost
id: 6f2b1c4d-3a8e-4c21-9e5f-0d7a91b23c60
status: experimental
description: Detects creation or modification of a RabbitMQ federation upstream that may cross a vhost authorization boundary (CVE-2026-67412)
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-67412
author: valtersit.com
logsource:
  product: rabbitmq
  service: audit
detection:
  selection_action:
    event.type:
      - 'upstream.created'
      - 'upstream.updated'
      - 'upstream_set.created'
      - 'upstream_set.updated'
  selection_fields:
    upstream.uri|contains:
      - 'amqp://'
      - 'amqps://'
  condition: selection_action and selection_fields
falsepositives:
  - Legitimate federation configuration by platform operators
  - Planned multi-vhost integrations performed by authorized administrators
level: medium
tags:
  - attack.t1078
  - cve.2026.67412

YARA Rule

rule CVE_2026_67412_RabbitMQ_Federation_Vhost_Bypass
{
    meta:
        description = "Detects RabbitMQ federation upstream configuration artifacts referencing cross-vhost upstream URIs, associated with CVE-2026-67412 authorization bypass"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-67412"
        date = "2026-01-01"
        cve = "CVE-2026-67412"
    strings:
        $fed = "federation" nocase
        $upstream = "upstream" nocase
        $uri = "uri" nocase
        $amqp = "amqp" nocase
        $vhost = "vhost" nocase
        $policy = "policymaker" nocase
    condition:
        filesize < 2MB and
        (
            (2 of ($fed, $upstream) and 1 of ($uri, $amqp, $vhost))
            or
            ($policy and 1 of ($upstream, $fed))
        )
}

Suricata IDS Rule

alert tcp $HOME_NET any -> $HOME_NET 5672 (msg:"CVE-2026-67412 RabbitMQ Federation Cross-vhost Upstream Link Attempt"; flow:to_server,established; content:"|00 0A|"; content:"federation"; content:"upstream"; content:"amqp"; nocase; distance:0; classtype:attempted-admin; reference:cve,2026-67412; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-67412; sid:202667412; rev:1;)

alert http $HOME_NET any -> $HOME_NET 15672 (msg:"CVE-2026-67412 RabbitMQ Management Federation Upstream Modification"; flow:to_server,established; http.method; content:"PUT"; http.uri; content:"/api/parameters/federation-upstream"; content:"amqp"; nocase; classtype:attempted-admin; reference:cve,2026-67412; sid:202667413; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [process where event.category == "process" and
     process.name in ("rabbitmqctl", "curl", "python", "python3") and
     process.command_line : "*federation-upstream*"]
  [network where event.category == "network" and
     network.destination.port in (5672, 5671, 15672) and
     (process.command_line : "*amqp*" or process.command_line : "*vhost*")]

Splunk SPL Query

index=rabbitmq sourcetype=rabbitmq:audit (event_type=upstream_created OR event_type=upstream_updated OR event_type=upstream_set_created OR event_type=upstream_set_updated)
| eval actor=coalesce(user, username, principal)
| eval target_uri=coalesce(upstream_uri, uri, upstream.url)
| where like(target_uri, "%amqp%")
| stats count min(_time) as first_seen max(_time) as last_seen values(target_uri) as upstream_uris by actor, vhost
| where count >= 1
| sort - count

If management audit events are unavailable, a complementary SPL can flag the management API activity directly:

index=nginx OR index=http_logs uri="/api/parameters/federation-upstream*" method=PUT
| stats count values(referer) by clientip, uri, status
| where status >= 200 and status < 300
| sort - count

Wazuh OSSEC Rule

<group name="rabbitmq,federation,cve-2026-67412,">
  <rule id="100712" level="8">
    <decoded_as>json</decoded_as>
    <field name="event.type">upstream\.created|upstream\.updated|upstream_set\.created|upstream_set\.updated</field>
    <description>RabbitMQ federation upstream created or modified - possible cross-vhost authorization bypass (CVE-2026-67412)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>federation_abuse,</group>
  </rule>

  <rule id="100713" level="10" frequency="3" timeframe="300">
    <if_matched_sid>100712</if_matched_sid>
    <same_field>user</same_field>
    <description>Repeated RabbitMQ federation upstream changes by same principal - potential CVE-2026-67412 exploitation</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The upstream project has published fixed version numbers in the NVD description, but no patch commit, advisory, or vendor artifact was confirmed from tracked sources at the time of writing. Treat this as an "upgrade eagerly, verify independently" situation.

1. Immediate mitigations (before upgrade):

• If federation is not required, disable the Federation plugin on all brokers. This removes the vulnerable code path entirely and is the highest-value short-term control.
• If federation is required, restrict who can hold policymaker / administrator privileges on any vhost, and audit which principals currently have them. CVE-2026-67412 requires a principal able to define federation upstreams; shrinking that set shrinks the exposure.
• Constrain upstream URIs to only brokers and vhosts the organization explicitly trusts, and review existing upstream and upstream-set parameters for any URI that points at a vhost the defining principal should not reach.
• Where feasible, separate tenants onto physically or logically distinct brokers rather than relying solely on vhost isolation, since vhost separation is the boundary this CVE bypasses.
• Enforce least-privilege RabbitMQ users and network-segment the AMQP and management listeners so that only trusted hosts can establish connections that could carry a federation link.

2. Patch / upgrade steps:

• Upgrade to RabbitMQ 4.3.3, 4.2.9, 4.1.14, 4.0.24, or 3.13.18, matching the maintained release line in use. Confirm the exact build against the upstream release notes rather than relying solely on this report.
• After upgrade, re-validate upstream configurations: re-create federation links as needed and confirm that cross-vhost upstream definitions are now rejected when the acting principal lacks grants on the destination vhost.
• Rotate credentials for any vhost policymaker accounts that could be the source of a malicious link, particularly in environments where suspicious upstream activity was observed.

3. Long-term hardening:

• Treat vhost isolation as necessary but not sufficient; enforce broker-level and network-level segmentation for genuinely hostile tenants.
• Monitor the federation control plane as a privileged action surface, with alerting on upstream creation/modification (see detection rules above).
• Adopt an inventory of federation links and owners, reviewed on a schedule.
• Track the CVE vendor lifecycle and CISA KEV status; CISA KEV listing is currently NO, but that can change.

References

• NVD — CVE-2026-67412: https://nvd.nist.gov/vuln/detail/CVE-2026-67412
• MITRE CWE-862 — Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/
• RabbitMQ Federation documentation (upstream and upstream-set configuration): https://www.rabbitmq.com/docs/federation
• RabbitMQ access control / vhost permissions documentation: https://www.rabbitmq.com/docs/access-control

No threat actor campaigns, public proof-of-concept, exploit code, or in-the-wild exploitation were identified for CVE-2026-67412 in the data provided. CISA KEV status: not listed. EPSS: not yet scored by FIRST.org.