RabbitMQ September 2026 CVEs: Which Versions Are Fixed and Which Are Not

The short answer

Between 23 and 25 September 2026, NVD published 54 CVEs against the RabbitMQ server: 2 critical, 13 high, 30 medium and 9 low. On 16 and 17 September it had already published 13 against three RabbitMQ client libraries. The server advisories first appeared on the rabbitmq-server GitHub repository between 9 July and 18 August, so NVD was catching up, not breaking news.

Every one of these CVEs has a fix. What differs from line to line is whether you can download it:

• 4.3: every fix is in a public release, the last of them in 4.3.5. The current release is 4.3.6.
• 4.2: all but two are fixed in public releases up to 4.2.9. CVE-2026-67420 (CVSS 2.3) and CVE-2026-67421 (CVSS 4.5) are fixed only in 4.2.10, which is not a public release.
• 3.13, 4.0 and 4.1: no fix is public. The advisories name 3.13.15, 4.0.20 and 4.1.11 or later, while the last public releases on those lines are 3.13.7, 4.0.9 and 4.1.8. Later releases on those lines go only to Broadcom's commercial customers.

Both critical CVEs are TLS verification failures, and each needs a specific plugin in use. Before treating all 54 as one emergency, check which plugins your brokers run. The RabbitMQ end-of-life chart has the support dates for every line.

The two critical CVEs

CVE-2026-67404 (CVSS 9.2) is in the OAuth 2 plugin. When no cacertfile is configured and the operating system CA bundle is empty or unreadable, which happens in some minimal container images, the broker fetches signing keys from the identity provider's JWKS endpoint with verify_none and logs nothing. An attacker between the broker and that endpoint can serve keys of their own, and the broker then accepts tokens the attacker signed. It is fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0.

CVE-2026-67231 (CVSS 9.1) is in the trust store plugin. To decide whether a client certificate is whitelisted, the plugin compares only the issuer name and serial number taken from the certificate the client presents. Neither value is secret and no key or signature is compared, so anyone who knows the issuer and serial of one whitelisted certificate can pass client authentication with a self-signed forgery. The fixed versions match CVE-2026-67404.

If you do not use OAuth 2, or you set cacertfile explicitly, CVE-2026-67404 does not reach you. If rabbitmq_trust_store is not enabled, CVE-2026-67231 does not either. rabbitmq-plugins list -e shows what is enabled on a node.

The high-severity server CVEs

The tables give the fixed release on each line as the advisory states it. "Public" means the release is on the rabbitmq-server GitHub releases page; "commercial only" means it is not. A line missing from a row is one the advisory does not list, which is not a statement that the line is safe.

Authentication and TLS

Management UI and HTTP API

Protocol parsing and resource limits

CVE-2026-66079 needs the least from an attacker. Anyone who can reach port 5672 with AMQP 1.0 enabled, which the advisory notes is the default listener, can stop the node with one small frame before logging in. CVE-2026-67232 is similar but needs the Web MQTT plugin, which is off by default. Most of the rest need either an enabled plugin, a non-default setting such as a wildcard CORS origin, or an authenticated user.

The 39 medium and low CVEs

Most of the remainder are denial of service through atom table exhaustion, missing size limits or missing timeouts, and permission checks in the management API, Shovel, Federation and the stream plugins that are looser than intended. A few deserve a direct look:

• CVE-2026-67412 (6.0): a Federation upstream skips vhost authorization, so a policymaker on one vhost can read and drain messages from another. With the default ack mode the source messages are consumed, not copied.
• CVE-2026-67406 (4.6), CVE-2026-67221 (5.9) and CVE-2026-66068 (5.6): Shovel can write plaintext connection credentials to crash logs, expose them through GET /api/shovels for AMQP 1.0 shovels, or log them at debug level.
• CVE-2026-67242 (6.3): on 4.2 and 4.3 the OAuth 2 backend skips the expiry check when a token's exp claim is a float, so an expired token is accepted. The advisory notes that mainstream identity providers emit integers.

