There is a piece of software called libssh2 that your organization almost certainly relies on, even if no one on your team has ever heard of it by name. It is a C library that implements the SSH protocol, and it is embedded as a dependency in an enormous range of tools: curl, the command-line utility used for countless file transfers and API calls; backup agents; firmware updaters; network and IoT devices; and automation frameworks of all kinds. When any of those tools makes an SSH, SCP, or SFTP connection, there is a reasonable chance libssh2 is handling the underlying work.
A critical vulnerability was disclosed in libssh2 on June 17, 2026, tracked as CVE-2026-55200. The flaw allows a remote attacker to corrupt the memory of any application using a vulnerable version of the library and, under the right conditions, execute arbitrary code on the affected system. No authentication is required. No user interaction is needed. Any process that connects to an untrusted SSH server, or that can be reached by a malicious one, is a potential target.
A public proof-of-concept exploit was published on June 24, one week after disclosure. CISA has since updated its assessment of the CVE to reflect public PoC availability, and NHS England Digital has issued a formal advisory. No official libssh2 release containing the fix has been tagged yet, though a patch exists in the project's commit history, Debian has a repaired build in its testing repository, and other distributions are actively backporting. The urgency here is real: the bar for exploitation has dropped considerably, and it will not rise again.
What is libssh2, and why does it matter?
SSH (Secure Shell) is the standard protocol used to securely connect to remote systems, transfer files, and run commands over a network. Most people interact with it through a terminal client. But SSH is also used extensively by automated systems: scripts that pull files from remote servers, agents that manage backups, tools that update firmware on network devices, and libraries that power higher-level software.
libssh2 is one of the most widely used libraries that implements the client side of SSH. Because it is a dependency rather than a standalone product, it tends to be invisible. It is present in most official package repositories for major Linux distributions. It ships embedded inside applications that may themselves ship inside containers, virtual machines, or cloud instances. Crucially, many of the environments where libssh2 lives, network equipment, embedded systems, backup appliances, are not updated frequently or at all.
That is precisely what makes a vulnerability in libssh2 dangerous. The exposure is not confined to one product or platform. It follows the library wherever it has been embedded, and that is a very large surface area.
What is CVE-2026-55200?
CVE-2026-55200 is an integer overflow vulnerability in ssh2_transport_read(), the function inside libssh2 responsible for parsing incoming SSH packets on the client side. It was discovered and responsibly disclosed by security researcher Tristan Madani (@TristanInSec), and was published by VulnCheck on June 17, 2026.
The vulnerability affects all versions of libssh2 up to and including 1.11.1. The fix exists as a commit to the project's repository; no new official release has yet been tagged with the patch included, though distributions are packaging backports.
What goes wrong
SSH communication is structured as a series of packets. Each packet carries a field called packet_length that tells the recipient how many bytes to expect. When libssh2 receives an incoming packet, it reads this field and uses it to calculate how much memory to allocate for the decrypted contents.
The problem is that libssh2 does not check whether packet_length falls within a valid range before performing that calculation. An attacker can supply an excessively large value, such as the maximum 32-bit integer (0xffffffff). When that value is fed into the allocation arithmetic, the result wraps around to a very small number. The library then allocates a tiny buffer, but subsequent processing steps still trust the original, enormous packet_length value when deciding how many bytes to copy into it. The result is an out-of-bounds heap write: the library writes far more data than the buffer can hold, corrupting adjacent memory.
This class of bug, an integer overflow that leads directly to a buffer overflow, is classified as CWE-680. The CVSS v4 vector for this vulnerability reflects network-based access, low attack complexity, no required privileges, and no required user interaction, with high impact across confidentiality, integrity, and availability.
What an attacker can do
The most severe outcome is remote code execution (RCE). By controlling the data written past the end of the undersized buffer, an attacker can corrupt adjacent heap structures, including function pointers and callback addresses. If that corruption can be steered reliably, the attacker gains the ability to redirect program execution and run arbitrary commands as the process using libssh2.
The important caveat: realizing RCE reliably requires overcoming target-specific factors such as memory layout, allocator behavior, and the mitigations present on the system. The published proof-of-concept confirms that the vulnerability is exploitable and demonstrates end-to-end code execution in a controlled environment, but adapting it to every real-world target takes additional work. This is a lower bar than it may sound: skilled, motivated attackers routinely do exactly this.
At minimum, even without achieving RCE, the heap corruption reliably causes the affected process to crash, producing a denial-of-service condition. Any automated tool, backup agent, or connectivity service using libssh2 could be taken offline by a single crafted packet from a server it connects to.
Who triggers the bug: servers, not just clients
This point is worth pausing on, because it changes the threat model significantly. The vulnerable code runs on the client side: it is the application making an SSH connection that is at risk, not the SSH server it connects to.
An attacker who controls, compromises, or can impersonate an SSH server can exploit any client that connects to it. This includes:
- An internal automation script that connects to a compromised SSH endpoint as part of a routine job
- A backup agent reaching out to a storage server that an attacker has taken over
- A curl invocation hitting a malicious or intercepted SFTP server
- A firmware updater in a network device phoning home to a hijacked update endpoint
A man-in-the-middle attacker positioned between a vulnerable client and any SSH server could also deliver the malicious packet without needing to control the destination server directly.
The other vulnerabilities patched alongside CVE-2026-55200
The same disclosure cycle surfaced two additional flaws in libssh2 that warrant attention, though neither rises to the level of CVE-2026-55200.
CVE-2026-55199 is a pre-authentication denial-of-service vulnerability that also targets the client side. During the initial SSH key exchange, a server can declare an arbitrarily high number of supported extensions. libssh2 does not cap this count, so a malicious server can send a crafted extension count value so large that the connecting client enters a tight CPU loop for over 60 seconds. The application hangs, processes waiting on the connection stall, and system resources are consumed for the duration. This flaw is fixed by a separate commit to the libssh2 repository.
CVE-2025-15661 is an SFTP heap over-read. It was patched in the same batch and, while less severe than the RCE path, represents additional risk for any deployment using SFTP functionality via libssh2.
All three vulnerabilities are addressed in the same backport effort across distributions.
Who is affected?
Every application and system using libssh2 version 1.11.1 or earlier is potentially affected by CVE-2026-55200. The library is present across a very broad ecosystem:
Development and automation tooling. curl, one of the most widely deployed command-line utilities on earth, uses libssh2 to support SCP and SFTP. Git, PHP's ssh2 extension, and R's ssh package also link against it. Any environment where these tools handle SSH-based transfers, including CI/CD pipelines, build systems, and deployment scripts, is in scope.
Backup and file transfer software. Many backup agents and file transfer tools embed libssh2 directly. If such software is connecting to a server that could be compromised or impersonated, the client is at risk.
Network and IoT devices. Devices that use libssh2 for remote management or connectivity and that receive infrequent or no updates represent a particularly stubborn category of exposure. These devices may remain vulnerable long after distribution-level patches are available.
Cloud and containerized workloads. Applications running in containers or cloud instances that link against the system libssh2 package, or that bundle their own copy, are affected at the application layer regardless of the underlying infrastructure. Container images built before the patch was backported will need to be rebuilt.
Any system with statically linked copies of libssh2. This is the silent risk. An application that statically compiled libssh2 into its own binary carries its own private copy of the vulnerable code, entirely separate from the system package. Those copies do not get updated when you update the system package. They require the application vendor to issue a new build.
The public proof-of-concept and CISA's updated assessment
When a vulnerability is disclosed, the risk is partially theoretical until an attacker has a working exploit in hand. That changed on June 24, when researchers published a proof-of-concept toolkit to a public repository under the name "exploitarium."
The toolkit makes three things clear. First, the vulnerability is real and triggerable: the PoC includes a verifier written in C that reproduces the vulnerable arithmetic, confirming that a crafted packet_length value produces the undersized allocation that the write overflows into. Second, the attack requires only a malicious SSH server: the PoC ships a minimal Python-based server that negotiates a normal encrypted SSH handshake and then delivers the malformed packet. Third, end-to-end code execution is feasible in a controlled environment: the PoC demonstrates the overflow corrupting a callback pointer and redirecting execution, though it is explicitly framed as a proof of feasibility rather than a ready-made weapon for every deployment.
CISA has updated its SSVC assessment accordingly. The exploitation field now reads "poc" rather than "none," and CISA has tagged the exploitarium repository as an exploit reference for this CVE. No in-the-wild exploitation has been confirmed at the time of writing, and CVE-2026-55200 has not yet been added to CISA's Known Exploited Vulnerabilities catalog. These are meaningful distinctions, but they are not a reason for complacency: the window between "PoC available" and "active exploitation" has been narrowing across the vulnerability landscape throughout 2026, and past libssh2 vulnerabilities have seen rapid uptake by opportunistic actors once exploit code became public.
NHS England Digital has also issued advisory CC-4799, urging affected organizations to update, reflecting the broad institutional concern that this flaw has generated.
A note on history: this bug has been here before
One detail that adds important context: this is not the first time libssh2 has shipped this exact class of vulnerability.
In 2019, the project released version 1.8.1 to fix a batch of nine security flaws, the most serious of which was CVE-2019-3855: a near-identical integer overflow in the same transport read path that also allowed a malicious server to execute code on a connecting client. The fix for that flaw was the same conceptual remedy — adding bounds validation to packet_length before the arithmetic runs.
The fact that the same bug class returned to the same function seven years later is worth understanding. It speaks to the difficulty of maintaining memory-safe code over long timescales in a widely embedded library with a large and shifting contributor base. It also suggests that any organization conducting a thorough remediation should audit not just whether they have patched this specific commit, but whether their internal processes would catch a similar regression in the future.
What should you do?
1. Inventory your libssh2 exposure
Before you can patch, you need to know where the library lives. This is more involved than it sounds, because libssh2 may be present as a system package, as a bundled dependency inside another application, or as a statically linked copy inside a binary.
Check the system-level package:
# Debian / Ubuntu
dpkg -l | grep libssh2
# RHEL / Rocky / AlmaLinux / Fedora
rpm -q libssh2
# Check the installed version
pkg-config --modversion libssh2
To find dynamically linked applications using the library:
lsof | grep libssh2
# or
ldconfig -p | grep libssh2
For statically linked copies, a binary scan tool such as strings combined with a version pattern, or a dedicated software composition analysis tool, is more appropriate. Pay particular attention to backup agents, custom automation tooling, and vendor-supplied appliance software.
2. Update libssh2 from your distribution's package manager
A patch exists as commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 in the libssh2 project repository. No official new release of libssh2 has been tagged yet at the time of writing, but major distributions are actively backporting this fix. Debian already has a repaired build in its testing repository (version 1.11.1-1+deb13u1 for trixie). Check your distribution's security advisories and update as soon as a patched package is available:
# Debian / Ubuntu
sudo apt-get update && sudo apt-get upgrade libssh2-1
# RHEL / Rocky / AlmaLinux / Fedora
sudo dnf update libssh2
# SUSE / openSUSE
sudo zypper update libssh2-1
# Arch Linux
sudo pacman -Syu
After updating, verify the installed version and check your distribution's security tracker to confirm the backport for CVE-2026-55200 is included. Applications that dynamically link libssh2 will typically pick up the fix without needing to be rebuilt, provided they use the system library rather than a bundled copy. A restart of affected services is required to ensure they load the updated library.
3. Address statically linked copies separately
For any application that bundles or statically links its own copy of libssh2, a system package update is insufficient. Contact the vendor or, for open-source tooling you control, rebuild against the patched commit. Until a rebuild is available, restrict the affected application's access to untrusted SSH endpoints where possible.
4. Restrict connections to untrusted SSH servers while patching
The attack requires a malicious or compromised SSH server to deliver the packet. While you work through remediation, review which processes and services connect to SSH endpoints you do not control and consider whether those connections can be restricted, rate-limited at the network layer, or temporarily suspended. This is a defence-in-depth measure, not a substitute for patching.
5. Monitor for anomalous SSH client behavior
The crash path produces process-level signals that are detectable. If any application using libssh2 is targeted and the RCE path does not succeed, or if a denial-of-service attempt is made, the affected process will crash or become unresponsive. Monitor for unexpected crashes of SSH-using automation, repeated restart events in process supervisors, and unusual CPU spikes in network-adjacent services.
# Check for crashes in a service that uses libssh2 (example: a backup agent)
journalctl -u your-backup-service --since "7 days ago" | grep -i "fault\|killed\|crash\|signal"
For CVE-2026-55199 specifically, a symptom is a process that is responsive on start but then hangs for 60 or more seconds shortly after attempting an SSH connection. If you see this pattern in logs or monitoring, treat it as a possible exploitation attempt and investigate the SSH endpoint involved.
Detection
Unlike some memory corruption bugs that are silent until RCE is achieved, both main attack paths here leave detectable traces.
For CVE-2026-55200, a failed exploitation attempt typically crashes the libssh2-linked process, producing a signal such as SIGSEGV or SIGABRT. These appear in system logs and service journal entries. Repeated crashes of an SSH-using process, particularly in a short window and with network activity preceding each crash, are a strong indicator of active exploitation attempts.
For CVE-2026-55199, the signature is a client-side CPU spike of more than 60 seconds immediately following an SSH connection attempt. Process-level CPU monitoring or tracing tools can surface this. If you see it, the SSH server the client connected to is suspect.
At the network level, anomalously large values in the SSH packet_length field are detectable by a network IDS with SSH protocol analysis capability. Suricata, which includes SSH decoding, can be configured to flag packets with packet length values exceeding the protocol's defined maximum.
Detection rules and updated guidance will be published to our GitHub repository as they are developed.
A note on the shape of this risk
The thing that makes CVE-2026-55200 distinct from many other RCE vulnerabilities is that the attacker does not need to find and attack your servers. They need your software to connect to theirs.
This inverts the usual mental model. Defenders think naturally about hardening inbound attack surface: patching servers, closing ports, filtering traffic. This vulnerability exploits outbound connections, the ones your automated tools make routinely and invisibly. A compromised update server, a poisoned DNS response pointing a backup agent at the wrong destination, a man-in-the-middle on a network segment, any of these is a viable delivery path. An attacker who compromises even one SSH endpoint that your automation connects to gains a position from which they can target every libssh2 client that reaches out to it.
The patch addresses the root cause cleanly. But the inventory question, knowing every place libssh2 lives in your environment, is the harder problem, and it is the one most organizations will struggle with. Statically linked copies in vendor appliances or aging internal tooling may not surface until you specifically go looking for them.
Summary
| CVE | CVE-2026-55200 |
| CVSS Score | 9.2 (Critical, v4) / 8.1 (High, v3.1) |
| Type | Integer Overflow to Buffer Overflow (CWE-680), Out-of-Bounds Heap Write |
| Discovered by | Tristan Madani (@TristanInSec) |
| Disclosed | June 17, 2026 (VulnCheck advisory) |
| Affected | libssh2 versions 0 through 1.11.1 (all versions to date) |
| Attack vector | Network; attacker controls or impersonates an SSH server the target connects to |
| Authentication required? | None |
| User interaction required? | None |
| Immediate impact | Process crash (DoS) against any vulnerable libssh2 client |
| Worst-case impact | Remote code execution on the system running the vulnerable client |
| Public PoC? | Yes, published June 24, 2026 |
| CISA SSVC status | Exploitation: PoC (updated June 24, 2026); not yet in KEV catalog |
| Active exploitation confirmed? | Not confirmed at time of writing |
| Companion vulnerabilities | CVE-2026-55199 (CVSS 8.2), pre-auth client CPU exhaustion; CVE-2025-15661 (CVSS 8.3), SFTP heap over-read |
| Notable advisories | NHS England Digital advisory CC-4799 |
| Fix | Commit 97acf3df to libssh2 repository; update via your distribution's package manager when the backported package is available |
| Official release tagged? | Not yet at time of writing; Debian testing has 1.11.1-1+deb13u1; other distributions are backporting |
| Interim measure | Restrict libssh2-using clients from connecting to untrusted SSH endpoints |
With a working public PoC in circulation, CISA's assessment updated to reflect it, and NHS England Digital issuing a formal advisory, this vulnerability has moved firmly from theoretical to practical. If you need help auditing your environment for libssh2 exposure, including statically linked copies in vendor tooling and container images, or establishing detection coverage for exploitation attempts, get in touch. The hard part here is not patching the system package; it is knowing everywhere the library lives.