CVE-2025-46712

Executive Summary

CVE-2025-46712 is a medium-severity vulnerability in Erlang/OTP's SSH implementation. The flaw allows a Man-in-the-Middle (MitM) attacker to inject optional messages during the SSH key exchange (KEX) handshake due to insufficient hardening measures. This can lead to downgrade attacks or manipulation of the handshake state, potentially weakening the security of the SSH session. The vulnerability affects all versions prior to the patched releases for OTP-27, OTP-26, and OTP-25. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk is elevated for environments where MitM attacks are feasible.

Supply Chain & Package Security

Erlang/OTP is a core dependency for many Elixir and Erlang applications. This vulnerability can be introduced through package managers like Hex.pm. Organizations using Erlang/OTP in their supply chain should verify the version of OTP in their base images and dependencies. A compromised SSH handshake could lead to session hijacking or data manipulation in transit.

CVSS Breakdown & Threat Level

• CVSS Score: 3.7 (Low)
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
• Attack Vector: Network
• Attack Complexity: High (requires MitM position)
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low
• Availability Impact: None

Threat Level: Low. Exploitation requires an active MitM position and high attack complexity. The impact is limited to integrity compromise of the handshake.

Deep Dive & Mechanics

The SSH protocol defines a key exchange (KEX) handshake that negotiates cryptographic parameters. During this handshake, optional messages (e.g., SSH_MSG_KEX_DH_GEX_REQUEST_OLD, SSH_MSG_IGNORE) can be exchanged. In vulnerable versions of Erlang/OTP, the SSH implementation does not enforce strict ordering or validation of these optional messages. A MitM attacker can inject crafted messages to:

1. Downgrade the key exchange algorithm.
2. Manipulate the handshake state to weaken session keys.
3. Potentially force the use of weaker cryptographic primitives.

The vulnerability lies in the ssh_kex.erl module, where optional messages are processed without proper state machine hardening. The fix involves rejecting unexpected optional messages during the KEX phase.

Vulnerable vs. Patched Code

Vulnerable Code (simplified from ssh_kex.erl):

handle_msg({ssh_cm, _Connection, #ssh_msg_kexdh_init{}} = Msg, State) ->
    % Process optional messages without validation
    case Msg of
        #ssh_msg_ignore{} -> ok;
        _ -> handle_kex_init(Msg, State)
    end.

Patched Code:

handle_msg({ssh_cm, _Connection, #ssh_msg_kexdh_init{}} = Msg, State) ->
    % Reject unexpected optional messages during KEX
    case Msg of
        #ssh_msg_ignore{} -> {error, unexpected_msg};
        _ -> handle_kex_init(Msg, State)
    end.

The patch adds explicit rejection of SSH_MSG_IGNORE and other optional messages during the KEX handshake, preventing injection.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Attacker must be in a MitM position (e.g., ARP spoofing, rogue access point).
• Target must run a vulnerable Erlang/OTP SSH server.

Exploitation Steps:

1. Intercept the SSH handshake between client and server.
2. Inject an SSH_MSG_IGNORE message during the KEX phase.
3. Observe the handshake state manipulation (e.g., algorithm downgrade).

Proof-of-Concept (Python using Scapy):

from scapy.all import *
import struct

def inject_ssh_msg_ignore(pkt):
    if pkt.haslayer(TCP) and pkt[TCP].dport == 22:
        # Craft SSH_MSG_IGNORE (ID 2)
        ignore_msg = struct.pack('!B', 2) + b'\x00\x00\x00\x04' + b'AAAA'
        # Inject into the TCP stream (simplified)
        pkt[TCP].payload = ignore_msg + bytes(pkt[TCP].payload)
        return pkt
    return pkt

# Use in a MitM scenario (e.g., with arpspoof)
# This is a conceptual example; actual injection requires stream reassembly.

Note: No public exploit code exists. The above is a conceptual demonstration.

Blue Team

Detection:

• Monitor for unexpected SSH_MSG_IGNORE messages during KEX.
• Use network flow analysis to detect MitM positioning (e.g., ARP anomalies).

Hunting:

• Search for SSH handshake logs with unusual message sequences.
• Check for downgrade of key exchange algorithms in session logs.

Indicators of Compromise (IOCs)

• Network: SSH packets containing SSH_MSG_IGNORE (type 2) during KEX phase.
• Logs: SSH debug logs showing unexpected_msg errors (after patching).
• System: Unusual ARP table entries (for MitM detection).

Detection Engineering

YARA Rule

rule CVE_2025_46712_SSH_KEX_Injection {
    meta:
        description = "Detects SSH KEX handshake with injected optional messages"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-46712"
    strings:
        $ssh_msg_ignore = { 02 00 00 00 ?? }  // SSH_MSG_IGNORE with length
        $kex_init = { 14 }  // SSH_MSG_KEXINIT
    condition:
        $ssh_msg_ignore and $kex_init
}

Sigma Rule

title: CVE-2025-46712 SSH KEX Optional Message Injection
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects SSH handshake with injected optional messages
author: Valters IT
logsource:
    category: network_connection
    product: suricata
detection:
    selection:
        event_type: alert
        alert.signature_id: 3000001
    condition: selection
falsepositives:
    - Legitimate use of SSH_MSG_IGNORE (rare)
level: medium

Suricata Rule

alert tcp any any -> any 22 (msg:"CVE-2025-46712 SSH KEX Optional Message Injection"; flow:to_server,established; content:"|02 00 00 00|"; depth:4; within:10; content:"|14|"; distance:0; within:5; sid:3000001; rev:1;)

Remediation & Mitigation

1. Patch Immediately: Upgrade to OTP-27.3.4, OTP-26.2.5.12, or OTP-25.3.2.21.
2. Network Segmentation: Limit SSH access to trusted networks to reduce MitM risk.
3. Enable Strict KEX: Configure SSH to reject optional messages (if possible).
4. Monitor: Deploy the provided detection rules to identify exploitation attempts.
5. Compensating Controls: Use VPNs or IPsec to encrypt SSH traffic end-to-end.

Valters IT
DevSecOps & Cyber Threat Intelligence