Source: rabbitmq-server X-Debbugs-CC: [email protected] Severity: grave Tags: security
Hi, The following vulnerabilities were published for rabbitmq-server. CVE-2026-61837[0]: | 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. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-w9hf-476r-443x CVE-2026-67223[1]: | RabbitMQ is a messaging and streaming broker. The advisory | establishes affected 3.13, 4.0, 4.1, 4.2, and 4.3 maintenance lines | but contains conflicting first-fixed versions for the 3.13, 4.0, and | 4.1 lines. fill/2 substitutes ${username} into user_dn_pattern | without RFC 4514 DN escaping, allowing a crafted username to alter | the LDAP bind DN and potentially select a different directory entry. | Exploitation requires rabbitmq_auth_backend_ldap with a | user_dn_pattern containing ${username}, a directory layout in which | the injected suffix resolves usefully, and a password valid for the | resulting DN. The advisory body identifies 3.13.15, 4.0.20, 4.1.11, | 4.2.9, and 4.3.3 as fixed, while structured metadata identifies | 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. No fixed-version | assertion is certifiable until a curator resolves this conflict. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-9x7r-g78c-5835 CVE-2026-67239[2]: | RabbitMQ is a messaging and streaming broker. From 3.13.0 until | 3.13.18 and 4.0.23 and 4.1.14 and 4.2.9 and 4.3.3, Stored XSS via | TLS peer-certificate DN in stream-management UI (sibling of V-11). | lines 102/106/110 render peercertsubject / peercertissuer with raw | <%= %> and no fmtstring(). RFC4514 backslash-escaping of </> is | HTML-inert and bypassable (<img ... //>). Requires non-default | config: a stream TLS listener with verifypeer and an attacker- | obtainable trusted cert with a malicious Same as the connection.ejs | finding, against operators viewing the stream-connection detail | rabbitmqstream + rabbitmqstreammanagement enabled with a TLS | listener using verifypeer Attacker can obtain a certificate signed | by a CA the listener trusts, with attacker-chosen DN An operator | views the. This issue is fixed in versions 3.13.18 and 4.0.23 and | 4.1.14 and 4.2.9 and 4.3.3. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-xm9p-57xv-vxwc CVE-2026-67241[3]: | 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. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-rg2g-289m-xhhw CVE-2026-67242[4]: | RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 | and 4.3.3, OAuth2 isinteger(Exp) guard skips token-expiry checks for | float exp. validatetokenexpiry/1 (lines 208-214) and | expirytimestamp/1 (138-144) both guard with 'when isinteger(Exp)' | and fall through to ok/never for float values. josejwt:verify | validates only the signature, not exp. With float exp, no expiry | validation occurs anywhere in the If the IdP emits exp as a JSON | float (RFC 7519 permits fractional NumericDate), both the login-time | expiry check and the mid-connection disconnect timer are silently | skipped , an already-expired token is accepted, and connections | never time OAuth2 backend enabled IdP emits float exp (uncommon; | mainstream IdPs emit integers) Attacker possesses a previously-valid | signed. This issue is fixed in versions 4.2.9 and 4.3.3. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-rrj4-g94f-rqj9 CVE-2026-67406[5]: | 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, Shovel does not format state | logged by the crash reporter and can leave unencrypted credentials | in a crash dump file. the shovel worker genserver processes does not | implement the formatstatus/2 callback. When these processes crash | (e.g., due to network partitions, connection failures), the OTP SASL | error handler writes the full process state , including plaintext | AMQP passwords and URIs , to the error log. This is particularly | severe for the shovel worker, which stores deobfuscated plaintext | URIs (including amqp://user:password@host format) in its genserver | state for the entire process Automatic Credential Exposure: Shovel | worker crashes (common during network partitions) automatically | write plaintext upstream/downstream passwords to error logs No | Special Configuration Needed: Unlike DEBUG logging, SASL error | reports are always active Broad. This issue is fixed in versions | 4.3.3, 4.2.9, 4.1.14, and 4.0.23. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q44f-9vc5-grh7 CVE-2026-67407[6]: | RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3 | and 4.2.9 and 4.1.14 and 4.0.23, Incomplete fix for CVE-2026-44838: | escaperegexchar/1 does not escape -, leaving room for an MQTT topic | permission bypass. the CVE-2026-44838 fix made | expandtopicpermission/2 escape regex metacharacters in expanded | topic-permission variables (escaperegex(V)), but escaperegexchar/1 | escapes \ ^ $ . | ? + ( ) [ ] { } and omits -. When a topic | permission template places {clientid} inside a [...] character class | A low-privileged authenticated MQTT user controlling its clientid | can broaden topic authorization (read and write) when templates | embed {clientid} in a [...] This issue is fixed in versions 4.3.3 | and 4.2.9 and 4.1.14 and 4.0.23. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q46v-hrvq-hp24 CVE-2026-67408[7]: | RabbitMQ is a messaging and streaming broker. From 4.1.0 until | 4.3.3, 4.2.9, and 4.1.11, Stream Management Super-Stream Binding | Keys Allocation Allows Low-Privilege Node Denial of Service. | rabbitMQ 4.3.1 with rabbitmqstreammanagement enabled accepts PUT | /api/stream/super-streams/{vhost}/{name} requests from an | authenticated management user that can access the target vhost. When | the request body contains the binding-keys field, the handler parses | the attacker-controlled comma-separated string and builds the full | stream-name list before checking whether the user has permission to | configure the resulting streams. A low-privileged management user | with vhost access but no configure, write, or read permission can | therefore force large transient allocations before the resource | permission check. In a 768 MB memory-limited container, one HTTP PUT | with about 4.5 MB of JSON body killed the RabbitMQ container with | Docker state exited true An authenticated low-privileged management | user can kill a memory-limited RabbitMQ node with one HTTP This | issue is fixed in versions 4.3.3, 4.2.9, and 4.1.11. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-2hm4-4438-49q8 CVE-2026-67409[8]: | RabbitMQ is a messaging and streaming broker. From 3.13.0 until | 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP | Response Status Code - Signing Key Destruction Causes Authentication | DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does | not validate the HTTP response status code when downloading signing | keys from the OAuth2 provider's JWKS endpoint. Non-200 responses | (including 4xx and 5xx errors) are processed identically to | successful responses. When the JWKS endpoint returns an error | response with a valid-JSON body that lacks a keys field, all | previously cached signing keys are destroyed, causing a persistent | authentication denial of Files: | deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 | deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 | deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines | 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The | Erlang httpc module returns {ok, {{HttpVersion, StatusCode, | ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} | matches ANY successful HTTP transaction Persistent authentication | DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails | for all users until a new successful JWKS refresh occurs | Amplification: A single attacker can deny access to all legitimate | OAuth2 users across the entire RabbitMQ. This issue is fixed in | versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-qw3h-qqm9-jrw8 CVE-2026-67410[9]: | RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.3.3 | and 4.2.9, OAuth2 Client Secret Exposed via Unauthenticated | JavaScript Endpoint (CWE-200). when OAuth2 authentication is enabled | for the RabbitMQ Management UI and the configured flow, IDP use a | client secret, the oauthclientsecret configuration value is included | in the JavaScript served by the unauthenticated endpoint /js/oidc- | oauth/bootstrap.js. Any user who can reach the management UI port | can retrieve the OAuth2 client secret without Files: | deps/rabbitmqmanagement/src/rabbitmgmtwmauth.erl, line 186 | deps/rabbitmqmanagement/src/rabbitmgmtoauthbootstrap.erl, lines | 35-50 deps/rabbitmqmanagement/src/rabbitmgmtdispatcher.erl, lines | 45-49 (route registration) Code Path: 1. The route /js/oidc- | oauth/bootstrap.js is registered as a plain Cowboy handler | (rabbitmgmtdispatcher.erl:46): Credential exposure for the affected | configuration: OAuth2 client secret is accessible without any | authentication Token theft: Attacker can complete the authorization | code flow using stolen authorization codes Client impersonation: | Attacker can make requests. Any RabbitMQ deployment with: This issue | is fixed in versions 4.3.3 and 4.2.9. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-f9f2-q3jf-wfj3 CVE-2026-67411[10]: | RabbitMQ is a messaging and streaming broker. From 3.13.0 until | 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3, native MQTT and MQTT over | WebSocket behind a trusted PROXY Protocol frontend could lose the | proxy-derived client address before the MQTT authentication path | checked loopback_users, causing the frontend-to-broker address to be | treated as loopback. An attacker who can reach the trusted frontend | and has valid credentials for a loopback-restricted account can | therefore bypass the source-address restriction; the issue does not | bypass password authentication. This issue is fixed in versions | 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-4r6f-9cpw-f6g6 CVE-2026-67412[11]: | 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. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-42pc-678q-v8qj CVE-2026-67413[12]: | 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. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-chxf-3hfg-j8f7 CVE-2026-67415[13]: | RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 | and 4.3.3, the Shovel parameter parser converted attacker-controlled | runtime parameter values into non-garbage-collected Erlang atoms | before bounding them or checking a fixed allowlist. Exploitation | requires network access to the Management HTTP API, valid | credentials with both the management and policymaker tags, | permission to set Shovel runtime parameters on a vhost, and the | rabbitmq_shovel and rabbitmq_shovel_management plugins to be | enabled. The attacker can exhaust the node-wide atom table and deny | service, and malicious parameters are stored durably and reparsed | when workers start, so atom pressure can recur after restart without | a live attacker connection. This issue is fixed in versions 4.2.9 | and 4.3.3. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-8mpg-qw9r-m5cr CVE-2026-67419[14]: | RabbitMQ is a messaging and streaming broker. Prior to 4.3.5, an | authenticated user who can bind a queue to a topic exchange and | publish to it can use consecutive # segments in a binding key to | make both topic matchers revisit the same trie-node and routing-key- | suffix states without memoization. The matcher materializes | duplicate destinations before deduplication, causing combinatorial | CPU work and memory pressure that can disrupt routing for all | tenants. This vulnerability is fixed in 4.3.5. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-h964-v5mf-22cq CVE-2026-67420[15]: | RabbitMQ is a messaging and streaming broker. From 3.13.0 until | 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ OAuth | credential refresh retains revoked runtime tags. when an existing | AMQP connection refreshes from an OAuth token that grants the | impersonator tag to a valid same-username token that no longer | grants that tag, RabbitMQ updates the OAuth backend implementation | (token/scopes/expiry) but leaves the connection's runtime #user.tags | unchanged. rabbitaccesscontrol:checkuserid/2 then still honors the | stale impersonator tag, so the connection (including newly opened | channels) can continue publishing messages with a foreign AMQP | userid after that privilege should have been revoked. A fresh | connection using the downgraded token correctly refuses the same | publish, proving the defect is stale session state rather than the | token Limited to connections that once held impersonator and | successfully refresh to a downgraded same-username | rabbitauthbackendoauth2 (or an equivalent refresh-capable backend | that returns tags) is enabled for This issue is fixed in versions | 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-86fm-44m9-rqjx CVE-2026-67421[16]: | RabbitMQ is a messaging and streaming broker. From 3.13.0 until | 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ Management | rendered an AMQP authorization-error reason containing an attacker- | controlled queue name as HTML when the OAuth management UI was | enabled. Exploitation requires an attacker with queue configure | permission, a management administrator who can see but cannot read | that queue, and the administrator clicking Get Message(s). A queue | name containing a base element can then retarget the automatic | relative refresh because the Content Security Policy omits base-uri | and connect-src, and an attacker endpoint that permits the | management origin through CORS can receive the victim's | Authorization header. This issue is fixed in versions 3.13.19, | 4.0.24, 4.1.15, 4.2.10, and 4.3.5. https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-6256-27fm-4rgr If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-61837 https://www.cve.org/CVERecord?id=CVE-2026-61837 [1] https://security-tracker.debian.org/tracker/CVE-2026-67223 https://www.cve.org/CVERecord?id=CVE-2026-67223 [2] https://security-tracker.debian.org/tracker/CVE-2026-67239 https://www.cve.org/CVERecord?id=CVE-2026-67239 [3] https://security-tracker.debian.org/tracker/CVE-2026-67241 https://www.cve.org/CVERecord?id=CVE-2026-67241 [4] https://security-tracker.debian.org/tracker/CVE-2026-67242 https://www.cve.org/CVERecord?id=CVE-2026-67242 [5] https://security-tracker.debian.org/tracker/CVE-2026-67406 https://www.cve.org/CVERecord?id=CVE-2026-67406 [6] https://security-tracker.debian.org/tracker/CVE-2026-67407 https://www.cve.org/CVERecord?id=CVE-2026-67407 [7] https://security-tracker.debian.org/tracker/CVE-2026-67408 https://www.cve.org/CVERecord?id=CVE-2026-67408 [8] https://security-tracker.debian.org/tracker/CVE-2026-67409 https://www.cve.org/CVERecord?id=CVE-2026-67409 [9] https://security-tracker.debian.org/tracker/CVE-2026-67410 https://www.cve.org/CVERecord?id=CVE-2026-67410 [10] https://security-tracker.debian.org/tracker/CVE-2026-67411 https://www.cve.org/CVERecord?id=CVE-2026-67411 [11] https://security-tracker.debian.org/tracker/CVE-2026-67412 https://www.cve.org/CVERecord?id=CVE-2026-67412 [12] https://security-tracker.debian.org/tracker/CVE-2026-67413 https://www.cve.org/CVERecord?id=CVE-2026-67413 [13] https://security-tracker.debian.org/tracker/CVE-2026-67415 https://www.cve.org/CVERecord?id=CVE-2026-67415 [14] https://security-tracker.debian.org/tracker/CVE-2026-67419 https://www.cve.org/CVERecord?id=CVE-2026-67419 [15] https://security-tracker.debian.org/tracker/CVE-2026-67420 https://www.cve.org/CVERecord?id=CVE-2026-67420 [16] https://security-tracker.debian.org/tracker/CVE-2026-67421 https://www.cve.org/CVERecord?id=CVE-2026-67421 Please adjust the affected versions in the BTS as needed.
