CVE-2025-32433: Unauthenticated RCE Vulnerability in Erlang/OTP’s SSH Implementation

Key Takeaways

• A critical vulnerability has been discovered in Erlang/OTP, tracked as CVE-2025-32433,  and has a CVSS score of 10 (critical). 
• This critical remote code execution (RCE) vulnerability affects the SSH server within the Erlang/OTP software platform.
• This vulnerability allows unauthenticated attackers to gain full system access by sending crafted SSH packets before any login or credentials are provided. 
• Systems running Erlang/OTP’s native SSH server are at risk and may be embedded in telecom, IoT, cloud platforms, databases, etc.
• We recommend patching impacted systems immediately. 

Background

A critical vulnerability, tracked as CVE-2025-32433, has been discovered in the SSH server component of Erlang/Open Telecom Platform (OTP). This vulnerability is an unauthenticated remote code execution (RCE) vulnerability, disclosed on April 16, 2025. It has a maximum CVSS v3 score of 10.0, indicating the highest severity. The flaw could allow an unauthorized threat actor with access to an Erlang/OTP-based SSH service to execute arbitrary code without supplying any credentials. If exploited, a threat actor could compromise the target system simply by initiating an SSH connection and sending malicious data, even before authentication completes. If the Erlang/OTP SSH daemon operates with elevated privileges, such as root, successful exploitation could grant a threat actor full control over the affected system.

One Malformed SSH Handshake

The vulnerability resides in the SSH handshake message handling of Erlang/OTP’s built-in SSH server. According to the SSH protocol specification (RFC 4252 §6), certain message types (with IDs ≥ 80) are reserved for stages after user authentication. If an SSH client attempts to send such messages before authentication, a compliant server must immediately disconnect the session. The vulnerability was discovered by a team of researchers at Ruhr University Bochum (Fabian Bäumer, Marcus Brinkmann, Marcel Maehren, and Jörg Schwenk) and responsibly disclosed it. Official advisories were published via the Openwall mailing list and the Erlang/OTP GitHub repository on April 16, 2025. 

What Went Wrong in Erlang/OTP

In affected versions of Erlang/OTP, the SSH daemon fails to enforce this rule and the server does not disconnect when receiving disallowed messages early. This oversight in state management means that a threat actor could inject messages intended for post-authentication phases during the unauthenticated handshake. The server would mistakenly accept and process them as if the client were already authenticated. 

In practical terms, a threat actor can perform a pre-auth channel hijack. Proof of concept code has been reviewed and identified as sending a channel open request to initiate an SSH session, then immediately sending a channel request carrying a payload (e.g., a command to execute) before any login. Vulnerable Erlang/OTP SSH servers lack the check to reject this type of command so they proceed to open the channel and execute the requested command with the privileges of the SSH service. The entire exploit can occur during the handshake, without any valid username or key.

Note: The root cause was a missing condition in the ssh_connection:handle_msg function of the Erlang/OTP SSH library. The patch introduced a check to detect message IDs ≥ 80 sent while authenticated = false and to immediately terminate the connection if encountered. In other words, the fix ensures the server “hard stops” any out-of-order message sequences during authentication, as the protocol intends.

Security researchers have described this bug as surprisingly trivial to exploit. Horizon3.ai’s attack team reproduced the exploit within a day and noted it was "surprisingly easy" to craft a working attack. Memory corruption is not required. The flaw is a logic mistake that a threat actor can leverage to directly execute commands. Public proof-of-concept (PoC) exploits emerged shortly after disclosure, demonstrating how a threat actor can, for instance, create a file on the server as root via a single malformed SSH handshake. Given the simplicity, experts warned that mass exploitation “in the wild” is likely imminent.

VMware products and versions that are end-of-life have not been included in the Broadcom advisory and will not have security patches released. As such, end-of-life versions of impacted products may also have these vulnerabilities. Cybereason recommends that related products be upgraded to supported versions that are eligible to receive critical security updates.

Impact: What an Attack Enables

The consequences of CVE-2025-32433 are potentially severe because it grants code execution before authentication allowing a threat actor to effectively become an unauthorized system admin on the target device.

