Erlang/OTP CVE-2026-89422 and OTP 26: What RabbitMQ 3.13 Users Need to Know

The short answer

CVE-2026-89422 is a flaw in the Erlang/OTP ssl application, published on 22 September 2026 with a CVSS 4.0 score of 9.3 from the EEF, the CVE numbering authority for Erlang. A TLS 1.3 client on an affected release can be made to finish a handshake without checking the server's certificate at all, so whoever answers the connection can pose as the intended server. It affects OTP 22.2 and later. The fixes are OTP 27.3.4.18, 28.5.0.7 and 29.1.1, released the same day. OTP 26 gets no fix: it reached end of life on 26 May 2026, and its last release was 26.2.5.21.

That matters for RabbitMQ 3.13 because RabbitMQ's compatibility matrix limits the public 3.13 releases, 3.13.0 to 3.13.7, to Erlang 26.0 through 26.2.x. Broadcom's knowledge base article 450171 shows Erlang 27 support for 3.13 starting at 3.13.8, which is a commercial release. A community 3.13 cluster has no supported runtime that contains the fix.

What the flaw does

In TLS 1.3, a client that wants to resume an earlier session offers a pre-shared key, and the server can accept it in its ServerHello. Affected OTP releases accept a pre_shared_key extension in the ServerHello even when the client never offered one. The client then treats the handshake as a resumption and skips the states that handle the server certificate. Path validation, verify_fun, hostname verification, partial_chain, CRL checks and OCSP stapling are all bypassed, and ssl:connect returns a working socket to a peer that holds no certificate, no private key and no earlier session.

Three details from the advisory set the scope:

• It is a client-side flaw. Erlang TLS servers are not affected by this CVE.
• The default client configuration is affected. Nothing unusual has to be switched on.
• Clients restricted to TLS 1.2 are not affected, because the code path exists only in TLS 1.3.

An affected connection leaves few traces. Per the advisory, ssl:peercert/1 returns no certificate despite verify_peer, and the connection reports session resumption for a client that never held a ticket.

Where RabbitMQ is a TLS client

RabbitMQ's own listeners for AMQP, MQTT, STOMP, streams and the management UI are TLS servers, so this CVE does not touch them. The broker becomes a TLS client when it opens connections of its own:

• Shovel and Federation links to a remote broker over amqps. An impersonator receives the credentials in the link URI and the messages the link moves, and can feed messages back.
• LDAP over TLS, when the LDAP backend authenticates users. An impersonator sees the bind credentials and decides the bind result.
• OAuth 2 signing key fetches from the identity provider's JWKS endpoint over HTTPS. An impersonator could hand the broker its own keys and have its tokens accepted, the same outcome as RabbitMQ's own CVE-2026-67404 by a different route.
• Inter-node traffic, if Erlang distribution runs over TLS, since each node dials its peers as a client.

RabbitMQ's compatibility matrix names TLS-enabled Shovels, Federation links and LDAP server connections as the client connections affected when OTP 26 turned on peer verification by default, so this is a list the project already tracks. Every case needs an attacker who can answer the connection: someone on the network path, or someone who can redirect the hostname the broker dials.

The other OTP advisories OTP 26 will not get

CVE-2026-89422 is the most serious of 14 Erlang/OTP CVEs NVD published between 1 and 22 September 2026: 1 critical, 9 high and 4 medium. Each one lists OTP 26 inside its affected range and names fixed releases on 27, 28 and 29 only. The high-severity ones:

The four medium CVEs are in stdlib, snmp, eldap and httpc. The eldap one, CVE-2026-70409, applies to clusters that use LDAP authentication: a malicious or compromised LDAP server can return a referral whose port is a run of about a million digits and degrade availability.

What to do

1. Find the OTP version on each node. rabbitmq-diagnostics erlang_version prints it. OTP 26, and OTP 27 before 27.3.4.18, are affected.
2. Apply the advisory's workaround if the runtime cannot change yet. Restrict the broker's outbound TLS connections to TLS 1.2. Shovel and Federation URIs, the LDAP plugin, the OAuth 2 plugin and inter-node TLS each have their own TLS settings, so set it everywhere the broker acts as a client. The advisory states that no configuration keeps TLS 1.3 and mitigates the flaw. That trade has a cost: CVE-2026-55953 is a TLS 1.2 client flaw in the same OTP releases, and its advisory recommends TLS 1.3 only. On unpatched OTP 26 no TLS setting avoids both, so the workaround narrows exposure rather than removing it.
3. Plan the runtime move. RabbitMQ 4.0.4 and later, 4.1, 4.2 and 4.3 support Erlang 27, which has the fix. For community 3.13, the route to a patched runtime is an upgrade to 4.x, and that starts with migrating classic mirrored queues to quorum queues. RabbitMQ and Erlang version compatibility sets out the pairs.

Upgrading the runtime does not close the broker's own advisories. The 32 RabbitMQ server CVEs from September that list 3.13 are fixed only in commercial 3.13 releases; see the RabbitMQ September 2026 CVEs for that half.

Where OSSeva fits

OSSeva ships patched Erlang/OTP 24, 25 and 26 builds with security fixes for the ssl, ssh and crypto applications backported, CVE-2026-89422 among them, alongside patched RabbitMQ 3.13 broker builds. A community 3.13 cluster can close both layers without changing its OTP major version while the queue migration runs. Builds are signed and delivered through your own repository manager on the Patch tier; Assure adds a VEX statement for each CVE; Operate adds 24/7 operation. See RabbitMQ 3.x extended support, the Erlang/OTP support page and the RabbitMQ support page. Dates are on the Erlang/OTP end-of-life chart, Erlang/OTP 26 end of life and RabbitMQ 3.13 end of life.