The same rule applies as above: on 3.13, 4.0 and 4.1 none of these has a public fix.

What it means for each version

3.13.7. Both critical CVEs and every other advisory that lists 3.13 are fixed only in 3.13.15 or later, which Broadcom supports commercially until 31 December 2029. The runtime is a second problem, covered below. See RabbitMQ 3.13 end of life.

4.0.9. The fixes are in 4.0.20 and later, and Broadcom's commercial support for 4.0 ended on 30 September 2026, so 4.0 no longer has a vendor patch stream of any kind. See RabbitMQ 4.0 end of life.

4.1.8. The fixes are in 4.1.11 and later, which are commercial; Broadcom lists commercial support for 4.1 until 30 April 2027. See RabbitMQ 4.1 end of life.

4.2.x. Upgrading to 4.2.9 closes everything except CVE-2026-67420, a low-rated issue where an OAuth credential refresh keeps a revoked impersonator tag on the connection, and CVE-2026-67421, a management UI injection that needs several conditions at once. Community support ended on 31 July 2026, so later advisories will not get a public 4.2 fix either.

4.3.x. Upgrade to 4.3.6. Community support for 4.3 ends on 30 November 2026, and GitHub shows no 4.4 release or pre-release yet.

The client libraries

Every client fix is public. Most of the amqp091-go issues need a malicious or compromised broker on the other end, so they matter most where applications connect to brokers you do not run or across networks you do not trust. CVE-2026-77405 is different: the client set no minimum TLS version, so a build on a Go runtime that still allows TLS 1.0 or 1.1 could negotiate them over amqps. CVE-2026-77408 and CVE-2026-77407 are about what the application passes in or leaves in memory, not about the broker. Each project has shipped later releases since, some with further advisories: amqp091-go is at 1.15.0, the Java client at 5.37.0 and rabbitmq-c at 0.18.0. Take the latest.

The Erlang/OTP layer under 3.13

On 3.13, a broker fix is half the job. RabbitMQ's compatibility matrix limits 3.13.0 to 3.13.7 to Erlang/OTP 26.0 through 26.2.x, and Broadcom's knowledge base article 450171 shows Erlang 27 support starting at 3.13.8, a commercial release. OTP 26 reached end of life on 26 May 2026; see the Erlang/OTP end-of-life chart. On 22 September the Erlang/OTP team published CVE-2026-89422 (CVSS 9.3), a TLS 1.3 client flaw that lets whoever answers a connection pose as the intended server, and fixed it in OTP 27.3.4.18, 28.5.0.7 and 29.1.1 only. RabbitMQ is a TLS client for Shovel and Federation links, LDAP and OAuth 2 key fetches, so community 3.13 has no public fix in either layer. Our CVE-2026-89422 guide covers what is exposed and the workaround, and the Erlang/OTP support page covers patched runtimes. RabbitMQ 4.0.4 and later run on Erlang 27, which has the fix.

Your options

• Upgrade to 4.3.6. It is the only line where every fix is public, and its community support ends on 30 November 2026. From 3.13, the move to 4.x starts with migrating classic mirrored queues to quorum queues, because 4.0 removed mirroring.
• Broadcom commercial releases. Tanzu RabbitMQ customers receive the 3.13, 4.1 and 4.2 releases that carry these fixes. Commercial support runs to 31 December 2029 for 3.13, 30 April 2027 for 4.1 and 30 June 2030 for 4.2; for 4.0 it ended on 30 September 2026.
• OSSeva patched builds. OSSeva ships signed RabbitMQ builds for 3.13, 4.0, 4.1 and 4.2 with these fixes backported, plus a patched Erlang/OTP 26 runtime for 3.13, delivered through your own repository manager. Patch covers the builds. Assure adds a VEX statement for each CVE, which settles scanner findings for plugins you do not run. Operate adds 24/7 operation of the clusters.

See RabbitMQ 3.x extended support for how the 3.13 builds and the quorum queue migration work, and the RabbitMQ support page for the 4.x lines.