• Full System Compromise: Any command the threat actor sends will run with the privileges of the SSH service process. In many Erlang/OTP deployments, the SSH daemon runs as root, so the threat actor gains absolute control. They can create or modify files, install malware, add new user accounts, or run arbitrary programs. For example, researchers noted a threat actor could install ransomware or steal sensitive data after exploiting this flaw.
• Silent, No-Auth Break-in: Because no valid credentials or user interaction are needed, the attack can happen with no warning signs, like failed logins. It’s a pre-auth compromise that may not trigger usual authentication logs. Initial intrusion can leave minimal traces. 
  
• Lateral Movement & Pivoting: Once in, threat actors can use the compromised system as a beachhead. In corporate networks, a breached Erlang/OTP service could be used to pivot deeper, probe internal systems, or exfiltrate data.
• Denial of Service or Sabotage: A threat actor could simply crash the device or stop critical services after gaining access. In high-availability systems (telecom switches, messaging servers, etc.), this could lead to service outages and downtime. Erlang’s reputation for fault tolerance is undermined if an outsider can arbitrarily kill processes or overload the system with malicious tasks.
  

Real-world exploitation of this vulnerability could facilitate attacks ranging from ransomware deployment to critical infrastructure sabotage. For instance, a telecom core router running Erlang could be made to shut down or reroute traffic, causing network disruption. An IoT sensor network could be turned against itself to feed false data or become part of a botnet. The breadth of impact depends on where Erlang/OTP’s SSH is used (as we explore next), but wherever it appears, the outcome of an exploit is a complete host takeover. 

Affected Systems and Platforms “Am I affected?”

If you run an SSH server built on Erlang/OTP, assume yes. The original advisory makes clear that all versions of Erlang/OTP’s SSH prior to the fixed releases are vulnerable. This is not tied to a specific operating system or device; it’s about the SSH library in Erlang’s platform. Any software or firmware that includes Erlang/OTP’s SSH component could be exposed. Here are known/notable examples of where Erlang/OTP is used:

Telecom and Network Appliances
Erlang has become a popular language for building fault-tolerant, distributed systems in a wide range of industries, including web applications, cloud computing, and financial services. Cisco’s network management systems (like the Tail-f ConfD engine embedded in routers) are built on Erlang/OTP. These systems often provide SSH-based admin consoles, which likely rely on OTP’s SSH implementation. Ericsson’s carrier-grade telecom switches (such as the AXD 301, famous for 9-nines reliability) run millions of lines of Erlang.

IoT and Industrial Control Systems
Erlang/OTP is favored in some internet of things (IoT) and operational technology (OT) solutions for its concurrency and reliability. It’s found in industrial automation controllers, smart sensors, and edge computing gateways. For instance, the open-source Nerves Project provides an embedded Elixir/Erlang platform for IoT devices and it uses OTP’s SSH to allow developers to remotely shell into devices. By default, a Nerves device will start an SSH server on port 22 (using Erlang’s :ssh), providing an IEx console and file transfer capabilities. This is a convenient feature, but with CVE-2025-32433, it could become an attack vector. Any IoT gadget or industrial controller exposing an Erlang-based SSH (whether for debugging or remote management) could be taken over completely by a network-based attacker. Consider smart meters, PLCs, or security cameras running Erlang/OTP software. They might be small, but if compromised, they can pose security risks (e.g., spying, sabotage, botnet recruitment, DDoS swarm recruitment, etc.).

Enterprise Software and Cloud Services
Erlang/OTP is the backbone of several widely-used software platforms:

