CVE-2025-32433: critical Erlang/OTP SSH server RCE

CVE-2025-32433 is a critical vulnerability in the Erlang/OTP SSH server. It received the maximum CVSS 10.0 score because a network attacker can execute arbitrary commands before authentication, with no password, SSH key or user interaction. Not every Erlang application is exposed; the affected systems are those that run an SSH server based on the Erlang/OTP ssh module.

Priority action: locate applications using the Erlang/OTP SSH server, install the patched release for the applicable OTP branch, and disable or firewall the service until updating is possible. A public PoC exists, and hiding a version banner is not a security control.

Key facts

Attribute	Confirmed value
CVE	CVE-2025-32433
Component	Erlang/OTP SSH server
CVSS	10.0 — critical
Account required	no
User interaction	no
Impact	command execution with service-process privileges
Fixed OTP releases	27.3.3, 26.2.5.11, 25.3.2.20
Fixed `ssh` releases	5.2.10, 5.1.4.8, 4.15.3.12
Public PoC	yes

The official Erlang/OTP advisory says that users running the library’s SSH server are affected regardless of the application’s purpose. Releases before OTP 17 are outside the new version-comparison scheme, but the maintainers consider them likely affected too.

The protocol-state flaw

SSH has defined stages: transport negotiation, key exchange, authentication, then session channels and command execution. An implementation must reject messages received in the wrong protocol state.

CVE-2025-32433 stems from incorrect handling of SSH messages before authentication completes. A vulnerable server accepted certain connection-protocol messages while the client had not proved its identity. That enabled access to functionality intended for an authenticated session.

This is not a weak-password issue or obsolete cipher. Changing a password, disabling root login or requiring public keys does not remove the vulnerability because exploitation bypasses the authentication boundary itself.

Root cause and the patch mechanism

Completing SSH key exchange does not mean that the client has been authenticated. The server must maintain separate state for transport, user authentication and the connection protocol that handles session channels. The Erlang/OTP flaw allowed a connection-protocol message to be processed while the user state was still unauthenticated. That crossed the boundary defined by RFC 4252 and made functionality intended for a later session phase reachable too early.

The Erlang/OTP remediation commit shows the essential change without requiring anyone to reproduce an exploit: the daemon disconnects a client when it receives a connection-protocol message before authentication. The patch does not strengthen a password or cipher; it enforces the correct state transition. This matters for triage because password rotation, key replacement and disabling administrator login may be useful general controls, but they are not substitutes for updating the library.

Code reached through the flaw executes in the service process context. The practical blast radius therefore depends on the BEAM VM account, filesystem access, mounted secrets, container permissions and network routes. CVSS describes the vulnerability’s technical potential; the environment-specific risk assessment should add those dependencies.

Where to find the vulnerable component

Erlang/OTP SSH may be embedded in a network appliance, telecom platform, management product, IoT system or a custom application exposing an administration shell. The dependency can sit inside a closed product whose operators do not associate it with a separate SSH service.

Inventory should combine:

listening ports and processes related to the BEAM VM;
container SBOMs and runtime dependencies;
application configuration invoking ssh:daemon or equivalent functionality;
vendor documentation for appliances and embedded products;
scans of internal, OT and management segments;
distribution package versions, which may not match upstream numbering.

Attack-surface model

Question	Evidence to collect	Why it changes priority
Is an OTP SSH server running?	`ssh:daemon` configuration, an active listener and the BEAM process	Erlang or an SSH client alone does not create exposure
Who can connect?	routes from the Internet, user networks, clusters, VPN, OT and management segments	no account is required, but network reachability is
What code is actually loaded?	complete OTP and `ssh` application versions in the running runtime	an image or package version does not prove that the process restarted
Which privileges does BEAM have?	UID, capabilities, host access, volumes and secrets	these determine the immediate RCE blast radius
Where can the service connect?	egress rules and access to databases, control planes and internal services	this reveals potential post-compromise paths
Who owns the update?	application team, distribution or appliance vendor	this prevents unsupported manual library replacement

In container environments, compare the SBOM with the artifact that is actually running and apply the controls in the container image security guide. For administrative services spanning several segments, a route map is more useful than an “internal” label. Zero Trust network segmentation can reduce reachability, but it does not turn an affected release into a fixed one.

There is no reason to emergency-patch every host containing Erlang without first confirming service exposure. Every active Erlang/OTP SSH server, however, deserves highest priority when reachable from user networks, the Internet or untrusted workloads.

Public PoC and safe testing

The public ProDefense/CVE-2025-32433 repository contains a PoC demonstrating the flaw. It can invoke a command on a remote system and must only be used in an isolated lab or an explicitly authorised engagement.

A safe verification path is:

confirm that the service uses Erlang/OTP SSH rather than OpenSSH;
identify the complete OTP and ssh application versions from the package or runtime;
compare them with the fixed release in the OTP 25, 26 or 27 branch;
clone the configuration into an isolated environment without production data;
perform only a TCP/SSH reachability check and identify the component without sending a sequence that invokes code;
if a dynamic regression test is necessary, run it against a reproduced lab instance with process monitoring and no production data;
after patching, confirm the runtime restarted and loaded the new code.

Do not make the decision from an SSH banner alone. Banners can be changed, hidden or supplied by an intermediate service.

