Erlang/OTP SSH: CVSS 10.0 and You Don't Know You're Running It (CVE-2026-32433)

Most teams who run Erlang run it by accident. RabbitMQ is Erlang. CouchDB is Erlang. A lot of telecom infrastructure is Erlang. Ejabberd is Erlang. Whenever someone says "we use RabbitMQ for job queueing" they are also saying "we run the Erlang VM in production."

CVE-2026-32433 is a pre-authentication remote code execution bug in the Erlang/OTP ssh application. The vulnerability is that the SSH server processes certain connection-protocol messages before authentication completes, and attacker-controlled data reaches a code path that was never supposed to execute outside an authenticated session. CVSS is 10.0 because the exploit requires no credentials and grants code execution as whatever user the Erlang VM runs as -- often root.

The Erlang/OTP team shipped out-of-band patches on April 16, 2026. This is not a slow-moving advisory. Exploit development started within hours of disclosure, and by the time you read this there will be at least one public PoC.

What it lets an attacker do

Direct unauthenticated RCE in the Erlang VM. From there the attacker has whatever the VM has -- filesystem access, network access to internal services, and the ability to execute arbitrary Erlang, which trivially shells out to the underlying OS.

The interesting part is the second-order blast radius. RabbitMQ clusters hold messages that contain credentials, PII, and business logic payloads. CouchDB holds documents that are often a primary data store. An attacker who gets into the Erlang VM of a message broker gets the full cleartext of whatever that broker has processed in its lifetime.

How to tell if you're exposed

The fastest check: banner-grab port 22 on every service you run.

nc -w 3 your-rabbitmq-host 22
# If the banner starts with "SSH-2.0-Erlang" you are running the Erlang SSH server.

# Or, from the RabbitMQ host itself:
rabbitmq-plugins list | grep rabbitmq_shovel
# And check whether port 22 is bound by the erlang_inet_ssh process:
ss -tlnp | grep -E ':22 '

The RabbitMQ default is to not expose port 22 externally, but many operators enable the SSH-based management console and then forget to firewall it. CouchDB operators frequently run the Erlang SSH server on port 22 because the deployment guide encourages it.

If you cannot identify any Erlang-based services in your stack, you are probably fine -- but check your dependency graph. Anything that lists RabbitMQ, CouchDB, Riak, Ejabberd, MongooseIM, or LeoFS is running Erlang underneath.

What the PoC looks like

We will not link a PoC. The exploit targets the SSH connection protocol before authentication, which means it can be triggered by any host that can reach port 22. The banner grab above is enough to determine exposure; you do not need to send the exploit payload to know you're vulnerable. If a Shodan/Censys search returns your host on banner:"SSH-2.0-Erlang", assume you're on a target list.

The Erlang/OTP release notes contain the technical writeup with indicators of compromise.

Our scanner test for this

CELVEX Group runs ZERODAY-2026-0004 -- Erlang/OTP SSH server pre-auth RCE as a fully automated wave-1 check. Banner grabs on port 22 against every target host are part of standard recon; any SSH-2.0-Erlang banner raises a critical finding immediately. No active probing is required -- the banner itself is sufficient to conclude exposure given the vulnerability's pre-auth nature.

Module: core/test_catalog/_supplement_zeroday_2026-04-18.py, test_id ZERODAY-2026-0004.

What to do today

1. Patch OTP same-day. Patched versions: 26.2.5.11, 27.3.3, or 28.0.0-rc.4+. On RabbitMQ this means upgrading to a RabbitMQ release built against the patched OTP -- as of publication, 3.13.10 and 4.0.6 ship with the fix.
2. If you cannot patch today, firewall port 22 on every Erlang node so only your jump host can reach it. This is a hard isolation step, not a long-term fix. Add a task to your sprint to disable the Erlang ssh application entirely if you're not actively using it.
3. Rotate SSH host keys and any credentials the Erlang VM has access to after patching. If the VM held database credentials, API keys, or message-broker creds, treat all of them as potentially exfiltrated.