• Message Brokers and Queues: RabbitMQ is a popular message queue that is “written in Erlang/OTP” and often deployed in cloud-native environments. By default RabbitMQ doesn’t require an SSH server for operation, but administrators sometimes enable the embedded Erlang SSH to get a remote shell or use features like distribution clustering. RabbitMQ is built on the Open Telecom Platform framework for clustering and failover purposes. Any RabbitMQ instance (or similar Erlang-based service) that has its OTP SSH interface enabled on a network-accessible port is vulnerable due to this CVE. In cloud deployments, this could be especially dangerous if not behind a firewall as an attacker could target RabbitMQ nodes in Kubernetes or VM clusters to seize control of message flow or pivot into the cloud environment.
• Databases and Distributed Stores: Apache CouchDB and the former Riak KV database are implemented in Erlang/OTP. These typically expose HTTP interfaces, not SSH, to clients. However, for maintenance or clustering, an Erlang SSH server might be running (for example, CouchDB can be configured to allow an Erlang remote shell). If so, that interface would be at risk. Even if the OTP SSH isn’t exposed externally, the presence of the vulnerability means an insider or lateral mover in the network could use it to escalate privileges on the DB server.
• Messaging and Chat Systems: The backend of WhatsApp is built on Erlang/OTP. While end-users don’t directly connect via SSH, the WhatsApp server infrastructure may have Erlang remote console capabilities for engineers. Facebook (Meta) would need to ensure any such internal management ports are patched. Similarly, XMPP chat servers like Ejabberd or MongooseIM run on Erlang; by default Ejabberd does not appear to enable the OTP SSH daemon for admin, but if any admin enabled it, those servers would be vulnerable.

Operating Systems and Distributions

Erlang is not an OS by itself, but it does come packaged in many Linux distributions. For example, Ubuntu, Debian, and others ship Erlang/OTP runtime for users. If any local applications or services on a server utilize the OTP SSH (instead of OpenSSH), they’d be affected. It is worth noting that Cybereason Consulting experts have reviewed the associated documentation and have not found any evidence that the CVE impacts the common OpenSSH daemon. The CVE is specific to Erlang’s SSH implementation. Ubuntu tagged this CVE “High” priority and released updates for supported versions within a day. Admins should ensure the OS-provided Erlang is updated especially if running services like the above on those machines.

Analogy

Imagine a locked building with security staff at a front desk. Normally, when someone walks in, they are required to check in with security, show their ID for verification, and receive a visitor badge before being allowed access to any rooms or offices within the building. Now imagine that anyone who walks in and says “I have a meeting in Conference Room A” is automatically granted access by security. Security unlocks the door without verifying their identity or whether they actually have a meeting. Security treats the request as valid simply because it was phrased like a legitimate request. That’s CVE-2025-32433 in a nutshell.

Guidance

• Restrict network access: Use firewall rules or security groups to limit which IP addresses can reach the SSH port.
• Disable the SSH server: If the Erlang/OTP SSH functionality is not mission-critical, consider turning it off until you can patch.
• Containment: Ensure the Erlang node can only be accessed from a secure management network or VPN.

• Proactively create threat hunts for any signs that this vulnerability has been targeted in your environment.
• Monitor for abnormal SSH traffic or connections with no associated login events.
• Check for system commands executed by the erlang or beam.smp process outside of expected contexts.
• Audit logs for recent unexpected file creation or service disruptions on or about the time of the CVE becoming public.
• Since exploitation might not leave obvious auth failure logs, look for unexpected SSH connections or odd commands executed by the Erlang VM.
• Increase the verbosity of logging if available. The patch will cause the server to log an error and disconnect if someone attempts the attack.

Recommendations

Below are some key recommendations from the Cybereason DFIR team:
As with most CVEs, patching is the top priority. The Erlang/OTP maintainers have released fixes in several patch versions:

These releases implement the protocol check to properly reject out-of-order messages and stop the exploit. If you obtain Erlang/OTP from a system package manager, look for these version numbers. Ubuntu backported the fix to its Erlang 24 and 22 packages with new build revisions. If you use a vendor-supplied Erlang/OTP (embedded in another product), then you should monitor advisories from that vendor. Companies like Cisco or Ericsson that ship Erlang within their products should issue updates aligning with the above versions. 

About the Author

Devon Ackerman, Global Head of DFIR, Cybereason

Devon Ackerman is the Global Head of DFIR at Cybereason. Devon leverages over 15 years of experience in the cybersecurity industry, with a focus on Digital Forensics and Incident Response. He has built, managed, and led large global incident response teams, and has worked hundreds of incident response engagements, including some of the most complex in the world.