// RabbitMQ 3.x extended support
Still on RabbitMQ 3.13?
Your broker and your Erlang runtime are both out of support.
Public RabbitMQ 3.13 builds run on Erlang/OTP 26, and OTP 26 stopped receiving patches in May 2026. Fixes for newer RabbitMQ advisories on the 3.13 line ship only in commercial releases. Moving to a patched runtime means moving to RabbitMQ 4.x, and moving to 4.x means migrating every mirrored queue. OSSeva patches both layers while you do that on your own schedule.
Trusted globally by enterprises




Why RabbitMQ 3.x estates are stuck
Most teams would upgrade tomorrow if the upgrade were a version bump. For RabbitMQ 3.x it is three separate projects that have to land in order.
RabbitMQ 4.0 removed classic queue mirroring
Every queue that relies on an ha-mode policy has to be redeclared as a quorum queue before the cluster can leave 3.13. Quorum queues handle poison messages, priorities, exclusive queues and global QoS differently, so this is application work, not a broker setting.
There is no supported Erlang for public 3.13 builds
RabbitMQ's compatibility matrix caps the public 3.13.x releases at Erlang/OTP 26. OTP 26 left Erlang's supported window when OTP 29 shipped in May 2026. The TLS, SSH and crypto code the broker depends on belongs to OTP, so a current broker on an old runtime is still exposed.
Older lines face a two-hop upgrade
RabbitMQ requires every upgrade to 4.x to pass through 3.13 with all feature flags enabled. A 3.8 or 3.9 cluster first climbs through the 3.x releases, often with an Erlang upgrade at each step, before the quorum queue work even starts.
The dates that matter
2024-09-30
RabbitMQ 3.13 community support ends. 3.13.7 is the last public release; later 3.13 patches are commercial only.
May 2026
Erlang/OTP 26 leaves Erlang's supported window when OTP 29 ships. Its final patch, 26.2.5.21, lands on 27 May. Public 3.13 builds have no patched runtime left.
2029-12-31
End of Broadcom's commercial support for RabbitMQ 3.13, for Tanzu licence holders only.
Watch
Amazon MQ has not yet announced end of support for RabbitMQ 3.13. When it does, brokers get a fixed notice period before forced upgrades.
What OSSeva delivers
Patched RabbitMQ 3.x builds
Backported CVE fixes for the broker, the management plugin and the shipped plugin set, delivered as signed packages and container images through your own repository manager.
A patched Erlang/OTP runtime
Security fixes for the OTP releases your broker actually runs on, so the TLS, SSH and crypto layers are covered along with the broker.
Quorum queue migration
Inventory of mirrored queues and policies, a route per vhost, dead-letter and delivery-limit design, and failover testing before the move to 4.x.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Migrate to 4.x now | A supported broker and runtime from the community | The quorum queue migration has to be finished first, and for large estates that is quarters of work. |
| Broadcom Tanzu RabbitMQ | Commercial 3.13 patch releases from the vendor | Requires a Tanzu commercial licence, which is priced for large enterprise commitments. |
| OSSeva extended support | Patched broker and Erlang runtime, plus migration help | A subscription per cluster or estate while you migrate. |
| Stay unpatched | Nothing | Every broker and OTP advisory since end of life stays open, and auditors see an unsupported version. |
Dates from rabbitmq.com release information and Erlang version requirements, and the Erlang/OTP release calendar.
Frequently asked questions
Who still provides support for old RabbitMQ versions?
Broadcom sells commercial patch releases for RabbitMQ 3.13 to Tanzu licence holders. OSSeva provides extended support for community RabbitMQ 3.8 to 3.13, including the Erlang/OTP runtime underneath, without a Tanzu licence.
Can RabbitMQ 3.13 run on Erlang 27?
Not the public releases. RabbitMQ's compatibility matrix caps 3.13.0 to 3.13.7 at Erlang/OTP 26. Running outside the supported band means running a combination nobody has tested.
Is RabbitMQ 3.13 still safe to run?
It runs, but the community no longer patches the broker and the Erlang/OTP 26 runtime it depends on stopped receiving fixes in May 2026. Without extended support, new advisories in either layer stay open.
Are there RabbitMQ 3.13 vulnerabilities without a public fix?
Yes. CVE-2025-50200 (credentials logged by the HTTP API) was fixed on the 3.13 line in 3.13.8, and CVE-2026-57213 (stored XSS in the federation management page) in 3.13.14. Both are commercial-only releases; the last public build is 3.13.7.
Khepri is enabled on our 3.13 cluster. Can we upgrade to 4.x?
Not in place. RabbitMQ's 4.0 release notes state there is no direct upgrade path from 3.13 with the experimental Khepri metadata store enabled; the supported route is a blue-green deployment to a new 4.x cluster.
Do you patch the Erlang runtime too?
Yes. A patched broker on an unpatched runtime is not a patched system, so the OTP layer is inside the agreement.
Will you help us migrate to RabbitMQ 4?
Yes. Extended support buys time; the quorum queue migration is how you stop needing it. We inventory mirrored queues and policies, choose a route per vhost, and test failover before cutover.
Keep 3.13 patched while the queues move.
Discovery call, estate inventory, proposal. Patched builds can be in your repository within days of signature.