RabbitMQ and Erlang Version Compatibility: Which Brokers Have No Supported Runtime Left

The short version

There is no supported Erlang/OTP release that RabbitMQ 3.13, 3.12 or 3.11 can run on. RabbitMQ's own compatibility matrix caps each of those broker lines at an OTP release that has since reached end of life. Upgrading the runtime is not an available fix, because the broker will not run on anything newer.

This is not an interpretation. It falls directly out of two published tables — RabbitMQ's Erlang version requirements and the Erlang/OTP support calendar — read side by side.

The two tables, joined

The broker columns come from RabbitMQ's Erlang Version Requirements page. The end-of-life dates come from the Erlang/OTP release calendar. Later RabbitMQ 4.x releases raise the minimum to Erlang 26.2 and then 27.0, with 27.x as the maximum for most of them and 28.x supported only by the most recent. Always check the live matrix for your exact patch release — the bands are narrow and they shift between patch versions, as the three separate 3.12 rows show.

Why this is worse than an ordinary end-of-life

Normally, when a runtime reaches end of life, you upgrade the runtime. Here you cannot. RabbitMQ 3.13 is not supported on Erlang 27. The maximum in the matrix is the newest runtime that broker release was built and tested against, and RabbitMQ's guidance is to stay inside the band — running outside it means running a combination nobody has validated, on the component your messaging depends on.

So the dependency runs the wrong way for anyone hoping to patch around it:

• To get a patched runtime, you need Erlang 27 or later.
• To run Erlang 27, you need RabbitMQ 4.x.
• To run RabbitMQ 4.x, you have to complete the 3.x to 4.x migration — quorum queues replacing classic mirrored queues, feature flags enabled in order, and the client compatibility checks that go with it.

A runtime security patch therefore costs a major broker migration. That is the coupling that keeps clusters on one combination for years, and it is why the question “are we patched?” gets a confident yes from teams who have only looked at the broker.

What is actually exposed

RabbitMQ is an Erlang application. It does not implement TLS, SSH, certificate validation or its cryptographic primitives — it uses OTP's. Those live in the ssl, ssh, public_key and crypto applications, which have their own advisories on their own schedule.

In our exposure study we counted the CVE records NVD holds against each product's own CPE, published after a line's end-of-life date and still naming that line. Erlang/OTP 24 accumulated 22, nine of them CVSS 7.0 or above, topping out at 10.0 with CVE-2025-32433, a pre-authentication remote code execution flaw in the SSH application. Over the same window, RabbitMQ 3.12 and 3.13 accumulated none.

The broker is the layer everyone inventories. The runtime is where the advisories are.

How to check what you are running

# Broker and runtime together
rabbitmqctl status | grep -iE 'rabbitmq version|erlang'

# Runtime only, from the VM
erl -noshell -eval 'io:format("~s~n",[erlang:system_info(otp_release)]), halt().'

# Is the SSH application even loaded? (relevant to CVE-2025-32433)
rabbitmqctl eval 'application:which_applications().' | grep -i ssh

Record the pair, not the broker alone. A version inventory that says “RabbitMQ 3.13.7” and nothing else has captured the less risky half.

The options, honestly

1. Migrate to RabbitMQ 4.x and Erlang 27 or 28. The correct destination. Budget it as a migration: classic mirrored queues are gone in 4.x, so anything still using them has to move to quorum queues first.
2. Stay, and accept a runtime with no patch stream. This is the default outcome, and it is rarely a decision. It deserves to be one, written down and owned.
3. Extended support on the pair you run. This is what we sell, so weigh it accordingly: OSSeva ships patched OTP 24, 25 and 26 builds matched to the RabbitMQ 3.11 to 3.13 releases that depend on them, so the broker keeps a patched runtime while the 4.x migration is planned rather than forced.

The next deadline is already set

Erlang/OTP 27 reaches end of life on 20 May 2027. Most RabbitMQ 4.x releases list 27.x as their maximum. Anyone who migrated to 4.x to escape this problem should confirm, well before May, that the release they are on supports Erlang 28.

Related

• Erlang/OTP extended support
• Erlang/OTP 26 end of life · OTP 25 · OTP 24
• RabbitMQ 3.13 end of life
• RabbitMQ support