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.