CVE-2026-67411 is an incorrect authorization vulnerability in rabbitmq-server affecting native MQTT and MQTT over WebSocket when used behind a trusted PROXY Protocol frontend. Versions from 3.13.0 up to but not including 3.13.18, 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 are affected. The flaw allows an attacker with valid credentials for a loopback-restricted account to bypass source-address restrictions due to loss of the proxy-derived client address before authentication checks. Password authentication is still required. The issue has been fixed in the specified later versions.
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.23, 4.1.14, 4.2.9, and 4.3.3, the optional rabbitmq_jms_topic_exchange plugin's x-jms-topic exchange accepted a client-controlled rjms_erlang_selector binding expression whose LIKE evaluator expanded percent and underscore wildcards into overlapping PCRE fragments. It executed those fragments with raw re:run/3 without match or recursion limits, allowing an authenticated tenant that can bind and publish to consume broker scheduler CPU and deny service with pathological selectors. This issue is fixed in versions 4.0.23, 4.1.14, 4.2.9, and 4.3.3.
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3, 4.2.9, 4.1.14, and 4.0.23, AMQP 1.0 management GET /bindings exposes full binding topology to any authenticated AMQP user without resource/management permission checks. the AMQP 1.0 HTTP-over-AMQP management endpoint GET /bindings (the rabbitamqpmanagement handler) enumerates bindings between an arbitrary source exchange and destination queue/exchange in the caller's virtual host without performing any resource-level permission check. Unlike every sibling operation in the same module (which call checkresourceaccess / bindingchecks), the GET handler ignores the authenticated User and returns the binding list unchanged. As a result, any authenticated AMQP 1.0 client that can open a management link pair , including users with no management/monitoring/policymaker/administrator tag , can enumerate the complete binding topology (source exchanges, destination queues/exchanges, routing keys, and binding arguments) of the virtual host they can access. The equivalent HTTP management API (GET /api/bindings) Confidentiality impact: a non-management AMQP 1.0 user can enumerate the complete routing topology of any virtual host it can connect to , every (source exchange, destination queue/exchange, routing key, binding arguments) This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.
CVE-2026-67415 is a medium severity vulnerability in rabbitmq-server versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2. It involves uncontrolled resource consumption due to the Shovel parameter parser converting attacker-controlled runtime parameters into non-garbage-collected Erlang atoms without proper bounds or allowlist checks. Exploitation requires network access to the Management HTTP API, valid credentials with management and policymaker tags, permission to set Shovel runtime parameters, and enabled shovel plugins. Successful exploitation can exhaust the node-wide atom table, causing denial of service. The issue is fixed in versions 4.2.9 and 4.3.3.
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.