CVE-2026-67412 is a missing authorization vulnerability in RabbitMQ server's Federation upstream feature. It affects versions from 3.13.0 up to but not including 4.3.3, 4.2.9, 4.1.14, 4.0.24, and 3.13.18. The flaw allows a policymaker on one virtual host (vhost) to read and drain messages from another vhost without proper permissions, breaking vhost tenancy. Messages are consumed (deleted) rather than copied when using the default acknowledgment mode. This issue has been fixed in the specified later versions.
CVE-2026-67409 is a vulnerability in RabbitMQ server versions from 3.13.0 up to but not including 3.13.18, and similarly in 4.0.x, 4.1.x, 4.2.x, and 4.3.x prior to fixed versions. The issue arises because the JWKS key fetching mechanism does not validate HTTP response status codes when retrieving signing keys from the OAuth2 provider. As a result, error responses with valid JSON but missing keys cause all cached signing keys to be destroyed, leading to persistent denial of OAuth2/JWT authentication until a successful refresh occurs. This can cause a denial of service affecting all users relying on OAuth2 authentication.
CVE-2026-67242 is a medium severity vulnerability in rabbitmq-server affecting versions from 4.2.0 up to but not including 4.2.9 and from 4.3.0 up to but not including 4.3.3. The issue arises because the OAuth2 token expiry validation incorrectly skips checks when the token's 'exp' claim is a floating-point number rather than an integer. This allows an attacker with a previously valid signed token containing a float 'exp' value to bypass expiry checks, causing the server to accept expired tokens and maintain connections indefinitely. The vulnerability is fixed in versions 4.2.9 and 4.3.3.
CVE-2026-67223 is an LDAP Injection vulnerability in rabbitmq-server affecting multiple maintenance lines from 3.13 through 4.3. It arises from improper escaping of the ${username} variable in the user_dn_pattern configuration, allowing crafted usernames to alter LDAP bind DNs. Exploitation requires the rabbitmq_auth_backend_ldap plugin, a vulnerable user_dn_pattern, a directory layout that resolves the injected suffix usefully, and a valid password for the resulting DN. Fixed versions are identified but conflicting between advisory text and metadata, so exact fixed versions are not fully confirmed. The vulnerability has a medium severity with a CVSS 4.0 score of 6.3.
CVE-2026-67239 is a stored cross-site scripting (XSS) vulnerability in rabbitmq-server affecting versions from 3.13.0 up to but not including 3.13.18, and similarly in versions 4.0.0 up to 4.0.23, 4.1.0 up to 4.1.14, 4.2.0 up to 4.2.9, and 4.3.0 up to 4.3.3. The vulnerability arises from improper neutralization of input during web page generation in the stream-management UI, specifically rendering TLS peer-certificate distinguished names without proper escaping. This can be exploited when a non-default configuration is used with a stream TLS listener that verifies peers and an attacker can provide a trusted certificate with a malicious distinguished name. The issue is fixed in the stated fixed versions.
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, AMQP 1.0 management exchange.declare skips alternate-exchange permission check. pUT /exchanges/:name (lines 192-240) checks only configure on the declared exchange and passes XArgs straight to rabbitexchange:declare/7. It omits the checkreadpermitted(X) + checkwritepermitted(AE) that rabbitchannel.erl:2540-2548 enforces for the alternate-exchange argument on the AMQP 0-9-1 path. The same file already implements the analogous DLX check for queues (lines 708-719), confirming this is a missing-check bug rather than intentional A user with only configure on exchange X can route X's unroutable messages into an alternate exchange they have no write permission AMQP 1.0 enabled (default in RabbitMQ 4.x) Attacker has configure on at least one exchange but lacks write on the target. This issue is fixed in versions 4.2.9 and 4.3.3.
CVE-2026-66071 is a medium severity vulnerability in rabbitmq-server affecting versions from 3.13.0 up to but not including 3.13.15, and several 4.x versions up to their respective fixed releases. It involves uncontrolled resource consumption due to atom exhaustion when parsing OAuth2 JWT scope values in certain IdP configurations where scope content is user-influenced. The vulnerability is fixed in versions 3.13.15, 4.0.22, 4.1.11, 4.2.6, and 4.3.1.
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, protected tag bypass via bulk-delete. dELETE /api/users/:name refuses to delete users tagged protected (rabbitmgmtwmuser:deleteresource/2 checks isprotecteduser). POST /api/users/bulk-delete iterates the supplied username list and calls rabbitauthbackendinternal:deleteuser/2 directly , that function has no protected-tag check , so the guard is silently An administrator can delete protected-tagged service accounts via the bulk endpoint, bypassing a safeguard the test suite confirms is rabbitmqmanagement enabled Attacker has the administrator tag A protected-tagged user. This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.
CVE-2026-66073 is a medium severity vulnerability in rabbitmq-server affecting versions 3.13.0 through 3.13.14, 4.0.0 through 4.0.19, 4.1.0 through 4.1.10, and 4.2.0 through 4.2.5. It involves uncontrolled resource consumption via atom table exhaustion through the management API's node field. This flaw allows an attacker with management tag privileges on a single vhost to leak atoms permanently, potentially crashing the Erlang VM after roughly 900,000 requests and causing denial of service for all tenants. The issue was fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
CVE-2026-67237 is a cross-site scripting (XSS) vulnerability in rabbitmq-server versions 4.2.0 through 4.2.7 and 4.3.0 through 4.3.1. The issue arises because the set_token_auth/2 function inserts a bearer token from the Authorization header or access_token cookie into OAuth bootstrap JavaScript without proper escaping. This allows attacker-controlled token content to execute JavaScript in the management UI origin. The vulnerable endpoint is exposed before authentication only when management.oauth_enabled is true. Exploitation via the cookie path requires the attacker to plant an access_token cookie on the management host. The vulnerability is fixed in versions 4.2.8 and 4.3.2.
CVE-2026-67234 is an improper input validation vulnerability in rabbitmq-server versions 4.2.0 through 4.2.7 and 4.3.0 through 4.3.1. The issue arises from the use of term_to_binary/1 on certain atoms to clear cookies, resulting in non-ASCII cookie names that violate RFC 6265. This can cause browsers to fail to delete authentication-mechanism preference cookies, leading to stale preferences persisting across logout and login cycles. The vulnerability does not allow code execution or data exfiltration. It is fixed in versions 4.2.8 and 4.3.2.
CVE-2026-67225 is a medium severity vulnerability in rabbitmq-server affecting versions 3.13.0 through 3.13.14, 4.0.0 through 4.0.19, 4.1.0 through 4.1.10, and 4.2.0 through 4.2.5. The issue involves the stream protocol storing the FrameMax value negotiated during the Tune handshake but failing to validate inbound frame lengths against this value. This allows a remote client to cause excessive memory consumption and potentially a denial of service when the stream plugin is enabled. The vulnerability is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the Web STOMP WebSocket handler enforced neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled, and no authentication is required to reach the vulnerable path. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, mechanisms/1 applied list_to_atom/1 to every colon-delimited token in an attacker-controlled auth_mechanism value, permanently consuming Erlang VM atoms and allowing the node to be crashed with a large request. Exploitation requires the Shovel or Federation plugin to be in use, and setting auth_mechanism requires the policymaker tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.8 and 4.3.2, a successful POST /login caused is_authorized/2 to set an auth cookie containing base64-encoded username:password credentials without HttpOnly, Secure, SameSite, or expiration protections. Because base64 is encoding rather than encryption, an attacker with same-origin cross-site scripting, an HTTP-readable network position, or local access to the browser cookie store could recover the actual login credentials; older browsers that treated an absent SameSite attribute as None also sent the cookie cross-site. This issue is fixed in versions 4.2.8 and 4.3.2.
CVE-2026-67233 is a missing authorization vulnerability in rabbitmq-server affecting the shovel management resource. Prior to fixed versions, users with the monitoring tag, intended for read-only access, could delete or restart shovels in any vhost they could see. This is due to insufficient role checks on DELETE operations in the shovel management API. The issue requires the rabbitmq_shovel and rabbitmq_shovel_management plugins to be enabled. It is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
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, The AMQP 0-9-1 shovel calls amqp_uri:remove_credentials before storing its connection URI, but the AMQP 1.0 shovel stores the raw URI including the password. The stored URI is visible via GET /api/shovels and via rabbitmqctl shovel_status. Preconditions include The Shovel plugin must be in use with AMQP 1.0 shovels configured using URI-embedded credentials. Reading the exposed status requires the monitoring tag.. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
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, The trust-store plugin installs a verify_fun that overrides {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer} when the presented cert "matches" a whitelisted one. The match key is extract_issuer_id/1 → public_key:pkix_issuer_id/2 → {IssuerName, SerialNumber} , both fields are taken verbatim from the presented certificate body and contain no public-key, SKI, fingerprint or signature material. is_whitelisted/1 is a pure ets:member lookup; the stored full DER is used only for list/0 display and is never compared against the presented cert. cacerts is [], so the whitelisted cert is never used as a trust anchor for path validation either. TLS client-authentication bypass: an attacker who knows the issuer DN + serial of any whitelisted certificate can connect with a forged self-signed cert. Preconditions include rabbitmq_trust_store plugin enabled and used as the TLS verify_fun Attacker knows or can guess the {Issuer, Serial} of at least one whitelisted cert (non-secret; exposed via CLI/logs/any cert copy). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
RabbitMQ is a messaging and streaming broker. Prior to versions 4.0.22, 4.1.11, 4.2.6, and 4.3.0, accept_content/2 at line 56 calls rabbit_stream_manager:create_super_stream/... directly after is_authorized (which only checks the management tag + vhost access via is_authorized_vhost). The stream-protocol equivalent (rabbit_stream_reader.erl create_super_stream handler) calls rabbit_stream_utils:check_super_stream_management_permitted/4 which enforces configure on the exchange and each partition queue. The HTTP handler omits this call entirely. A user with management tag and vhost access , but no configure permission on any resource , can create super-streams (an exchange + N partition stream queues + bindings) via the HTTP API. The native stream-protocol path enforces configure on each resource; the HTTP path does not, creating a privilege escalation from 'can view' to 'can create persistent cluster-wide resources.' Preconditions include rabbitmq_stream_management plugin enabled management tag + vhost access (no resource permissions needed). This issue is fixed in versions 4.0.22, 4.1.11, 4.2.6, and 4.3.0.
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, match_value/3 passes the user-supplied ?name= regular expression to re:run with no match_limit option, and executes it once per resource in the result set. OTP's default 10M match_limit caps each call at roughly 100-200ms, but the regex runs once per resource in the result set. With a large set, for example 5000 queues at 150ms each, a single request consumes 12 or more minutes of CPU. Parallel requests saturate the schedulers. The use_regex=true option is a supported feature on list endpoints, so this path is reachable through normal API use. Preconditions include Any user with the management tag can exploit this.. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.