CVE-2025-32433

What it actually does

This vulnerability affects the Erlang/OTP SSH server implementation and allows unauthenticated remote code execution through improper handling of SSH protocol messages before normal authentication is completed. A network-reachable attacker can interact with the Erlang SSH service, trigger flawed pre-authentication message handling, and cause attacker-controlled code or commands to execute in the context of the Erlang VM or the operating system account running the affected service. The issue is fixed in OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20, and in the Erlang/OTP Git repository at commit 10e20b1dbe39b056fab430e50b08cb4f3696ae87.

Why it matters to the business

A vulnerable Erlang/OTP SSH service exposed to untrusted networks can be fully compromised without valid credentials. Successful exploitation may allow attackers to take over application servers, steal secrets, modify data, deploy malware, pivot to internal systems, or disrupt services. The risk is especially urgent because the vulnerability is in the CISA Known Exploited Vulnerabilities catalog, has active in-the-wild exploitation, has a very high EPSS probability, and the federal remediation deadline was 2025-06-30. Any internet-accessible Erlang/OTP SSH listener should be treated as a high-priority exposure until patched or isolated.

How an attack unfolds

An attacker first identifies a host running an Erlang/OTP-based SSH server, commonly by scanning for SSH banners or probing known management, embedded, messaging, telecom, or application ports that use Erlang SSH rather than OpenSSH. The attacker then establishes an SSH session and sends a crafted sequence of protocol messages that abuses the server-side message handling flaw before authentication succeeds. Because the vulnerable code path incorrectly permits a critical action prior to credential validation, the attacker can cause arbitrary command execution without knowing a username, password, private key, or Erlang cookie. After gaining execution, the attacker typically runs reconnaissance commands, retrieves environment variables and secrets, drops tooling, creates persistence, and may pivot to other systems accessible from the compromised service account. Public reporting tracks this issue as actively exploited in the Q2/H1 2025 vulnerability landscape, though no specific named actor attribution is required to justify urgent remediation.

How to fix it

Upgrade Erlang/OTP immediately to a fixed release: OTP-27.3.3 or later, OTP-26.2.5.11 or later, or OTP-25.3.2.20 or later. For source-based builds, ensure the Erlang/OTP code includes commit 10e20b1dbe39b056fab430e50b08cb4f3696ae87 or a later vendor release containing the fix. Restart all services embedding or dynamically linking the affected Erlang/OTP SSH implementation after patching; rebuilding applications may be required where Erlang/OTP is bundled into an appliance, container image, embedded runtime, or statically packaged release. If immediate patching is not possible, disable the Erlang/OTP SSH server, bind it only to localhost or a trusted management network, block external access with firewalls/security groups, and require VPN or bastion access. Do not rely on credential rotation alone because exploitation does not require valid credentials.

How to confirm the fix worked

Confirm the installed Erlang/OTP version is OTP-27.3.3+, OTP-26.2.5.11+, or OTP-25.3.2.20+ by checking runtime and package metadata, for example using erl -eval 'erlang:display(erlang:system_info(otp_release)), halt().' -noshell and vendor package inventory. Verify that all deployed containers, appliances, application bundles, and build artifacts use a fixed Erlang/OTP runtime, not only the base host package. Confirm that any Erlang/OTP SSH listeners are either patched or inaccessible from untrusted networks by reviewing service configuration, firewall rules, cloud security groups, and network scans. Validate that services were restarted after upgrade by checking process start times and loaded runtime paths. If mitigation rather than patching is used, test that the Erlang SSH port is closed or reachable only from approved administrative sources.

Typical attack path

1. Scan the internet or internal ranges for SSH services that appear to be Erlang/OTP SSH rather than OpenSSH.
2. Connect to the exposed Erlang/OTP SSH listener and fingerprint the service version or behavior.
3. Send crafted SSH protocol messages that reach the vulnerable pre-authentication handling path.
4. Trigger unauthenticated command or code execution in the context of the Erlang VM service account.
5. Run initial discovery commands such as identity, hostname, network, process, and environment enumeration.
6. Access application secrets, configuration files, credentials, tokens, or Erlang runtime data available to the service.
7. Deploy follow-on tooling, persistence, reverse shells, or malware, and attempt lateral movement to adjacent systems.

How to detect it

Investigate hosts that ran vulnerable Erlang/OTP SSH services before patching or isolation. Collect Erlang application logs, SASL/crash logs, systemd/journald output, container stdout/stderr, EDR process telemetry, shell history for the service account, network flow logs, firewall logs, and packet captures where available. Look for bursts of SSH connections that terminate before authentication, malformed or unusual SSH packet handling errors, Erlang SSH handler crashes, and connections from unfamiliar internet sources. Because exploitation results in code execution from the Erlang VM, high-fidelity evidence includes unexpected child processes spawned by beam.smp or erl, such as /bin/sh, bash, curl, wget, python, perl, nc, socat, chmod, crontab, or systemctl. Review newly created files in temporary directories, modified cron jobs, new SSH authorized_keys entries, unexpected system users, reverse-shell activity, outbound connections immediately after inbound SSH probes, and access to secrets or configuration files by the Erlang service account. If threat hunting across historical data, prioritize the period since publication on 2025-04-16 and any time before installation of the fixed OTP release.

• beam.smp -> /bin/sh
• beam.smp -> /bin/bash
• beam.smp -> curl
• beam.smp -> wget
• beam.smp -> nc
• beam.smp -> ncat
• beam.smp -> socat
• beam.smp -> python
• beam.smp -> perl
• beam.smp -> chmod
• beam.smp -> crontab
• beam.smp -> systemctl
• erl -> /bin/sh
• erl -> /bin/bash
• ssh_connection_handler
• ssh_transport
• Protocol error
• Connection closed before authentication
• userauth
• /tmp/.ssh/authorized_keys
• /var/tmp/.ssh/authorized_keys
• /dev/shm/
• /tmp/.X11-unix/
• /etc/cron.d/
• /var/spool/cron/
• ~/.ssh/authorized_keys

What your security team should do

• Treat internet-exposed Erlang/OTP SSH services as emergency-priority assets because the vulnerability is KEV-listed, actively exploited, and has very high EPSS likelihood.
• Inventory all Erlang/OTP deployments, including containers, embedded products, appliances, CI/CD images, messaging platforms, telecom systems, and custom applications that enable the Erlang SSH server.
• Patch to OTP-27.3.3+, OTP-26.2.5.11+, or OTP-25.3.2.20+; for Git builds verify inclusion of commit 10e20b1dbe39b056fab430e50b08cb4f3696ae87.
• Immediately disable or firewall Erlang/OTP SSH listeners that cannot be patched, especially any reachable from the internet or broad internal networks.
• Hunt for prior exploitation on systems that exposed Erlang/OTP SSH before remediation, focusing on pre-authentication SSH anomalies and unexpected child processes spawned by the Erlang VM.
• Rotate secrets, API tokens, Erlang cookies, SSH keys, and application credentials accessible to the Erlang service account if compromise is suspected.
• Add network monitoring for Erlang/OTP SSH exposure and alert on new or unexpected SSH listeners running from Erlang-based services.