Erlang/OTP Vulnerabilities by Version: CVEs for OTP 24 to 29 and the RabbitMQ Releases That Pin Them

The short answer

Three Erlang/OTP major releases get security fixes today: OTP 27, 28 and 29. According to endoflife.date, OTP 27 is supported until 20 May 2027, OTP 28 until 20 May 2028 and OTP 29 until 11 May 2029. OTP 26 reached end of life on 26 May 2026, and its last release, 26.2.5.21, shipped that day. OTP 25 ended in May 2025 with 25.3.2.21, and OTP 24 in May 2024 with 24.3.4.17. No Erlang/OTP advisory published since June 2026 names an OTP 26 fix. That includes CVE-2026-89422, a TLS 1.3 client authentication bypass rated 9.3, and it matters for RabbitMQ because public RabbitMQ 3.13 releases cannot run on anything newer than OTP 26.

OTP release lines

In practice the project patches the three newest major releases. A new major ships each May, and the oldest of the three drops out of support around the same time.

Erlang advisories are published by the Erlang Ecosystem Foundation, the CVE numbering authority for Erlang/OTP, and give an affected range per OTP release and per application (ssl, ssh, inets, erts, public_key and so on). Many 2026 records, including all of September's, are in NVD's Deferred status, so for those NVD shows only the EEF's CVSS 4.0 score.

The 2026 advisory waves

Each row is one set of patch releases. The CVEs listed are those rated 7.0 or higher by NVD or by the EEF; each wave also fixed medium and low issues, and patch sets with nothing rated 7.0 or higher are left out.

OTP 26 missed every row from June onward, and almost all of those advisories list OTP 26 inside the affected range.

Notable Erlang/OTP CVEs by release line

NVD has analysed some of these records and scored them itself with CVSS 3.1, often differently from the EEF's CVSS 4.0 score. Where both exist, the table shows both.

"Not patched" means the release is inside the affected range and no patch on it carries the fix.

September 2026: CVE-2026-89422 and the rest of the month

CVE-2026-89422 is a flaw in the TLS 1.3 client. If the ServerHello carries a pre_shared_key extension the client never offered, the client treats the handshake as a resumption and skips the server certificate entirely, so a peer with no certificate and no key can pose as the intended server. The default client configuration is affected, and clients limited to TLS 1.2 are not. It affects OTP 22.2 and later and is fixed in 27.3.4.18, 28.5.0.7 and 29.1.1. Our write-up of CVE-2026-89422 on OTP 26 covers where RabbitMQ acts as a TLS client.

NVD lists 19 Erlang/OTP CVEs published between 1 and 22 September 2026: CVE-2026-89422, which the EEF rates critical, 13 rated high and 5 medium. Sixteen came on 1 September with 27.3.4.17, 28.5.0.6 and 29.0.6, and ten of those are in inets httpd, the web server that ships with OTP. One of them, CVE-2026-73812, is a gap left by the March fix for CVE-2026-23941: since then httpd rejects duplicate Content-Length headers, but it still accepts a request that carries both Transfer-Encoding and Content-Length. The other three came on 22 September with 27.3.4.18, 28.5.0.7 and 29.1.1. None of the 19 has an OTP 26 fix.

CVE-2025-32433, the SSH remote code execution

CVE-2025-32433 (10.0) lets an unauthenticated attacker run code on any node that runs the Erlang/OTP SSH server, through a flaw in how the server handles SSH protocol messages. CISA added it to the Known Exploited Vulnerabilities catalogue on 9 June 2025. It is fixed in 25.3.2.20, 26.2.5.11 and 27.3.3, and OTP 24 and older got no fix. The 10.0 is the GitHub CNA score on NVD.

It only matters where the ssh application runs as a daemon. RabbitMQ does not use Erlang SSH, so a broker is not exposed through it, but other Erlang and Elixir software may be, and NVD's record lists Cisco ConfD and Network Services Orchestrator among the affected products. Check for it with application:which_applications() on each node.

