CVE-2026-55200

What it actually does

This is a network-reachable heap memory corruption flaw in libssh2 through 1.11.1. The vulnerable ssh2_transport_read() path does not properly enforce an upper bound on the SSH packet_length field before processing packet data. A malicious SSH peer can send a crafted packet with an excessively large length value, causing an out-of-bounds heap write. Depending on allocator behavior, process hardening, and application context, this can lead to process crash, memory corruption, or remote code execution with the privileges of the process using libssh2.

Why it matters to the business

Applications and products that embed or link libssh2 can be compromised or made unavailable when they connect to, or otherwise communicate with, a malicious SSH endpoint. Successful exploitation could let an attacker run code inside affected services, automation tools, file-transfer workflows, update mechanisms, CI/CD jobs, monitoring systems, or embedded products that rely on libssh2. Although the issue is not currently listed in CISA KEV and no mature public exploit is indicated, the high technical severity and remote pre-authentication nature make remediation important, especially for internet-facing or automated SSH integrations.

How an attack unfolds

An attacker first needs to cause a vulnerable application using libssh2 to process SSH traffic from an attacker-controlled peer. In many deployments this means operating a malicious SSH server and inducing a vulnerable client, scanner, automation job, or integration to connect to it; in other embedded uses it may involve sending crafted SSH traffic to a component that accepts SSH connections through libssh2. During SSH transport processing, the attacker sends a packet with a deliberately oversized packet_length value. Because vulnerable versions fail to enforce the required upper bound before writing packet data into heap-managed buffers, the crafted packet corrupts adjacent heap memory. A basic exploit may cause a denial of service through a crash. A more advanced exploit would groom heap layout, control overwritten metadata or adjacent objects, redirect execution flow, and execute attacker-controlled code in the context of the vulnerable process.

How to fix it

Upgrade libssh2 to a release or vendor package that includes the upstream fix from commit 7acf3df. The affected range is libssh2 through 1.11.1; because no fixed version was provided in the input, rely on operating system, distribution, appliance, container image, and software-vendor advisories for the exact patched package version. If a packaged fix is not yet available, rebuild libssh2 from a source revision that includes commit 7acf3df or apply the vendor backport. After patching the library, restart or redeploy all applications and services that dynamically link to libssh2, and rebuild statically linked binaries or container images that embed it. As interim mitigations, restrict which SSH servers vulnerable clients can contact, block outbound SSH from workloads that do not require it, avoid connecting automation to untrusted SSH endpoints, apply process sandboxing and memory-hardening controls, and monitor for crashes in software using libssh2.

How to confirm the fix worked

Inventory hosts, containers, appliances, and application builds for libssh2 versions through 1.11.1. Confirm that package metadata, SBOMs, container manifests, and compiled artifacts show a vendor-patched build or a source revision containing commit 7acf3df. For dynamically linked software, use package-manager queries and binary linkage checks such as ldd or equivalent tooling to confirm the loaded libssh2 library is patched. For statically linked software, rebuild and verify the embedded dependency through SBOM or build provenance rather than relying only on system packages. Validate exposure by identifying applications that initiate or accept SSH sessions through libssh2, especially those that can reach untrusted SSH endpoints. After remediation, restart affected processes and confirm no vulnerable libssh2 instance remains loaded in memory.

Typical attack path

1. Identify software, appliances, agents, automation jobs, or services that use libssh2 through 1.11.1.
2. Position an attacker-controlled SSH endpoint or otherwise gain the ability to send crafted SSH transport packets to the vulnerable component.
3. Trigger an SSH session so the vulnerable code path in ssh2_transport_read() processes attacker-controlled packet data.
4. Send SSH packets containing an excessively large packet_length value designed to bypass expected bounds handling.
5. Cause out-of-bounds heap writes, resulting in process crash or controlled heap corruption.
6. If pursuing code execution, use heap grooming and memory-corruption techniques to redirect control flow and run code with the privileges of the affected process.

How to detect it

Detecting prior exploitation is difficult because successful exploitation may leave only generic memory-corruption artifacts. Review application, system, EDR, and crash logs for segmentation faults, heap corruption, allocator aborts, or AddressSanitizer findings in processes that use libssh2, especially around SSH connection activity. Collect and inspect core dumps for stack traces containing ssh2_transport_read(), libssh2, or SSH packet parsing functions. Review network telemetry for unexpected SSH sessions to untrusted or newly observed hosts, particularly outbound SSH from automation systems, scanners, file-transfer jobs, CI/CD workers, and management tools. If packet captures or IDS telemetry are available, look for SSH sessions with abnormal packet length behavior or malformed SSH transport packets preceding process termination. Correlate process crashes with remote peer IPs, command execution anomalies after crashes, newly spawned child processes, unusual file writes, or persistence activity by the affected application account. No specific threat actor or ransomware use is currently indicated in the provided data, so focus detection on exploit behavior, crash artifacts, and suspicious SSH peer activity rather than actor-specific indicators.

• ssh2_transport_read
• libssh2.so
• libssh2.dll
• libssh2/1.11.1
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• malloc(): corrupted top size
• malloc(): memory corruption
• corrupted double-linked list
• double free or corruption
• free(): invalid next size
• Segmentation fault
• core dumped
• packet_length
• SSH packet length
• 7acf3df

What your security team should do

• Prioritize patching internet-connected, automated, or high-privilege systems that use libssh2, especially CI/CD runners, file-transfer systems, monitoring tools, backup tools, vulnerability scanners, and embedded network products.
• Create an inventory of products and containers that bundle libssh2 because the vulnerable code may be present even when the operating system package is patched.
• If no vendor package is available, track and deploy builds containing upstream commit 7acf3df or a confirmed backport.
• Restrict outbound SSH access from workloads that do not explicitly require it, and limit SSH destinations for automation to trusted hosts.
• Review crash telemetry, core dumps, EDR alerts, and application logs for heap corruption or segmentation faults involving libssh2 or ssh2_transport_read().
• Hunt for unexpected outbound SSH connections from systems that run libssh2-based automation, especially connections immediately preceding process crashes.
• Rebuild and redeploy statically linked applications and container images after the dependency is patched.
• Monitor vendor advisories for downstream products that embed libssh2 and may publish their own fixed versions or mitigation steps.