External risk intelligence

RabbitMQ Trust-Store Plugin TLS Client-Authentication Bypass

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-67231

RabbitMQ is a messaging broker typically deployed in internal backend infrastructure to facilitate communication between services. While it can be exposed to the internet in specific architectural patterns, it is not commonly deployed as a public-facing edge service by design, making internet reachability possible but not the default or standard deployment pattern.

Authentication Bypass

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a security vulnerability in RabbitMQ, a messaging and streaming broker. The issue, found in the trust-store plugin, could allow an attacker to bypass TLS client authentication by using a forged certificate if specific conditions are met. This could potentially enable unauthorized access to systems relying on this authentication method.

Unauthorized access to messaging systems.
Understand RabbitMQ's role in your infrastructure.
Confirm if RabbitMQ is used and assess exposure.

Attack Path

How an attacker could exploit the issue

An attacker who knows the issuer and serial number of a whitelisted certificate can bypass TLS client authentication. This is possible when the RabbitMQ trust-store plugin is enabled and configured to use a specific verification function. An attacker can then connect to the broker using a forged self-signed certificate that matches the known issuer and serial number, potentially leading to unauthorized access.

Vulnerability requires trust-store plugin enabled.
Attacker uses forged cert with known issuer/serial.
Bypasses TLS authentication for unauthorized access.

Live Threat

Current exploitation, exposure, and threat context

When the RabbitMQ trust-store plugin is enabled and configured as the TLS verify function, an attacker who knows the issuer name and serial number of a whitelisted certificate could connect to the broker using a forged self-signed certificate. This bypasses TLS client authentication under specific conditions.

Server authentication.
TLS client authentication bypass.
Unauthorized broker access.

Operational Fix

Recommended remediation, mitigation, and detection steps

Teams responsible for RabbitMQ deployments, likely platform or infrastructure teams, must first identify all instances of the affected trust-store plugin. Confirming network reachability and business criticality will inform prioritization for remediation, which may involve coordination with application owners and potentially vendor engagement if RabbitMQ is managed as a service.

Platform/Infrastructure teams own this issue.
Verify plugin usage and network exposure.
Plan upgrade during maintenance window.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is RabbitMQ?

RabbitMQ is an open-source message broker software that acts as a middleware for applications. It allows different software systems to communicate by queuing and routing messages, ensuring that data is reliably transmitted between services in complex, distributed architectures.

What is the vulnerability in CVE-2026-67231?

This vulnerability is an authentication bypass identified as CWE-295: Improper Certificate Validation. It occurs because the RabbitMQ trust-store plugin checks only the issuer name and serial number of a presented certificate rather than verifying the cryptographic signature or public key. This allows an attacker to gain unauthorized access by presenting a forged certificate that simply mirrors those two non-secret identity fields.

How can an attacker trigger this CVE-2026-67231 bug?

An attacker needs to be able to connect to the RabbitMQ instance where the trust-store plugin is active and configured as the TLS verification function. The vulnerability is not triggered if the trust-store plugin is disabled, nor does it occur if the system relies on standard TLS validation methods instead of this specific plugin. The attacker must also successfully identify the issuer name and serial number of a certificate already present in the broker's whitelist.

Is my RabbitMQ instance at risk?

Risk depends on your specific architecture. According to Halo Surface Signal, RabbitMQ is typically used in internal backend infrastructure and is not inherently designed to be an edge service. However, it can be reached via the network in certain setups. If your instance is internet-facing or reachable by untrusted parties, the likelihood of an attacker identifying whitelisted certificate details and successfully exploiting this bypass increases.

How do I address CVE-2026-67231?

First, audit your RabbitMQ deployments to determine if the trust-store plugin is enabled. If it is, verify your current version against the patched releases—specifically 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0. Prioritize patching in environments where the broker is network-accessible. Coordinate with your application teams to schedule an upgrade, as this will resolve the flawed verification logic in the plugin.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.