Skip to main content
NewsSecurity
SecurityJuly 2, 20267 min read

The New libssh2 SSH Flaw Is Client-Side, Not Your sshd, and apt upgrade Will Not Fix the Copies That Matter

CVE-2026-55200 is an out-of-bounds write in the libssh2 client library that a malicious or compromised SSH server can use to corrupt a connecting client's memory, and a public proof-of-concept is already out. The corrections that matter: it is client-side and not an OpenSSH or sshd bug, the severity rating is disputed across scorers, and the real cleanup is finding the statically linked and vendored copies a distribution update never touches.

The bug in one paragraph

CVE-2026-55200 is an out-of-bounds write in libssh2, the client-side SSH library. The parsing function ssh2_transport_read() in transport.c reads the packet_length field off the wire during the SSH handshake but fails to enforce an upper bound on it. A malicious, compromised, or man-in-the-middled SSH server can send a packet that declares a length far larger than the real payload, and libssh2 writes past the end of a heap buffer, corrupting adjacent memory. The weakness is classed as CWE-680, integer overflow to buffer overflow, the classic primitive that can escalate from a crash to remote code execution. No credentials are required. NVD published the record on June 17, 2026 and last modified it on July 1, 2026, and a public proof-of-concept is now linked directly from the NVD entry.

This is client-side, and it is not your sshd

The single most important correction to the headlines: this is a bug in an SSH client library, not in an SSH server. Your OpenSSH sshd, the thing listening on port 22 and accepting logins, does not use libssh2 and is not the target here. The victim is the side that opens the connection. You are exposed when something on your host acts as an SSH client through libssh2 and connects out to a server an attacker controls or has interposed on. A box that only receives SSH is not what this CVE is about. That flips the usual mental model: the risk follows outbound SSH, not your inbound attack surface.

The severity is disputed, and that changes your priority

You will see this called critical 9.2. That is one scorer. VulnCheck, the CNA, assigned CVSS 4.0 at 9.2 Critical. NIST scored the same flaw 8.3 High on CVSS 3.1. Red Hat rates it Moderate at 7.1. Ubuntu tags it Medium priority. SUSE calls it Important. The spread is not sloppiness, it reflects a real judgement call: exploitation requires your client to connect to an attacker-controlled or intercepted server, so several scorers weight that as user interaction or higher attack complexity and mark the number down. Treat 9.2 as the ceiling, not the consensus, and prioritize by whether you actually make outbound SSH to places you do not fully trust.

Which distributions are actually affected

The NVD range reads "0 through 1.11.1", but that is the CNA's conservative upper bound, and the distributions do not agree on the older versions. The real picture, per each vendor's own tracker at the time of writing:

  • Debian: bookworm (stable, libssh2 1.10.0) is still marked vulnerable with no DSA yet, while trixie is fixed in 1.11.1-1+deb13u1 (DSA-6365-1) and sid in 1.11.1-4.
  • Ubuntu: 20.04, 22.04, and 24.04 LTS are marked not affected, and only 25.10 and 26.04 received a fix (1.11.1-1ubuntu0 series).
  • Red Hat: RHEL 8, 9, and 10 do not ship the libssh2 package at all and are not affected, RHEL 7 is affected, and the Red Hat Hardened Images got a fix in RHSA-2026:29950.
  • SUSE: SLE and Leap 15 and earlier are not affected, SLE 16.x and Leap 16 are affected with fixes rolling out, and Tumbleweed is fixed in 1.11.1-3.1.
  • Alpine: patched packages have landed on the current branches (3.21 and 3.22 are marked fixed at 1.11.1-r2), but the tracker still lists edge and some newer branches as not yet confirmed, and older branches like 3.19 and 3.20 ship pre-fix builds, so verify your exact branch on the Alpine tracker. This matters for container images, since a large share of them are Alpine-based.

Note the contradiction worth remembering: Debian treats 1.10.0 as vulnerable while Ubuntu treats the same era as not affected. Do not trust a blanket "every version is affected" line. Check your distribution's tracker for your exact package version.

The fix is a commit, not a release

There is no libssh2 1.11.2. The newest upstream tag is still 1.11.1, released back in October 2024. The fix exists only as commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8, merged through pull request 2052. The NVD description text prints a mangled short hash, 7acf3df, that drops a leading digit, so use the full hash above from the patch reference. The practical consequence is blunt: if you build libssh2 from the latest official release tarball, you still ship the bug unless you cherry-pick the patch. The people who are safe are those on a distribution backport or a source build that includes that commit.

