RabbitMQ on an End-of-Life Version: Upgrade, Patch or Migrate

This post is about the decision once a broker is past end of life. For the dates of every release line, see the RabbitMQ end-of-life chart.

Where RabbitMQ support stands in October 2026

The RabbitMQ team gives community support to one line at a time. As of 4 October 2026, according to the release information page on rabbitmq.com:

• RabbitMQ 3.8 to 3.13: past community support. For 3.13 it ended on 30 September 2024.
• RabbitMQ 4.0: community support ended 30 April 2025, and commercial support ended 30 September 2026.
• RabbitMQ 4.1 and 4.2: community support ended 31 January 2026 and 31 July 2026.
• RabbitMQ 4.3: the only line with community support, which ends 31 January 2027.

Community security fixes go to the current line only. When a vulnerability is fixed in 4.3, there is no open source release of that fix for 3.x or for the older 4.x lines.

What Does This Mean Practically?

Consider CVE-2023-46604, the unauthenticated remote code execution flaw in the Apache ActiveMQ OpenWire protocol marshaller. It was disclosed on 27 October 2023, and ransomware operators were exploiting it in the wild within days. The fix shipped in the then-current releases; anything on an older 5.x line had no upstream path at all.

That is the shape of the problem. The advisory is public, so the affected versions and the exploitation route are public with it. An organisation that cannot absorb a version jump inside an exploitation window is not weighing an upgrade against a patch. It is running a known-exploitable service. This is precisely the exposure profile that PCI DSS Requirement 6.3.3 and SOC 2 CC7 are designed to address.

Why Are So Many Enterprises Still Running RabbitMQ 3.x?

The RabbitMQ 3.x to 4.x migration is non-trivial for production environments. Key changes in RabbitMQ 4.0 include:

• Classic queue mirroring is removed; replicated queues must become quorum queues or streams
• Changes to consumer acknowledgment behavior under certain edge conditions
• Minimum Erlang/OTP version requirement increase to 26.x
• Updated management API paths for some endpoints

For an enterprise running hundreds of vhosts, dozens of custom exchanges and queue topologies, and applications built against the 3.x behavior contract, this migration takes time to test and execute safely. Scheduling "migrate RabbitMQ" into a Q3 roadmap is easier said than done when the platform handles order processing, payment events, or clinical messaging.

What About Broadcom Tanzu RabbitMQ?

Many enterprises are in the additional bind of having commercial Broadcom Tanzu RabbitMQ support either expiring or repriced. Broadcom's acquisition of VMware restructured the Tanzu portfolio around per-core licensing with a minimum commitment, which means the invoice tracks cluster size rather than the support actually consumed, for what is functionally the same codebase as community RabbitMQ. We do not publish other vendors' pricing; compare your renewal quote against a per-cluster model directly.

Teams leaving Tanzu need somewhere to go for CVE coverage and compliance documentation during the migration period. That's precisely what extended lifecycle support addresses.

Your Options for EOL RabbitMQ

Migrate to RabbitMQ 4.x

The permanent solution. OSSeva recommends planning RabbitMQ 4.x migration for all customers; the question is timeline. A well-planned migration typically takes 3–6 months for straightforward deployments and 6–12 months for complex multi-vhost, multi-application environments. The migration requires: queue topology audit, quorum queue migration planning, client library updates, integration testing, and a staged production rollout.

Extended lifecycle support while migrating

OSSeva delivers backported CVE patches for RabbitMQ 3.8 through 4.2. Patches are delivered as signed Docker images, Helm chart updates, and direct binary tarballs. Each release includes a CVE attestation letter for compliance documentation. This keeps your security posture active and your auditors satisfied while you execute the 4.x migration at a controlled pace.

Exit Broadcom Tanzu to OSSeva-supported OSS RabbitMQ

For teams paying Tanzu pricing, OSSeva provides a migration toolkit that exports your existing vhost, exchange, queue, binding, and policy definitions and redeploys them on an OSSeva-supported OSS RabbitMQ cluster.

Erlang/OTP Compatibility

RabbitMQ 3.11–3.13 support Erlang/OTP 25.x and 26.x. OSSeva patches also cover the Erlang runtime itself for CVEs affecting the Erlang version bundled with or required by supported RabbitMQ builds. Erlang/OTP CVEs are less frequent but can affect RabbitMQ's TLS implementation, the BEAM scheduler, and the distribution protocol.

Compliance Considerations

For enterprises in financial services, healthcare, or government, the compliance exposure from unpatched EOL RabbitMQ is direct. PCI DSS v4.0 Requirement 6.3.3 requires all system components to be protected against known vulnerabilities. Running RabbitMQ 3.x with disclosed, unpatched CVEs is a direct finding under this requirement. OSSeva's extended support provides the patch delivery and attestation documentation QSAs and internal audit teams require.