Safe exposure validation does not require the PoC. A team can determine status from deployment manifests, the loaded ssh application version, listener configuration and network-path testing. If the runtime version cannot be read, treat an ambiguous reachable server as requiring clarification by its owner or supplier, not as automatically safe.

Triage decision tree

The Erlang/OTP SSH server is not running: document evidence from configuration and runtime, check whether the feature can start conditionally, then close the alert as no active attack surface.
The server runs a fixed release: confirm the loaded ssh version, process restart and access policy, then proceed to a controlled retest.
The release is vulnerable and the listener is reachable from an untrusted zone: disable the service or block traffic, deploy the update urgently and review telemetry from the point at which the service became reachable.
The release is vulnerable but access is restricted: retain a default-deny rule, test it from every relevant zone and schedule the update. Isolation lowers likelihood but does not repair the flaw.
Host or network anomalies are present: move from vulnerability handling into incident response. Isolation, evidence preservation, process analysis and secret rotation should precede a routine retest.

This split avoids two common mistakes: raising an emergency against every host containing Erlang, and declaring a listener safe merely because it is not Internet-facing while it remains accessible from a compromised workload or user network.

Remediating CVE-2025-32433

The update depends on the deployed branch:

OTP 27: 27.3.3 or later;
OTP 26: 26.2.5.11 or later;
OTP 25: 25.3.2.20 or later.

The corresponding fixed ssh applications are 5.2.10, 5.1.4.8 and 4.15.3.12. The OTP 27.3.3 patch page confirms the release details.

When Erlang is embedded in a vendor appliance, use the vendor’s supported update and instructions. Replacing a library manually may break signatures, dependencies or support. Until an update is available, the official workaround is to disable the SSH server or block access with firewall policy. Limiting access to dedicated management hosts materially reduces risk but is not a permanent fix.

Hardening the blast radius

Keep defence-in-depth controls after updating so that a future flaw in an administrative service has fewer consequences:

allow traffic only from explicitly defined management hosts and enforce policy in both directions;
run BEAM as a non-administrative account without unnecessary capabilities or access to the container runtime socket;
mount only required volumes and secrets, using a read-only filesystem where the product supports it;
restrict egress to named dependencies instead of permitting general access to internal networks and the Internet;
record the owner, version and business justification for every administrative listener;
test segmentation from the Internet, VPN, user networks and cloud workloads.

The AWS, Azure and GCP cloud penetration testing guide covers practical network-path validation. In on-premises environments, an internal network segmentation penetration test serves the same purpose when run from representative source zones. Hardening does not convert a vulnerable version into a fixed one, but it can reduce both initial reachability and onward movement from a compromised process.

Detection and compromise assessment

Focus monitoring on pre-authentication traffic and host behaviour:

unusual SSH packet sequences that do not include normal login;
brief connections from many addresses and scanning of non-standard ports;
child processes created by BEAM or the service account;
operating-system commands unrelated to the application’s function;
new files, users, authorised keys and scheduled tasks;
outbound traffic from hosts that normally only answer requests;
repeated protocol errors immediately before a process anomaly.

The absence of a “successful login” event does not exclude exploitation because authentication is the boundary being bypassed. When compromise is suspected, preserve memory and logs, isolate the host, rotate exposed credentials and examine systems reachable by the service account.

There is no single universal IOC that proves exploitation of CVE-2025-32433. After key exchange, SSH payload content is protected, so NetFlow, byte counts or a short session alone will not reveal which protocol message the server processed. Network telemetry can establish the source, time and frequency of connections; host evidence should come from the BEAM process, operating-system audit logs, EDR, file changes and outbound connections.

Fixed code may produce an event corresponding to “Unexpected message for unauthenticated user” before disconnecting the client. That is a useful signal of a protocol-state violation against a patched server, but it is not proof of successful RCE. Log format in older builds may depend on the product and configuration, so the absence of that text does not establish safety.

The minimum triage dataset should include connection time and source, the target listener, OTP and ssh versions, BEAM process identity, child processes, command-execution events, changes in writable directories, secret access and egress in the same time window. Correlating these layers is substantially more reliable than a single network signature.

Remediation verification and retesting

Closing the finding after updating an image is not enough. A retest should confirm, in order:

the precise OTP and ssh application versions loaded by the running process;
restart of every replica, cluster node and appliance instance that used the old code;
normal operation of authorised login and required administrative functions;
rejection of the invalid state transition in an isolated regression test, with no child process, file creation or outbound connection;
effective firewall policy from every zone that should lack access;
expected telemetry and no evidence of earlier compromise.

Run the negative test in a lab or a dedicated staging instance. Production verification can rely on evidence of the version, restart, configuration and reachability. For a vendor product, the final criterion is its supported fixed package, not only a system Erlang version visible outside the appliance. The same evidence trail for versions, exposure and retesting should become part of the permanent vulnerability management process.

Why the CVSS 10.0 score fits

The vector describes a low-complexity network attack with no privileges or interaction, high confidentiality, integrity and availability impact, and a changed security scope. Business context should reduce priority only when the Erlang SSH server is not running or is genuinely unreachable from untrusted zones. A port being “internal” is not enough.

Organisations operating non-standard services should combine CVSS priority with actual reachability and process privileges. An authorised infrastructure penetration test can validate whether management services are actually isolated without destructive RCE.