CVE-2026-67231 in RabbitMQ
Summary
by MITRE • 09/24/2026
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 verify_fun that overrides {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer} when the presented cert "matches" a whitelisted one. The match key is extract_issuer_id/1 → public_key:pkix_issuer_id/2 → {IssuerName, SerialNumber} , both fields are taken verbatim from the presented certificate body and contain no public-key, SKI, fingerprint or signature material. is_whitelisted/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 rabbitmq_trust_store plugin enabled and used as the TLS verify_fun 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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The RabbitMQ messaging broker contains a critical vulnerability within its trust-store plugin that allows for the bypass of TLS client authentication mechanisms. This flaw exists in versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. The vulnerability stems from an improper implementation of certificate validation logic where the trust-store plugin installs a custom verify_fun function that overrides standard TLS verification errors such as bad_cert_unknown_ca or bad_cert_selfsigned_peer under specific conditions. Specifically, if a presented certificate matches a whitelisted entry based on its issuer distinguished name and serial number, the system accepts it regardless of other cryptographic validity checks. This behavior fundamentally undermines the security model of mutual TLS authentication which relies on verifying that the client possesses the private key corresponding to the public key in the presented certificate.
The technical root cause lies in how the plugin determines whether a certificate is whitelisted. The matching process utilizes the extract_issuer_id function, which calls pkix_issuer_id to retrieve only the IssuerName and SerialNumber fields from the certificate body. These two attributes are extracted verbatim without any association with public key material, subject key identifiers, fingerprints, or signature data. Consequently, an attacker who knows or can guess these non-secret values for any whitelisted certificate can construct a forged self-signed certificate that will pass the whitelist check. The stored full DER-encoded representation of the whitelisted certificate is used solely for display purposes in list operations and is never compared against the presented certificate during authentication. Furthermore, the cacerts variable remains empty, meaning the whitelisted certificates are not utilized as trust anchors for path validation either. This design flaw ensures that cryptographic integrity checks are effectively bypassed when a match on issuer identity and serial number occurs.
The operational impact of this vulnerability is severe, allowing an unauthorized attacker to impersonate legitimate clients or services within the RabbitMQ cluster. By presenting a self-signed certificate with a matching Issuer DN and Serial Number, an adversary can establish authenticated connections without possessing the private key associated with any trusted authority. This bypass enables potential data exfiltration, injection of malicious messages into queues, denial of service through resource exhaustion via fake clients, or lateral movement within environments where RabbitMQ serves as a critical communication backbone. The attack requires minimal preconditions: the rabbitmq_trust_store plugin must be enabled and configured to use this verify_fun function, and the attacker must have access to at least one whitelisted certificate's issuer distinguished name and serial number, which are often exposed via command-line interfaces, logs, or general certificate repositories.
This vulnerability aligns with CWE-295 Improper Certificate Validation as it involves accepting a certificate that does not meet strict cryptographic validation requirements but passes based on insufficient identity attributes. It also maps to MITRE ATT&CK technique T1078 Valid Accounts because the attacker leverages valid-looking credentials derived from misconfigured trust policies rather than stealing actual secrets. To mitigate this risk, organizations must upgrade RabbitMQ to version 3.13.15 or later in the 3.13 series, or versions 4.0.20, 4.1.11, 4.2.6, and 4.3.0 depending on their deployment branch. Until an upgrade is performed, administrators should disable the rabbitmq_trust_store plugin if it is not strictly necessary for their security architecture. Additionally, reviewing TLS configurations to ensure that standard CA-based validation is enforced rather than relying solely on whitelisting mechanisms can reduce exposure. Regular audits of certificate inventories and limiting access to issuer details in logs will further minimize the attack surface available to potential adversaries seeking to exploit this logic flaw.