CVE-2026-55199

What it actually does

libssh2 clients through 1.11.1 can be forced into a CPU-exhaustion loop during SSH key exchange when a malicious SSH server sends a crafted SSH_MSG_EXT_INFO message with an extension count of 0xFFFFFFFF. Because the SSH_MSG_EXT_INFO parser does not correctly handle failed string extraction and the normal session timeout does not interrupt CPU-bound parsing, the client can spin for more than a minute per connection before recovering or being terminated. The flaw affects availability only; it does not provide code execution, authentication bypass, data theft, or data modification.

Why it matters to the business

Applications, automation jobs, scanners, deployment tooling, backup systems, file-transfer workflows, or embedded products that use libssh2 to connect to SSH servers can experience CPU spikes, hangs, slowdowns, job failures, or service degradation if they connect to a malicious or compromised SSH endpoint. The risk is highest for systems that automatically connect to user-supplied, internet-facing, partner-managed, or otherwise untrusted SSH servers. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it can still be operationally disruptive in environments with high-volume outbound SSH activity.

How an attack unfolds

An attacker operates, compromises, or positions themselves to impersonate an SSH server that a vulnerable libssh2-based client will connect to. When the client initiates the SSH handshake, the attacker allows key exchange to progress far enough to send an SSH_MSG_EXT_INFO message. The malicious server sets the extension count field to an extreme value, such as 0xFFFFFFFF. The vulnerable client then enters a tight parsing loop because libssh2 does not properly check return values while processing the advertised extensions. Since this loop consumes CPU rather than waiting on network I/O, normal session timeout protections do not stop it promptly. Repeating the interaction across many clients or many concurrent connections can cause sustained CPU exhaustion and denial of service in the affected client-side application or host.

How to fix it

Upgrade libssh2 to a release or vendor package that includes the upstream fix from commit 1762685. Because no specific fixed package versions were provided, treat libssh2 versions through 1.11.1 as affected unless the operating-system or application vendor confirms that the fix has been backported. Rebuild or redeploy applications that statically link libssh2, since updating the system shared library alone may not remediate bundled copies. As compensating controls, restrict automated SSH clients to trusted and allowlisted destinations, enforce SSH host-key verification or pinning, avoid connecting libssh2-based tooling to user-supplied SSH endpoints, apply CPU and runtime limits to worker processes, and monitor or cap concurrent outbound SSH connection attempts.

How to confirm the fix worked

Confirm exposure by inventorying all libssh2 packages and bundled/static copies in applications, containers, appliances, and build artifacts. Verify the installed library version and, where vendor backports are used, confirm that the package changelog or source contains the SSH_MSG_EXT_INFO handling fix corresponding to upstream commit 1762685. Validate that applications have been rebuilt against the fixed library if they statically link libssh2. From a network-control perspective, confirm that libssh2-based clients can only connect to approved SSH servers and that SSH host-key verification is enforced. After remediation, run regression tests for SSH/SFTP/SCP workflows and monitor for absence of CPU-bound hangs during SSH key exchange.

Typical attack path

1. Identify software, automation, or services that use libssh2 to initiate outbound SSH/SFTP/SCP connections.
2. Set up or compromise an SSH server that vulnerable clients are likely to connect to, or obtain a network position that can impersonate the expected SSH server.
3. Wait for or induce the vulnerable client to initiate an SSH connection.
4. During SSH key exchange, send a crafted SSH_MSG_EXT_INFO packet with an excessive extension count value such as 0xFFFFFFFF.
5. Cause the client-side libssh2 parser to enter a CPU-bound loop, delaying or disrupting the calling application.
6. Repeat across multiple connections or targets to amplify CPU exhaustion and operational impact.

How to detect it

Look for evidence of client-side denial of service rather than server compromise. Useful sources include EDR process telemetry, operating-system performance logs, application logs from tools that perform SSH/SFTP/SCP operations, network connection logs, proxy or firewall egress logs, and packet captures of suspicious SSH sessions. Investigate libssh2-using processes that show sudden high CPU usage immediately after initiating an outbound TCP/22 connection, especially if the connection fails, times out, or never reaches user authentication. In packet captures, look for SSH key exchange followed by an SSH_MSG_EXT_INFO message from the server containing an anomalously large extension count, particularly 0xFFFFFFFF. Correlate repeated events from the same destination SSH server, newly observed SSH host keys, unexpected SSH endpoints, or multiple clients experiencing CPU spikes after connecting to the same server. There are no public indications from the provided data that this vulnerability is in CISA KEV, used by ransomware, or associated with named threat actors, so detection should focus on behavioral signs and crafted protocol artifacts.

• SSH_MSG_EXT_INFO
• nr_extensions=0xFFFFFFFF
• extension count 0xFFFFFFFF
• FF FF FF FF
• libssh2
• libssh2.so
• outbound tcp/22 followed by sustained client CPU spike
• client CPU exhaustion during SSH key exchange

What your security team should do

• Prioritize patching internet-facing automation, scanning infrastructure, CI/CD systems, file-transfer services, and any software that connects to untrusted or user-controlled SSH servers using libssh2.
• Create an inventory of direct and transitive libssh2 usage, including containers and statically linked binaries, not just operating-system packages.
• Upgrade to vendor packages or application releases that include the upstream fix from commit 1762685; if unavailable, apply vendor backports or rebuild from patched source.
• Restrict outbound SSH from automated workloads to approved destinations and require strict host-key validation to reduce exposure to malicious or impersonated SSH servers.
• Apply process-level CPU limits, job timeouts, and concurrency limits around libssh2-based workers as temporary containment for high-volume environments.
• Add monitoring for abnormal CPU spikes in SSH/SFTP/SCP client processes immediately following outbound SSH connection attempts.
• Review recent telemetry for failed or long-running SSH handshakes with unusual client CPU consumption, especially where clients connect to third-party, user-supplied, or newly observed SSH servers.