Version 26 reached end-of-life on 26 May 2026 and no longer receives security patches. Because the 3.13 line supports a maximum of 26.2.x, those deployments cannot move to a maintained runtime — the only way out is upgrading the broker itself.
That is the wedge. Not ordinary technical debt you can defer: an audit finding with a date on it.
The compatibility matrix
The published erlang version requirements, by broker series — a supported erlang version means both minimum and maximum:
| Series | Minimum | Maximum |
|---|---|---|
| 4.3.x | 27.0 | 27.x — v28 for brand-new clusters only |
| 4.2.x | 26.2 | same ceiling; Erlang 28 is partially supported |
| 4.1.x | 26.2 | same ceiling; v28 partially supported |
| 4.0.x | 26.2 | same ceiling from 4.0.4 |
| 3.13.x | 26.0 | 26.2.x |
The docs state it plainly: Erlang 26 has reached end of life and is no longer maintained. Anything on 3.9 or 3.8 is further behind again, and those RabbitMQ versions lost community support long ago.
Runtime dates per endoflife.date — security support ends:
| Release | Ends |
|---|---|
| Erlang 25 and earlier | Passed |
| Erlang 26 | 26 May 2026 — passed |
| v27 | 20 May 2027 |
| v28 | 20 May 2028 |
Why 3.13 cannot just move to the latest Erlang
The instinct on hearing "your runtime is unsupported" is to upgrade the runtime. Here you cannot.
The 3.13.x line tops out at 26.2.x. Install a newer runtime underneath and the broker will not start. So a 3.13 estate has two available states: an unsupported runtime, or a broker upgrade.
No configuration, backport, or patch resolves this from inside 3.13. The version support ceiling *is* the problem.
What the risk actually is
Be precise here, because overstating it is easy and wrong.
The Erlang/OTP SSH server carried a critical unauthenticated RCE in 2025 — CVSS 10.0, exploited in the wild by ransomware operators. RabbitMQ was not affected. It does not use that SSH library, and the packages the project distributes on GitHub omit it. Anyone claiming that CVE endangers your broker is wrong.
The exposure is structural, not specific. That incident proves the runtime does receive critical, actively exploited vulnerabilities. The next may land somewhere the broker genuinely depends on — TLS, OpenSSL bindings, the distribution layer — and past its support policy, no patch will be published for you.
Auditors understand that distinction. An unmaintained runtime under production messaging is a finding whether or not a CVE has landed yet.
Your options
1. Upgrade to 4.1.x or later
The direct route. Both 4.1 and 4.2 accept the current release, so broker and runtime resolve together. Sequence matters: latest 3.13 patch first, then the broker, then the runtime — rolling one node at a time so the cluster keeps serving.
Expect real work. Classic queue mirroring was removed in 4.0, so mirrored-queue redundancy has to become quorum queues first. See upgrading RabbitMQ 3.x to 4.x without downtime and our guide to RabbitMQ version support.
2. Move to a commercially supported broker
If the upgrade cannot happen this quarter — frozen change window, certified application, air-gapped estate — commercial RabbitMQ licensing provides a supported broker built against a maintained runtime, with security patches backported to the version you actually run.
Where community support has ended, this is the only path that keeps you defensible in an audit. It buys a supported position while you plan the migration properly.
3. Do nothing
Occasionally defensible for an isolated internal system with no regulatory exposure. Rarely right for anything customer-facing, and it should be a documented decision rather than a default.
Is RabbitMQ 3.13 still supported?
No. The 3.13 series has reached end of community support, and that is the second half of the
problem. Even setting the runtime aside, a 3.13 broker no longer receives security fixes from
the RabbitMQ project. The Erlang 26 end of life date compounds an exposure that already exists
rather than creating a new one.
This is why "we will upgrade Erlang and stay on 3.13" is not a plan. The broker and the runtime
are both out of support, and only one of them can be fixed without touching the other.
What happens on 26 May 2026?
Nothing breaks that day. This is the part teams consistently misread.
Erlang 26 keeps running exactly as it did. What stops is the supply of security patches from the
Erlang/OTP team. From that date, any vulnerability found in the runtime your broker depends on
has no official fix for your version. The risk does not arrive as an outage — it accumulates
quietly as unpatched CVEs, and it usually surfaces during an audit or a customer security review
rather than in monitoring.
That distinction matters for how you plan. There is no emergency on the day. There is a steadily
worsening compliance position from the day onward, and the cost of fixing it does not fall over
time.
Three ways out, ranked by disruption
1. Upgrade to RabbitMQ 4.1.x or later. The cleanest answer. It puts you on a supported broker
and a supported runtime in one move, and it is the only option that resolves both problems
permanently. Budget for the classic-to-quorum queue migration, which is the real work.
2. Move to a commercial build. If the upgrade cannot happen inside your compliance window,
a commercially supported distribution buys covered time on a maintained runtime while you plan
properly. This removes the deadline, not the upgrade.
3. Accept the risk with documentation. Occasionally defensible for an isolated, air-gapped
estate with a decommission date already agreed. It is a decision to record deliberately, not a
default to drift into.
What is not on the list is staying on 3.13 with Erlang 26 indefinitely and hoping the topic does
not come up. It comes up.
Check what you are running
rabbitmqctl status | grep -A2 ErlangOr from a shell on any node — this also confirms what running RabbitMQ actually loaded:
erl -eval 'erlang:display(erlang:system_info(otp_release)), halt().' -noshellRun it everywhere. Mixed runtimes across a cluster cause their own failures — the project recommends the same major release on every node, and drift produces errors that look like network faults. On RHEL and CentOS the zero-dependency Erlang RPM pins a known-good build; Ubuntu users should configure the project's apt repository rather than distribution packages, which lag badly.
While you are there, check TLS. Client peer verification is enabled by default in newer releases, so a TLS certificate and key pair that worked on an older build may need attention during the move — verification failures at cutover are a common surprise.
FAQ
Which runtime versions are supported?
The latest Erlang line is fully supported for current RabbitMQ releases. Erlang 28 is partially supported from 4.2 onward and permitted for brand-new 4.3 clusters. Erlang 26 has ended; 25 and older are long past.
Can RabbitMQ 3.13 run the newer runtime?
No. Its maximum is 26.2.x. Installing a later release under 3.13 is unsupported and the broker will not start correctly.
Is my broker vulnerable because the runtime is out of support?
Not to any specific published flaw today. The exposure is that future vulnerabilities will not be patched, and you cannot reach a patched runtime without upgrading the broker.
Does CVE-2025-32433 affect the broker?
No. It affects the Erlang/OTP SSH server, which RabbitMQ does not use, and the distributed packages exclude that library. The project published confirmation it is unaffected.
What is the minimum runtime for 4.1?
Version 26.2, with 27.x as the maximum. That range makes 4.1 the common upgrade target from 3.13 — it accepts a runtime you may already have while opening the path to a supported one.
Where is the official compatibility information?
The project publishes an erlang version requirements page covering every currently supported release, plus its release policy and support schedule. Check there before making a compliance decision.
Running 3.13 on an unmaintained runtime and need to know where you stand? AceMQ assesses legacy
estates, plans migration to a supported build, and provides
RabbitMQ support for legacy versions while you get there.
