CVE-2026-55199: libssh2 Pre-Auth DOS Vulnerability

CVE-2026-55199 Overview

CVE-2026-55199 is a pre-authentication denial of service vulnerability in libssh2 through version 1.11.1. The flaw resides in the SSH_MSG_EXT_INFO handler within src/packet.c and allows a malicious SSH server to trigger a client-side CPU exhaustion loop during key exchange. An attacker controlling a server can send a crafted extension count value of 0xFFFFFFFF, causing the client to spin in a tight CPU loop for more than 60 seconds. The issue stems from unchecked return values from _libssh2_get_string() combined with a session timeout that does not apply to CPU-bound loops. The vulnerability is fixed in commit 1762685.

Critical Impact
A malicious SSH server can force any connecting libssh2 client into a sustained CPU exhaustion loop before authentication, disrupting SSH-dependent automation, CI/CD pipelines, and management tooling.

Affected Products

libssh2 versions up to and including 1.11.1
Applications and SSH clients that statically or dynamically link libssh2
Automation, backup, and management tools relying on libssh2 for outbound SSH connections

Discovery Timeline

2026-06-17 - CVE-2026-55199 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-55199

Vulnerability Analysis

The vulnerability is classified under [CWE-835] Loop with Unreachable Exit Condition (Infinite Loop). It manifests during the SSH key exchange phase when the server transmits an SSH_MSG_EXT_INFO message advertising server-supported extensions. The libssh2 client parses an attacker-controlled nr_extensions field and iterates that many times to consume name/value string pairs from the packet buffer.

Because the loop trusts the declared extension count without bounding it against the actual packet length, a malicious server can declare up to 0xFFFFFFFF extensions. The client then enters a loop with roughly four billion iterations. Each iteration calls _libssh2_get_string() to read a string, but the function's return value is not checked for failure. When the buffer is exhausted, subsequent calls fail silently and the loop continues to completion.

The libssh2 session timeout mechanism does not interrupt this code path because the loop is CPU-bound rather than blocked on I/O. As a result, the client process consumes a full CPU core for over 60 seconds per connection.

Root Cause

The root cause is twofold: missing validation of nr_extensions against the remaining packet payload size, and unchecked return values from _libssh2_get_string() inside the parsing loop. Together these defects allow attacker-controlled iteration counts to drive uninterrupted CPU work.

Attack Vector

Exploitation requires only that a victim client initiate an SSH connection to a server controlled by the attacker. No credentials, prior authentication, or user interaction beyond connection establishment are needed. Attackers can redirect victims to malicious endpoints through DNS poisoning, configuration tampering, supply chain manipulation of connection targets, or by hosting attacker-operated mirrors that clients connect to for backups, Git operations, or remote management.

The vulnerability is described in prose only because no public proof-of-concept code is referenced in the advisory. Technical specifics are available in the VulnCheck Advisory on libssh2 and the GitHub Pull Request Discussion.

Detection Methods for CVE-2026-55199

Indicators of Compromise

Client processes linked against libssh2 consuming a full CPU core for 60 or more seconds during outbound SSH connections
Repeated SSH connection attempts from automation hosts to unfamiliar or recently changed destinations
Stalled or timing-out CI/CD jobs, Git operations, or backup tasks that rely on libssh2-based clients

Detection Strategies

Inventory binaries and packages linking libssh2 and compare installed versions against 1.11.1 or earlier
Monitor for SSH client processes exhibiting sustained high CPU utilization without corresponding network throughput
Inspect SSH client connection logs for repeated failed handshakes against the same remote endpoint

Monitoring Recommendations

Alert on processes such as ssh, git, curl, rsync, or custom automation agents that sustain CPU saturation during SSH handshake phases
Track outbound TCP/22 connections from servers and developer workstations to destinations outside an approved allowlist
Correlate CPU spikes with SSH_MSG_EXT_INFO packet exchange where deep packet inspection is available

How to Mitigate CVE-2026-55199

Immediate Actions Required

Upgrade libssh2 to a build that includes commit 1762685 or a release published after the fix
Rebuild and redeploy any statically linked applications that bundle vulnerable libssh2 versions
Restrict outbound SSH connections from automation infrastructure to a vetted list of trusted servers

Patch Information

The fix is committed upstream in the libssh2 repository. The patch validates the extension count against the remaining packet length and checks return values from _libssh2_get_string() before continuing the loop. Review the change in the GitHub Commit Overview and the associated GitHub Pull Request Discussion.

Workarounds

Limit outbound SSH connectivity through firewall rules or egress proxies that allow only known-good destinations
Run libssh2-based automation under CPU cgroup limits or process resource caps to bound the impact of a single malicious server
Replace libssh2-linked clients with alternative SSH implementations on critical hosts until patched packages are deployed

bash

# Configuration example: enforce egress allowlist for outbound SSH on Linux
sudo iptables -A OUTPUT -p tcp --dport 22 -d 10.0.0.0/8 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 22 -j REJECT

# Apply CPU quota to a libssh2-based service via systemd
sudo systemctl set-property my-ssh-automation.service CPUQuota=50%