CVE-2026-55199: libssh2 Pre-Authentication DoS via CPU Exhaustion

Technical summary

The vulnerability resides in the SSH_MSG_EXT_INFO handler within src/packet.c of libssh2. During key exchange, a malicious server can set the nr_extensions field to 0xFFFFFFFF (maximum 32-bit unsigned integer), triggering unbounded iteration in extension processing. The code fails to validate return values from _libssh2_get_string() calls, and because the resulting loop is CPU-bound rather than I/O-bound, the session timeout mechanism does not interrupt it. This leads to sustained high CPU utilization on the client until the loop completes or the process is killed. The defect is classified as an infinite or near-infinite loop condition (CWE-835). The fix is available in commit 1762685.

Business impact

Organizations face potential service disruptions if client applications built with vulnerable libssh2 connect to malicious or compromised SSH servers. Since the attack requires server-side control, the immediate risk is highest for automated tools, integrations, or scripts that connect to external SSH infrastructure without strong trust boundaries. Affected applications will hang unresponsively during connection, consuming CPU and potentially triggering watchdog restarts or operator intervention. In environments where SSH is used for critical automation or API communication, this could cascade into infrastructure failures.

Affected systems

Any application statically or dynamically linked against libssh2 version 1.11.1 or earlier is vulnerable when initiating connections to SSH servers. This includes SSH clients, sftp/scp utilities, CI/CD integration tools, configuration management systems, and cloud automation frameworks that depend on libssh2 for SSH protocol support. The vulnerability affects all platforms and architectures where libssh2 is deployed.

Exploitability

Exploitation requires a threat actor to control or intercept the SSH server during a client connection attempt. This is not a trivial bar—the attacker must either own the server, successfully perform man-in-the-middle interception, or compromise a legitimate server. Public exploitation is not currently known (KEV status indicates no active weaponization), but the attack is technically straightforward once server-side control is achieved. The CPU exhaustion will be immediately observable as a hung connection and elevated process CPU usage.

Remediation

Update libssh2 to a patched version released after commit 1762685. Verify the specific patch version against your vendor's advisory, as release numbering varies by distribution. For applications unable to update immediately, monitor SSH connection behavior for unexpected hangs or CPU spikes, and implement network controls to restrict outbound SSH connections only to trusted, known servers. Review SSH server whitelist policies and consider disabling SSH where not operationally required.

Patch guidance

Consult your operating system vendor or application vendor for patched libssh2 builds. If building from source, ensure you are using code at or after commit 1762685. Test patched versions in a staging environment before production deployment, particularly if your application integrates SSH connection pooling or long-lived sessions. Verify that the patch version is clearly documented in your software bill of materials (SBOM) and deployment configurations.

Detection guidance

Monitor for client-side SSH connection attempts that result in sustained high CPU usage (>80% on a single core) lasting more than 10 seconds without data transfer. Log SSH connection timeouts or connection states that persist in 'authenticating' or 'key exchange' phase. Correlate with external server IP addresses and compare against your approved SSH server whitelist. Automated process monitoring can alert on libssh2-dependent applications consuming abnormal CPU during SSH operations. Network introspection can detect SSH_MSG_EXT_INFO packets with unusually large extension count fields.

Why prioritize this

Although the CVSS score is MEDIUM (5.9), this vulnerability should be prioritized based on: (1) the attack occurs pre-authentication, meaning no credentials are required; (2) it reliably causes denial of service on the client with no user interaction; (3) any application connecting to untrusted SSH servers is at risk; and (4) the fix is available and straightforward. Organizations should treat patching as high priority for applications exposed to external SSH infrastructure.

Risk score, explained

The CVSS:3.1 score of 5.9 (MEDIUM) reflects the availability impact (high) tempered by the requirement for network adjacency and an attacker-controlled server (attack complexity high). The score does not account for contextual severity in organizations where SSH is critical to automation or deployment pipelines. Security teams should elevate priority based on their SSH usage patterns and trust boundaries.

Frequently asked questions