CVE-2026-67231: RabbitMQ: Trust-store whitelist by Issuer+Serial only
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 verifyfun that overrides {badcert, unknownca} / {badcert, selfsignedpeer} when the presented cert "matches" a whitelisted one. The match key is extractissuerid/1 → publickey:pkixissuerid/2 → {IssuerName, SerialNumber} , both fields are taken verbatim from the presented certificate body and contain no public-key, SKI, fingerprint or signature material. iswhitelisted/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 rabbitmqtruststore plugin enabled and used as the TLS verifyfun 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.0
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
Only deployments that enable the rabbitmq_trust_store plugin and use it as the TLS verify_fun are affected. The issue applies to TLS client authentication; the plugin's whitelist does not validate the presented certificate's public key, signature, fingerprint, or trust chain.
What does an attacker need to bypass client authentication?
An attacker needs the issuer distinguished name and serial number of any whitelisted certificate. These values are non-secret and may be available from the CLI, logs, a copy of the certificate, or by guessing them; the attacker can then present a forged self-signed certificate with matching values.
Are whitelisted certificates used as normal certificate authorities for path validation?
No. The trust-store configuration uses an empty cacerts list, so whitelisted certificates are not used as trust anchors for certificate-path validation. Whitelist matching is only an ETS lookup of the presented certificate's issuer and serial number.
Which versions contain the fix?
The issue is fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. Deployments on earlier versions should treat trust-store-based TLS client authentication as bypassable when the stated preconditions are present.