Message brokers are the kind of infrastructure that holds a lot of trust without attracting a lot of attention. RabbitMQ in particular sits between microservices, queues credentials, payloads, and operational state, and is often deployed once and forgotten about while application teams iterate around it. The 2024 and 2025 RabbitMQ security advisory stream, with findings ranging from authentication weaknesses in the management plugin through Erlang cookie handling to plugin loading paths that trust the local filesystem more than they should, is a useful prompt to look at brokers with the same SBOM rigor applied to databases.
The advisories that matter most for supply chain practitioners involve the management plugin, which exposes a web UI and HTTP API on TCP/15672, and the Erlang distribution mechanism that nodes use to cluster. The management plugin authentication path has been a recurring source of CVEs because it has to bridge between RabbitMQ's internal authentication backends, HTTP basic auth, and various OAuth and OIDC integrations, and the bridging code has historically been where the bugs live. The Erlang distribution mechanism uses a shared cookie file as a primary trust anchor, and the operational security of that cookie has been a recurring source of incidents that may or may not get CVE numbers.
What does the recent RabbitMQ advisory pattern look like?
The 2024 and 2025 advisories include authentication bypass conditions in specific management plugin endpoints, information disclosure through error messages that leaked configuration state, denial of service through malformed AMQP frames, and a series of fixes around how the broker handles plugin loading from the plugins directory. The patches landed across the 3.12, 3.13, and 4.0 release lines, with the upstream maintaining a steady cadence of monthly point releases that bundle security fixes with feature work. The supported release matrix narrowed through 2025 as the project moved toward Erlang/OTP 26 and 27 baselines, which means clusters still on older Erlang runtimes have fallen off the security support window even when their RabbitMQ version technically receives backports.
The pattern that stands out is not the severity of any single CVE, most of which require either prior authentication or local access, but the combination with the broker's privileged position. A management plugin information disclosure that leaks a configured federation upstream's credential is, in isolation, a moderate severity finding; in the context of a broker that federates with a partner organization's broker, it is a path to that partner's queues and the credentials that flow through them. The CVSS score does not capture that, and that is the gap the supply chain perspective fills.
Why does the management plugin keep producing CVEs?
The management plugin is a Cowboy HTTP application running inside the Erlang VM, handling JSON over HTTP, with authentication backends that include internal users, LDAP, OAuth 2.0, and various custom plugins. Each authentication backend has its own code path, the backends interact through Erlang message passing, and the surface area for subtle bugs is large. The Cowboy HTTP layer has been hardened over the years, but each new backend integration introduces a new boundary where assumptions about authentication state can be violated.
The configuration permissiveness is another factor. The management plugin can be configured to allow anonymous access for specific operations, to expose Prometheus metrics without authentication, and to bind to interfaces that include public networks if the operator does not constrain it. Default configurations have tightened over time, but the long tail of clusters that were set up years ago retains permissive defaults that the operator never revisited. The combination of broad attack surface, sensitive operations, and configuration drift produces a steady stream of CVEs whose individual severity is moderate but whose aggregate risk is substantial.
What does the Erlang cookie problem look like in practice?
RabbitMQ nodes authenticate to each other in a cluster using a shared Erlang cookie, a file on disk whose contents form a symmetric secret. The cookie is also the credential used by command-line tools like rabbitmqctl to talk to a local node. If an attacker can read the cookie, they can pretend to be a peer node and access everything the cluster trusts, which is essentially all the broker's queues, exchanges, and configuration. The cookie's file system permissions are therefore load-bearing, and the operational discipline of keeping those permissions tight is uneven across deployments.
The supply chain dimension of the cookie problem is in container images and configuration management. A container image that bakes in a known cookie value, a Helm chart that uses a hard-coded default, or a configuration management module that uses an organizationally-shared cookie all turn the per-cluster secret into a class secret that is shared across deployments. An attacker who learns the cookie from one cluster can move to another with the same cookie, which is how a compromise of a development cluster reaches production. The hardening pattern is to generate a fresh, high-entropy cookie per cluster and store it in a secrets manager, not in source control or a config map.
Why should brokers get database-grade SBOM treatment?
Operators inventory databases carefully because the data is the asset. They track database versions, patch them on a known cadence, audit access patterns, and apply network segmentation and encryption defaults. Message brokers hold a comparable concentration of trust because the broker mediates the data flow between services, holds the credentials services use to publish and consume, and often persists messages for some retention window. The risk profile is comparable, but the inventory and patch discipline historically is not.
The SBOM picture for RabbitMQ is also more interesting than operators sometimes appreciate. The broker is Erlang/OTP, which has its own supply chain with its own CVE stream, and the plugins it loads are themselves software with their own dependencies. A complete SBOM lists the Erlang/OTP version, the RabbitMQ version, the enabled plugins with their versions, and any custom plugins the operator has added. The version of Erlang/OTP matters because some RabbitMQ CVEs are fixed only on certain Erlang baselines, and the plugin inventory matters because the plugin loading path has historically been a source of findings that depend on which plugins are present.
How Safeguard Helps
Safeguard inventories RabbitMQ deployments by version, Erlang/OTP baseline, and enabled plugin set across container images and ingested cluster SBOMs, so the question of which advisory applies to which broker can be answered against live data rather than tribal knowledge. Griffin AI correlates the inventory with the 2024 and 2025 RabbitMQ advisory feed and ranks affected brokers by exposure of the management plugin to untrusted networks, by federation and shovel relationships that widen the blast radius, and by whether the Erlang cookie is sourced from secrets management rather than baked into the image. Policy gates can block deployment of container images that ship pre-supported RabbitMQ versions or that include hard-coded cookie values, and the TPRM workflow surfaces upstream vendors whose messaging products embed unpatched brokers. The reachability analysis identifies which plugins are actually enabled in a given deployment, so a CVE in a specific plugin raises priority only on brokers where that plugin is loaded.