No OT Authentication Required: Understanding the Erlang SSH Vulnerability

OT security professionals should be aware of a significant new vulnerability that has emerged in 2025. CVE-2025-32433 has been identified as a critical vulnerability in Erlang/OTP's SSH implementation, receiving the highest possible severity rating of 10.0 on the CVSS scale.

The severity of this vulnerability stems from its ability to allow unauthorized code execution without requiring authentication. This represents a fundamental security breach - no credentials are needed and no complex exploitation techniques are required for an attacker to execute arbitrary code on affected systems.

What makes this particularly concerning is Erlang's widespread deployment across critical infrastructure and operational technology environments. According to Cisco data, approximately 2 million devices with Erlang are shipped annually (link). The technology is deeply embedded in our digital infrastructure, with reports indicating that roughly 90% of internet traffic passes through Erlang-controlled nodes. The eight largest service providers worldwide utilize Erlang-based systems for network control, and the eight leading Network Equipment Providers incorporate Erlang-based components in their products.

This vulnerability therefore represents a potential threat not to a niche technology, but to essential components of our national digital infrastructure.

The Technical Nitty-Gritty

For my fellow technical enthusiasts who want to understand exactly what's happening under the hood, let's break down the exploit.

The vulnerability exists because Erlang's SSH implementation doesn't properly enforce the SSH protocol sequence. Normally, SSH requires strict authentication before allowing any channel operations. This vulnerability allows attackers to bypass this by sending channel operation messages before authentication completes.

A typical exploit flow looks like this:

  1. Connect to the SSH server and exchange banners
  2. Send an SSH_MSG_KEXINIT packet (begins key exchange)
  3. Skip authentication entirely (yikes!)
  4. Send SSH_MSG_CHANNEL_OPEN to open a session
  5. Send SSH_MSG_CHANNEL_REQUEST with an "exec" command
  6. Profit (or wreak havoc, depending on which side you're on)

Lets walk through the actual exploit code to give you a clear idea of what's happening:

The attack starts with a simple TCP connection to the target's SSH port. After exchanging SSH banners, the attacker sends a seemingly legitimate SSH_MSG_KEXINIT packet to begin key exchange. This keeps the server happy and engaged.

The critical weakness emerges in the next step - instead of completing authentication, the attacker jumps straight to sending SSH_MSG_CHANNEL_OPEN followed by SSH_MSG_CHANNEL_REQUEST with an arbitrary command. The Erlang SSH server, not properly checking the protocol state, executes this command without requiring authentication!

Existing proof-of-concept code attempts to write a file called "lab.txt" with the content "pwned" - a relatively benign payload. However, attackers could easily replace this with commands to establish persistence, exfiltrate data, or disrupt operations.

OT Impact: This Is Where It Gets Scary

Now let's talk about what this means for Operational Technology environments. OT systems are notoriously difficult to patch and often run critical processes that can't tolerate downtime. Many OT networks still operate with the "air gap" mentality, even though true isolation is increasingly rare.

The Erlang SSH vulnerability poses particular concerns for OT for several reasons:

  1. High prevalence in industrial control systems: As the Cisco data shows, Erlang is widely used in networking equipment that forms the backbone of many OT environments.
  2. Remote accessibility: Many organizations have increased remote access to OT networks since 2020, often using SSH for secure connections. This vulnerability turns that security measure into an attack vector.
  3. Privilege escalation: If the SSH daemon is running as root (common in many deployments), attackers gain complete control of the device.
  4. Supply chain implications: With Erlang present in countless embedded systems and network devices from major vendors like Cisco and Ericsson, the vulnerability potentially affects devices throughout the supply chain.

The consequences could be severe - from unauthorized access to sensitive industrial systems to complete disruption of critical infrastructure operations. Imagine an attacker gaining control of telecommunications equipment during an emergency, or manipulating industrial processes in manufacturing facilities.

What Should You Do?

If you're responsible for OT security, here's your action plan:

  1. Identify affected systems: Scan your networks (especially ones touching the Internet) for devices running Erlang/OTP SSH servers.
  2. Update immediately: Upgrade to versions OTP-27.3.3, OTP-26.2.5.11, or OTP-25.3.2.20 as recommended.
  3. Apply firewall rules: As a temporary mitigation, restrict SSH access to absolutely essential users and sources.
  4. Monitor for exploitation: Watch for unusual SSH connections or unexpected command execution.
  5. Engage with vendors: Contact your equipment providers to understand their patch timelines for affected devices.

Final Thoughts

While it's tempting to downplay the seriousness of yet another vulnerability (we've all got alert fatigue, right?), this one deserves your attention. With its perfect CVSS score and widespread impact potential, CVE-2025-32433 ranks among the most significant vulnerabilities of 2025 so far.

The good news? Patches are available. The bad news? Many affected systems are in environments where patching is challenging, time-consuming, or disruptive to critical operations.

So patch if you can, mitigate if you must, and remember - in the world of OT security, being paranoid isn't a disorder, it's a job requirement.

Stay safe out there!