Vulnerability Analysis

Erlang/OTP SSH CVE-2025-32433: Unauthenticated RCE Scoring 10.0

A maximum-severity vulnerability in Erlang/OTP's SSH server allowed unauthenticated remote code execution. Any system running Erlang's built-in SSH daemon was at risk, including telecom infrastructure.

Alex
Cloud Security Specialist
5 min read

On April 16, 2025, researchers at Ruhr University Bochum disclosed CVE-2025-32433, a critical vulnerability in Erlang/OTP's SSH server implementation. The vulnerability received the maximum CVSS score of 10.0 and allowed unauthenticated remote code execution on any system running Erlang's built-in SSH daemon.

The implications were significant because Erlang/OTP is the foundation of critical telecommunications infrastructure, messaging systems, and distributed databases. Products built on Erlang, including RabbitMQ, CouchDB, and numerous telecom switching systems, were potentially affected if they exposed Erlang's SSH server.

The Vulnerability

CVE-2025-32433 was a protocol handling flaw in Erlang/OTP's SSH server. The vulnerability allowed an attacker to send SSH protocol messages before authentication was completed. Specifically, the SSH server failed to properly enforce the protocol state machine, allowing channel request messages (which should only be processed after authentication) to be sent and processed during the pre-authentication phase.

By sending crafted SSH messages in an unexpected order, an attacker could execute arbitrary Erlang functions on the server without authenticating. If the SSH daemon was running as root (which is common for SSH servers that need to bind to port 22), the attacker gained root-level code execution.

The affected versions were:

  • OTP-27.x before OTP-27.3.3
  • OTP-26.x before OTP-26.2.5.11
  • OTP-25.x before OTP-25.3.2.20
  • All earlier versions (unsupported, no patches available)

Why Erlang/OTP Matters

Erlang may not have the name recognition of Python or Java among general software developers, but it underpins a remarkable amount of critical infrastructure:

Telecommunications. Erlang was created by Ericsson for telephone switching systems. It remains widely used in telecom infrastructure. If you have made a phone call or sent a text message, Erlang code was almost certainly involved in routing it.

Messaging systems. RabbitMQ, one of the most popular message brokers, is built on Erlang/OTP. WhatsApp's backend was famously built on Erlang, handling millions of concurrent connections.

Databases. CouchDB and Riak are built on Erlang. These databases are used in applications requiring high availability and distributed operation.

IoT and embedded systems. Erlang's lightweight process model makes it suitable for IoT gateway devices and embedded controllers.

Financial services. Several financial trading platforms and payment processing systems use Erlang for its fault-tolerance characteristics.

The SSH server in Erlang/OTP is not a general-purpose SSH server like OpenSSH. It is a library component that Erlang applications can use to provide SSH access for administration, debugging, or remote shell capabilities. Many Erlang-based systems enable the SSH server for operational management, sometimes without fully considering its security implications.

Exploitation Difficulty

The vulnerability was straightforward to exploit once the mechanism was understood. Within days of the disclosure, proof-of-concept exploit code appeared on GitHub. The exploit required only the ability to reach the Erlang SSH port (typically 22, but often configured on alternative ports for application-specific SSH servers).

The key factors that made exploitation easy:

  • No authentication required. The entire point of the vulnerability was that it allowed pre-authentication command execution.
  • No complex payload construction. The attacker could call arbitrary Erlang functions, including os:cmd/1 which executes operating system commands.
  • Reliable exploitation. Unlike memory corruption bugs that may depend on specific memory layouts, this was a logic flaw that worked consistently.

The primary limiting factor was that the target needed to be running Erlang's SSH server, not just any SSH server. Systems running OpenSSH were not affected. But for organizations running Erlang-based infrastructure, the risk was immediate.

Detection and Response

Detecting exploitation attempts required monitoring SSH server logs for protocol anomalies. Specifically:

  • SSH connection attempts that send channel requests before completing authentication.
  • Connections that do not follow the normal SSH protocol handshake sequence.
  • Unusual process spawning from the Erlang runtime, particularly os:cmd calls executing shell commands.

For organizations running Erlang-based systems:

  1. Identify all systems running Erlang/OTP SSH servers. This may include systems you do not think of as "SSH servers" -- any Erlang application that includes the ssh application in its dependency tree might be running an SSH listener.
  2. Update to patched OTP versions (27.3.3, 26.2.5.11, or 25.3.2.20).
  3. If patching is not immediately possible, restrict network access to the Erlang SSH port. Use firewall rules to limit access to trusted management IPs.
  4. Disable the SSH server if it is not required for your application's operation. Many Erlang applications enable SSH for debugging convenience and do not actually need it in production.
  5. Audit for compromise if the SSH server was exposed to untrusted networks before the patch was applied.

The Hidden Dependency Problem

CVE-2025-32433 highlighted a challenge that Safeguard.sh was built to address: vulnerabilities in runtime platforms and framework libraries that application developers do not think about.

A development team building a service on RabbitMQ might not know or care that RabbitMQ is built on Erlang, or that Erlang's SSH server is available as a library component. The vulnerability is not in their code or their direct dependencies -- it is in the platform underneath their dependencies.

This is why SBOM-driven vulnerability management matters. A comprehensive SBOM captures not just your application's direct dependencies, but the entire stack down to the runtime. When a vulnerability is found in Erlang/OTP, you need to know which of your systems are built on Erlang, even if "Erlang" never appears in your application's package.json or requirements.txt.

How Safeguard.sh Helps

Safeguard.sh excels at exactly this kind of deep dependency tracking. By generating and analyzing comprehensive SBOMs for your deployments, Safeguard identifies the full dependency tree, including runtime platforms like Erlang/OTP that sit beneath your application's direct dependencies.

When CVE-2025-32433 was disclosed, Safeguard users with Erlang-based systems in their inventory received immediate alerts, even if their primary application was "a RabbitMQ deployment" rather than "an Erlang application." This kind of deep visibility is the difference between responding to a critical vulnerability in hours versus discovering months later that you were exposed.

Safeguard's policy gates can also enforce minimum runtime versions, ensuring that Erlang/OTP (and other runtime platforms) stay current across your infrastructure.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.