CVE-2026-67236: RabbitMQ Information Disclosure Vulnerability

CVE-2026-67236 Overview

CVE-2026-67236 is an information disclosure vulnerability in RabbitMQ, an open-source messaging and streaming broker. The flaw affects the management plugin's login handler, which sets an auth cookie containing base64-encoded username:password credentials after a successful POST /login request. The cookie lacks HttpOnly, Secure, SameSite, and expiration attributes, exposing credentials to multiple recovery paths. Attackers with same-origin cross-site scripting (XSS), HTTP-readable network positions, or local access to the browser cookie store can decode the credentials. The issue is tracked under [CWE-312: Cleartext Storage of Sensitive Information] and resolved in RabbitMQ versions 4.2.8 and 4.3.2.

Critical Impact
Attackers can recover RabbitMQ management credentials from an insecurely stored cookie through XSS, network interception, or local browser access.

Affected Products

RabbitMQ Server versions 4.2.0 through 4.2.7
RabbitMQ Server versions 4.3.0 and 4.3.1
RabbitMQ Management Plugin (rabbitmq_management)

Discovery Timeline

2026-09-25 - CVE-2026-67236 published to NVD
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-67236

Vulnerability Analysis

The vulnerability resides in the RabbitMQ management plugin login handler at deps/rabbitmq_management/src/rabbit_mgmt_wm_login.erl. After a successful credential check via rabbit_mgmt_util:is_authorized_user/4, the handler constructs an auth cookie by concatenating the username and password with a colon separator and base64-encoding the result. Base64 is a reversible encoding, not encryption. Any party that obtains the cookie value can trivially decode the original credentials.

The cookie is set without the HttpOnly flag, allowing JavaScript running in the same origin to read it through document.cookie. The absence of the Secure attribute permits transmission over plaintext HTTP. The missing SameSite attribute causes older browsers that default to None to attach the cookie on cross-site requests. No expiration is set, extending exposure beyond the active session.

Root Cause

The root cause is a design flaw in session handling: credentials are reflected back into client-side storage rather than being replaced by an opaque session identifier. The authentication server already validated the credentials, so storing them client-side provides no functional benefit and creates a direct credential exposure.

Attack Vector

Exploitation requires one of three positions: a same-origin XSS primitive against the RabbitMQ management UI, a network vantage point capable of reading HTTP traffic, or local access to the browser cookie store. In each case, the attacker reads the auth cookie, base64-decodes the value, and recovers the plaintext RabbitMQ username and password. Those credentials then authorize full management-plugin access, including queue manipulation and user administration.

The following patch removes the credential-bearing cookie entirely:

erlang

    Password = proplists:get_value(<<"password">>, Body),
    case rabbit_mgmt_util:is_authorized_user(ReqData, Context, Username, Password) of
        {true, ReqData1, Context1} ->
-            Value = base64:encode(<<Username/binary,":",Password/binary>>),
-            {true, cowboy_req:set_resp_cookie(<<"auth">>, Value, ReqData1), Context1};
+            {true, ReqData1, Context1};
        Other ->
            Other
    end.

Source: GitHub Commit df9e7f4

A companion change in deps/rabbitmq_management/priv/www/js/main.js removes the client-side references that previously read and cleared the auth cookie during logout. See GitHub Commit edf1fbc for the frontend fix.

Detection Methods for CVE-2026-67236

Indicators of Compromise

Presence of an auth cookie on the RabbitMQ management UI domain with a base64-decodable username:password payload.
Set-Cookie: auth=... response headers emitted by POST /login on vulnerable RabbitMQ versions.
Unexpected RabbitMQ management API calls from IP addresses or user agents that do not match legitimate administrator activity.

Detection Strategies

Inventory RabbitMQ servers and compare running versions against 4.2.8 and 4.3.2; any version in the range 4.2.0-4.2.7 or 4.3.0-4.3.1 is vulnerable.
Capture HTTP responses from /api/login and /login endpoints and alert on Set-Cookie headers containing an auth name with base64-encoded content.
Review web proxy and WAF logs for cross-site requests to RabbitMQ management endpoints originating from unrelated domains.

Monitoring Recommendations

Monitor RabbitMQ management audit logs for logins from unexpected source addresses or at anomalous times.
Track creation of new RabbitMQ users, permission changes, and policy modifications that could indicate credential reuse by an attacker.
Alert on repeated 401/403 responses followed by a successful login, which may indicate credential replay against the management plugin.

How to Mitigate CVE-2026-67236

Immediate Actions Required

Upgrade RabbitMQ Server to 4.2.8 or 4.3.2 as published in the GitHub Security Advisory GHSA-88vh-gx85-p36m.
Rotate all RabbitMQ management credentials that were used to authenticate against vulnerable versions, especially shared or administrative accounts.
Instruct administrators to clear browser cookies for the RabbitMQ management domain after upgrading.

Patch Information

The maintainers released fixed binaries in RabbitMQ v4.2.8 and RabbitMQ v4.3.2. The fix removes the server-side cowboy_req:set_resp_cookie call that stored the base64-encoded credentials and removes the matching client-side cookie handling in main.js.

Workarounds

Restrict access to the RabbitMQ management plugin to trusted administrative networks using firewall or reverse-proxy ACLs.
Terminate TLS in front of the management UI and enforce HTTPS-only access to prevent plaintext interception of the cookie.
Deploy a reverse proxy rule that strips any Set-Cookie: auth=... header emitted by RabbitMQ until the upgrade is complete.

bash

# Example NGINX rule to strip the vulnerable cookie at the reverse proxy
location /api/login {
    proxy_pass http://rabbitmq_backend;
    proxy_hide_header Set-Cookie;
    add_header Set-Cookie "auth=; Path=/; Max-Age=0; HttpOnly; Secure; SameSite=Strict";
}