PatchDayAlert
Analysis · 5 min read · 1,081 words By Colten Anderson · Commentary

Your vuln scanner is looking for OpenSSH. The exploited bug is in Erlang.

CVE-2025-32433 is a CVSS 10.0 pre-auth RCE in Erlang/OTP's SSH server, and it's exploited in the wild against OT firewalls. The reason it slips past your scans is the whole point.

Your vuln scanner is looking for OpenSSH. The exploited bug is in Erlang.

The bug everyone’s exploiting right now is in an SSH server you didn’t know you were running. Your vulnerability scanner checks OpenSSH versions. It does not check for the Erlang SSH daemon embedded in your Cisco gear, and that gap is exactly where the attacks landed.

CVE-2025-32433 is an unauthenticated remote code execution flaw in the Erlang/OTP SSH server, scored at CVSS 10.0, the maximum, with an EPSS of roughly 67 percent. The mechanism is clean and ugly at the same time: the SSH server processes connection-protocol messages with message codes 80 and above, things like SSH_MSG_CHANNEL_REQUEST, before authentication finishes. An unauthenticated attacker sends those pre-auth messages, breaks out of the key-exchange state machine, opens a channel, and runs OS commands as the Erlang SSH daemon process. No credentials. No foothold. Just a reachable port and a malformed handshake.

Researchers at Ruhr-University Bochum disclosed it on April 16, 2025. The Erlang team patched within 48 hours. Proof-of-concept exploits showed up the same day the patch shipped. That’s the part that should make you sit up: the window between “fixed” and “weaponized” was effectively zero.

The patch is in a stream you don’t manage

Here’s what makes this one worse than a normal CVSS 10. Patching it means updating Erlang/OTP itself, to OTP-27.3.3, OTP-26.2.5.11, or OTP-25.3.2.20. That is not the package-manager path your OS patching cadence handles. If Erlang got onto your network as the runtime under some vendor’s appliance, the fix arrives on that vendor’s schedule, not yours.

And it did get onto your network that way. Cisco’s network management systems use Erlang/OTP through the Tail-f ConfD configuration engine, embedded across many Cisco routers and network management platforms; Cisco published its own advisory (cisco-sa-erlang-otp-ssh) covering the affected products. NetApp published advisory NTAP-20250425-0001 on April 25 listing its affected products. SUSE issued packages too.

One useful correction, because the early coverage got it wrong: RabbitMQ is not affected. The maintainers stated plainly on April 24 that RabbitMQ does not use the Erlang/OTP SSH library, server or client. If you spent a weekend in April chasing RabbitMQ nodes, you chased the wrong thing. Spend this week on the network gear instead.

This is why the OT firewalls got hit first

The attackers went where the inventory is thinnest. Unit 42 documented active in-the-wild exploitation between May 1 and May 9, 2025, including reverse-shell payloads setting up unauthorized remote access. TXOne Networks observed the same in OT environments. CSO Online’s headline said it directly: “Hackers exploit unpatched Erlang/OTP to crack OT firewalls.”

Operational technology firewalls and networking infrastructure were the primary targets. That is not a coincidence, and it is not because OT is exotic. It’s because those devices are the ones least likely to be inventoried for embedded runtimes and most likely to sit on long patch cycles. An attacker betting that nobody knows there’s an Erlang SSH server inside the OT firewall is making a very safe bet. The OS-version scan comes back clean. The OpenSSH check comes back clean. The thing listening on a separate port, on a separate daemon, speaking a banner nobody parses, never gets looked at.

That banner is the one thing working in your favor. The Erlang SSH server announces itself as SSH-2.0-Erlang/X.X.X. Censys counted roughly 253 internet-exposed Erlang SSH servers at the time of its analysis. The catch: the banner shows the SSH application version, not the OTP version, so you have to translate it to know whether a given box is actually patched. It’s a clue, not a verdict.

Why this keeps happening

Embedded runtimes are a patch-management blind spot by design, and the design isn’t malicious; it’s just convenient for everyone except the person who has to defend the result. A vendor ships a product. That product needs SSH-based configuration management. Reaching for Erlang/OTP and its SSH library is a reasonable engineering call. The vendor doesn’t surface “by the way, there’s an Erlang SSH daemon in here” on the datasheet, because that’s an implementation detail nobody markets.

So the runtime disappears into the appliance. Your asset inventory records the product, not its dependencies. Your scanner knows about the OS and the services it recognizes. The embedded SSH server lives in the seam between those two views, owned by no patch stream you control, exposed on a port you didn’t open on purpose. Multiply that across Cisco, NetApp, and whatever OT vendor is in your rack, and you get a vulnerability that is simultaneously a CVSS 10 and nearly invisible to the tools meant to catch CVSS 10s.

CISA caught up to the reality on June 9, adding CVE-2025-32433 to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of June 30. If you run federal systems, that date is the law. If you don’t, treat it as the date the rest of us should already be done by.

What to actually do this week

Don’t wait for the scanner to flag this, because it won’t. Pull the advisories for every network-infrastructure and storage vendor in your environment: Cisco’s ConfD-based products, NetApp per NTAP-20250425-0001, SUSE packages. For anything internet-facing, look for the SSH-2.0-Erlang banner on every port, not just 22. Remember the banner version needs translating before you call a box patched. Where a vendor fix isn’t out yet, restrict reachability to the management interface and stop treating “we patched OpenSSH” as if it covered this. It didn’t. It was never going to.

The uncomfortable part isn’t that Erlang/OTP had a bug. Software has bugs. The uncomfortable part is that a maximum-severity, actively exploited, zero-credential RCE can sit on your perimeter for weeks because the standard tooling has no idea the vulnerable service exists. The attackers figured that out before the defenders did. That’s the actual finding here, and it’ll be true again next quarter under a different runtime’s name.

The PatchDayAlert digest tracks the ones like this, the bugs hiding inside something else, and flags which vendor update actually clears them.

Sources

Share

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.

Subscribe