Which RabbitMQ versions pin which OTP

RabbitMQ supports a narrow band of OTP releases per patch version, so the broker version decides which runtime fixes you can take. The ranges below are from RabbitMQ's Erlang version requirements page.

RabbitMQ's notes add that OTP 28 is partly supported from 4.2.0, for brand new clusters only, because Khepri clusters upgraded from OTP 27 can hit a known issue in mixed-version clusters. Every public 3.x release is capped at an OTP release that is now out of support, so on 3.x no supported runtime exists with the 2026 fixes from June onward. On 4.x the runtime is OTP 27 for most releases, which is supported until 20 May 2027. RabbitMQ and Erlang version compatibility covers the pairs in more detail.

What a broker exposes depends on what it runs, not just the OTP version. RabbitMQ's HTTP listeners run on Cowboy rather than inets httpd, so the inets httpd CVEs do not reach them, and it does not use the ssh application. The TLS, public_key, asn1 and erts flaws are a different matter: any TLS listener, and any outbound TLS connection from a Shovel, Federation link, LDAP server or OAuth 2 key fetch, goes through the OTP code those advisories fix.

What each line gets

OTP 29, 28 and 27

Each has been patched in every advisory since it was released. 27.3.4.18, 28.5.0.7 and 29.1.1 are the releases to run. OTP 27 is the next to leave support, on 20 May 2027, and most RabbitMQ 4.x releases list 27.x as their maximum, so check now that your broker release supports OTP 28.

OTP 26

OTP 26 ended on 26 May 2026 with 26.2.5.21, which carried the fixes for CVE-2026-42790 and CVE-2026-42789. Since then it has missed every advisory, including CVE-2026-89422 at 9.3 and CVE-2026-55953, a TLS 1.2 client flaw that NVD scores 7.4 and the EEF 9.1. See Erlang/OTP 26 end of life.

OTP 25

OTP 25 ended in May 2025. Its last fixes were for CVE-2025-32433 in 25.3.2.20 and the strict key exchange fix for CVE-2025-46712 in 25.3.2.21. It has missed the SSH and SFTP resource exhaustion fixes of September 2025, such as CVE-2025-48041, and everything since. See Erlang/OTP 25 end of life.

OTP 24

OTP 24 ended in May 2024 with 24.3.4.17. It has no fix for CVE-2025-32433, the KEV-listed SSH remote code execution, or for anything after it. See Erlang/OTP 24 end of life.

What to do on each line

• 27, 28 and 29. Take each patch release. In 2026 the sets have come roughly once a month.
• 26 under RabbitMQ 3.13 or 4.0.1 to 4.0.3. The runtime fix needs RabbitMQ 4.0.4 or later on OTP 27, or a patched OTP 26 build. No client TLS setting on an unpatched OTP 26 avoids both TLS client flaws: the CVE-2026-89422 advisory's workaround is to restrict clients to TLS 1.2, and the CVE-2026-55953 advisory's is to use TLS 1.3 only. Pick the one that fits each connection, and treat it as a stopgap.
• 25 and 24. Confirm whether the ssh application runs. If it does, CVE-2025-32433 is the first thing to close.
• Standalone Erlang and Elixir services. These usually move between OTP majors more easily than RabbitMQ does. Rebuild and test on OTP 27 or 28.

Where OSSeva fits

OSSeva ships patched Erlang/OTP 24, 25 and 26 builds with security fixes for the ssl, ssh, public_key and crypto applications backported, so a RabbitMQ 3.x cluster keeps a patched runtime while the move to 4.x is planned. They are available now on the Patch, Assure and Operate tiers. Assure adds the OTP upgrade path mapped against your broker estate, and Operate adds 24/7 BEAM monitoring with a 15-minute SLA and named Erlang engineers. See the Erlang/OTP support page and the Erlang/OTP end-of-life chart.