RabbitMQ CVE Lookup by Version: Enter Your Version, See Which Vulnerabilities Apply

Enter the version a node reports and the table shows every advisory whose affected range includes it. This page is the version lookup. For the full register with every advisory's background, read the RabbitMQ CVE register, and for deciding how fast to patch, read what actually needs patching. The example below is 4.3.6, the newest 4.3 patch on rabbitmq.com's release page. Support dates checked against rabbitmq.com on 29 October 2026.

Every 4.x series still in support carries dozens of advisories, and on four of them the newest public release is still exposed. One advisory usually lists several series at once, so the rows overlap and do not add up to the total. The last column is the newest non-preview release of that series on GitHub and how many broker advisories still list it.

Two readings matter. First, on 4.2, 4.1, 4.0 and 3.13 the fixes past the newest public release went to commercial support customers only, which is how rabbitmq.com/security labels them ("Enterprise Support Only"). Second, the low counts on 3.12 and older do not mean those series are safer: recent advisories list only the series the RabbitMQ team still assessed, so a 3.12 node is simply not checked against them.

Read the result as a list of advisories whose published range includes your exact version, then act on the fixed-in column. Four details change what you do next.

• Use the full patch version. Ranges are written per patch, for example >= 4.2.0, < 4.2.12, so 4.2.5 and 4.2.11 get different answers. Run rabbitmq-diagnostics server_version on every node, because a cluster mid-upgrade runs two versions.
• Fixed in is the floor for that advisory, not the target. The highest fixed-in version clears everything listed for you. Moving to an intermediate patch can land you inside a different advisory's range.
• "Commercial support only" means no public build exists. The fix shipped after the series left community support, so it is not in a public GitHub release. You get it through a commercial RabbitMQ licence, or by moving to a series that still gets public releases.
• Zero results on an old series means not assessed. If the series is past its commercial support date, advisories no longer list it, so a clean result there is not a clean bill of health.

An advisory can apply to your version and still not apply to your deployment: many need a specific plugin, protocol listener or OAuth 2 setup to be reachable. Check the advisory text before scheduling an emergency window.

Once the lookup shows which advisories list your version, work through them in this order.

1. Update target. Take the highest fixed-in version across your results as the target, and check that it is a public release or that your commercial support covers it.
2. Severity. Each advisory carries a severity label (Critical, High, Medium or Low) and, where the advisory includes one, a CVSS score on the advisory itself. The label describes the flaw in general, not the risk to your deployment.
3. Reachability. Ask whether an attacker could reach the affected component from where they sit: a management listener, a protocol plugin or an OAuth 2 setup you do not run is no attack surface for you.
4. Client applications. The Java client is a library inside your applications, so a client advisory is fixed by rebuilding those applications on the fixed client version, not by updating the broker.
5. Evidence. If an audit or compliance review needs a record, keep the lookup result with the date and the exact version it was run against.

A scanner and this lookup answer different questions, so scan results and lookup results rarely match line for line. A container image or host scanner compares package names and versions with a vulnerability database and reports everything it finds in the image, including the operating system, the Erlang runtime and libraries. The lookup compares your RabbitMQ version with the affected ranges in RabbitMQ's own published advisories and covers only the broker and the Java client.

Two differences matter. Many advisories on rabbitmq.com/security are listed as "CVE ID pending", so a scanner that matches on CVE identifiers may not report them yet, while the lookup matches on the advisory's version range. And a scanner reports a flaw in a component your configuration may never load, which is the reachability question above. Run the scan on the whole image, then use the lookup to verify the RabbitMQ-specific advisories against the exact version on each RabbitMQ node.

If you find a vulnerability rather than look one up, rabbitmq.com/security asks you to use the "Report a vulnerability" option under the Security tab of the relevant GitHub repository, for example rabbitmq/rabbitmq-server, and gives a fallback email address for a user who cannot use GitHub. It asks that you do not report security vulnerabilities through public GitHub issues, public mailing lists or public Discord channels. Private disclosure gives the maintainers time to publish a fix before details are public.

The lookup covers the published GitHub advisories for the broker and the Java client, and nothing else. Check these separately.

• Erlang/OTP. RabbitMQ runs on Erlang, and runtime CVEs are not listed in the broker's advisories. Check your Erlang version against the Erlang/OTP security notices and RabbitMQ's supported Erlang range.
• Dependencies and the Tanzu distribution. rabbitmq.com/security says the Broadcom Support Portal is the authoritative source for commercial releases, including CVEs in dependencies and the Erlang runtime that the public table does not list.
• Other clients and the operator. Only rabbitmq-java-client is included. The AMQP 1.0 clients, the Kubernetes cluster operator and community plugins have their own repositories and advisories.
• Anything published after the snapshot date. The public advisories page on rabbitmq.com is authoritative; where it and this lookup disagree, it wins.

The snapshot is refreshed by re-running AceMQ's script against the GitHub advisory API.

If the fix is commercial support only, or your series is no longer assessed, you have three routes: take a commercial licence for a series it still covers, upgrade to a series with public releases, or keep your version and get the fix backported. Commercial RabbitMQ licensing reaches back to 3.13.x. AceMQ extended support reaches back to 3.8.x: we match each new advisory against the exact build you run, backport the fix where it applies, and give you a signed non-applicability statement where it does not.

A health check is the quickest way to get a dated list of which advisories apply to each of your clusters, given the plugins and listeners you actually run.