Where the real exposure hides

If you only run apt upgrade or dnf update, you fix the one dynamically linked system copy of libssh2 and you are done with maybe a fraction of the problem. libssh2 is embedded all over the place, and package managers do not touch statically linked or vendored copies. The usual suspects: curl built with libssh2 for SCP and SFTP (run curl -V and look for libssh2 in the output), Git and libgit2 builds that use libssh2 for the SSH transport, the PHP ssh2 extension, backup and sync agents, firmware updaters, network appliances, and application container images that bundle their own libssh2. Each of those is an independent copy that a distribution update will never move. The hard part of this CVE is not patching. It is inventory.

Who should act first

Rank your hosts by outbound SSH to endpoints you do not control. The ones at the top: CI and build runners that clone or push over SSH, backup and rsync-over-SSH jobs that reach third-party or partner storage, mirroring and automation bots, anything that connects to a partner SFTP endpoint, and any client that traverses a network where a man-in-the-middle is plausible. A server whose only SSH exposure is an inbound OpenSSH daemon can move down the list. This is the same "who is actually at risk" triage we walked through for the two critical NGINX bugs: the CVE is real, but the blast radius is specific.

What to do this week

  • Inventory every consumer of libssh2, not just the system package. Check installed binaries with ldd, check curl with curl -V, check language bindings like the PHP ssh2 extension, and check the contents of your container images. The vendored and static copies are the ones that bite.
  • Apply your distribution's backport where one exists, using the fixed versions listed above for your release.
  • Rebuild or update the static and bundled copies yourself, because no package update will do it for you.
  • As an interim mitigation, restrict outbound SSH, SCP, and SFTP to known-good servers, and verify or pin host keys so a swapped or intercepted server is rejected before the vulnerable parse path runs.
  • Do not rip out your SSH automation in a panic. Scope the change to the clients that actually reach untrusted servers.

One honest caveat

A public proof-of-concept exists and is linked from the NVD record, but as of this writing there is no evidence of exploitation in the wild, only PoC availability. Do not let a scary headline number drive a rushed change on hosts that never make risky outbound SSH. Equally, do not wave it off: a client-side memory-corruption bug with a public PoC, in a library this widely embedded, is exactly the kind of thing that gets weaponized against CI and automation later. Re-verify the current status and your exact package versions against your distribution's security tracker before you act, because triage states and backport versions move day to day.

How a senior team de-risks this

The reason this lands as a fire drill for some teams and a checklist for others comes down to whether you can answer one question quickly: where does libssh2 live in our estate, including the static and vendored copies. Teams that maintain a real software inventory and rebuild their own images on a known cadence treat this as a scoped dependency bump. Teams that cannot see past the system package manager spend the week guessing. Building that visibility, for embedded client libraries exactly like this one, is ordinary supply-chain hygiene and the core of a security and compliance review. It is the same discipline that turns the next widely embedded CVE, like the OpenSSL 3.0 end-of-life exposure, into a boring afternoon instead of a scramble.

Sources

Talk to the engineer who will own your stack.

No account managers, no offshore handoff. Senior DevOps, direct. Tell us what you are dealing with and you get a straight answer.

View Related Service Discuss

Related News

Security

OpenSSL 3.0 Stops Getting Security Fixes in September and You Probably Still Ship It

OpenSSL 3.0 stops receiving all fixes, including security fixes, after September 7, 2026, and the 3.4 line follows on October 22. For most teams the distro backports cover it, but self-compiled, vendored, and container-bundled OpenSSL go quietly unpatched. Here is who is actually exposed and how to check.

Security

From September 11 the EU Cyber Resilience Act Puts a 24-Hour Clock on Exploited Vulnerabilities and Most Makers Have No Runbook

From 11 September 2026, Article 14 of the EU Cyber Resilience Act forces makers of products with digital elements to report actively exploited vulnerabilities within 24 hours, with a 72-hour follow-up and a 14-day final report. It is the first binding CRA deadline, and the hard part is operational: detecting, triaging, and filing a conformant report inside a single day.

Security

If You Use Gravity SMTP On WordPress Rotate Your Email API Keys Now

CVE-2026-4020 in the Gravity SMTP WordPress plugin (about 100,000 installs) lets an unauthenticated attacker pull your email provider API keys straight off the site, and bots are mass-exploiting it. It is rated CVSS 7.5 (High). Here is what leaks, why it deserves immediate attention, and the patch-and-rotate steps.