libssh2: ten 2026 flaws, no release since 2024 (CVE-2026-66032)

On July 24, 2026, four vulnerabilities were disclosed at once in a component called libssh2: CVE-2026-66032, CVE-2026-66033, CVE-2026-66034 and CVE-2026-66035. That brings the number of libssh2 vulnerabilities disclosed in 2026 to ten.

libssh2 is the shared component a program uses when it connects out to another server over SSH (an encrypted remote connection) or SFTP (encrypted file transfer). You are likely to be using it without knowing the name. curl, the download tool found almost everywhere, hands its SFTP work to this component. libgit2, which lets programs drive Git operations, can be built so that SSH support is "provided by libssh2 or by invoking OpenSSH." And the PHP ssh2 extension lists libssh2 itself as a build requirement.

These ten have two features that set them apart from ordinary CVE news. First, the machine that gets damaged is not the one being connected to, but the one doing the connecting. Second, the upstream project has not shipped a release since 1.11.1 in October 2024. "Update to the latest version" is not an answer here, so this article walks through how to check what you actually have, and what is fixed where, using results measured on a real machine.

The ten disclosed in 2026

Here is the whole set. Severity is expressed with CVSS, the common 0-10 scale, and because the industry is mid-migration you will see both the newer 4.0 and the older 3.1 scores. Where they disagree, that is a difference in scoring method, not an error on either side.

Four of the ten are pre-authentication, meaning they land while the two sides are still agreeing on ciphers and exchanging greetings. Whether your key or password is correct never enters into it. The moment you attempt the connection, the outcome is already decided.

One identifier starts with "CVE-2025-", but that only reflects when the number was reserved: it was published on June 18, 2026. If you track vulnerabilities in a year-by-year sheet, this one drops into last year's rows and is easy to miss.

The danger is the server you connect out to

The people who can use these ten are anyone able to stand up, or already control, a server that you connect to. That is the reverse of the usual direction. Protecting the servers you publish is not enough. The SFTP endpoint a business partner told you to collect files from every night, the jump host your team relies on, the address a scheduled job dials out to on its own — if any one of those starts behaving maliciously, the side that takes the damage is the side that went to fetch.

Once the SFTP endpoint your partner nominated turns hostile, all it has to do is write deliberately wrong numbers into the length and count fields of the SSH handshake, and corrupt the memory of the program that dialed in. SSH begins by declaring things: this is the cipher we will use, this much data is coming next. The code that trusts those declarations and sizes its buffers accordingly is where the holes are, so when the declaration and the reality are made to disagree, writes land outside the box that was reserved. The four pre-authentication issues are settled entirely inside that opening exchange.

Whether the far end is your jump host or a partner's SFTP endpoint, what follows splits into two grades. The mild one is that the program crashes or hangs: your nightly file transfer stops silently and the data simply is not there in the morning. The severe one is that the corrupted memory becomes a foothold, and commands run on the connecting machine with that program's privileges. Those machines tend to be exactly where credentials and keys live, which is how it spreads. For CVE-2026-55200 from June, a record of published exploit code is registered in the vulnerability database, so this is not purely theoretical. The same "the client is the one that breaks" shape appeared in the Tera Term terminal vulnerabilities.

Checking whether you use it, in one minute

libssh2 is a textbook example of a component nobody remembers choosing. The fastest check is to ask curl. Here is the output on an Ubuntu 26.04 LTS machine.

$ curl -V
curl 8.18.0 (x86_64-pc-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.5 zlib/1.3.1
  brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.2 libssh2/1.11.1
  nghttp2/1.68.0 librtmp/2.3 mit-krb5/1.22.1 OpenLDAP/2.6.10
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns
  ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss

libssh2/1.11.1 appears on the first line, which means this curl delegates scp and sftp to libssh2. Even if you never run curl directly, HTTP libraries in many languages call libcurl underneath.

To see which file is actually linked, one more line does it.

$ ldd $(which curl) | grep ssh
	libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1

$ dpkg -l | grep libssh2
ii  libssh2-1t64:amd64  1.11.1-1ubuntu0.26.04.3  amd64  SSH2 client-side library

One trap deserves a warning. The "1.11.1" in curl -V is the upstream version string, and it does not move when a distribution backports fixes. The package version is the honest number. In the example above, the trailing .3 in 1.11.1-1ubuntu0.26.04.3 means the third security revision. Judge by "1.11.1" alone and you will overstate the risk; assume "it's Ubuntu, so it's fine" and you will understate it. The package version is what to look at.

For keeping an ongoing inventory across self-built containers and Windows binaries, see our free OSS dependency scanner. Indirectly included components like this one behave the same way as the Netty vulnerabilities: human memory does not keep up.

What each of the July 24 four actually does

CVE-2026-66035: heap metadata overwritten before authentication

This is the earliest one to land. SSH picks a cipher when a connection opens, and one of the options is Encrypt-then-MAC, where the integrity value is appended after encryption. According to the NVD entry, on that path a server can declare a packet length smaller than one cipher block, after which nearly a full block more than the allocation gets copied in. What sits there is the neighbouring chunk's size field. It happens before login, so neither key nor password is a barrier. The fix is commit 42e33d8.

CVE-2026-66033: picking a cipher is enough to kill the client

Also pre-authentication. When AES-GCM ciphers are negotiated, a subtraction in the length calculation can go below zero, and a negative length is handled as an enormous positive number, so a copy of nearly the maximum possible size runs and the process dies on the spot. This is less "corrupted" than "reliably terminated": a malicious server can pick which clients it stops. In practice that looks like a nightly batch job dying at the same point every time. The fix is commit a2ed82d.

CVE-2026-66032: the same memory released twice right after opening SFTP

This one carries the highest 3.1 score of the ten, at 8.8. When a client asks to open a file over SFTP and the server answers "success" in a particular shape, the response buffer is released, and then the same pointer is released a second time. The NVD entry describes using that state to confuse the allocator's bookkeeping so that separate allocations end up overlapping. It requires an established SFTP session, that is, a successful login. But a file-transfer partner is precisely the place you log into every night with a valid key. The fix is commit 5e47761.

CVE-2026-66034: listing public keys leaks memory contents

This sits in the publickey subsystem, which retrieves the list of public keys registered on a server. The parser takes the comment length from the response at face value and advances, so a value longer than the real data reads into adjacent memory. Per NVD, what leaks are heap pointers, which hands an attacker the layout they need to aim the next step. The error cleanup path additionally frees an uninitialized pointer. The fix is commit a13bb6c.

The six that came earlier, in May and June

July's four are not an outlier. The same "a server breaks its client" pattern has been arriving since May.

CVE-2026-55200: no upper bound on a length field, ending in code execution

At 9.2 under CVSS 4.0, this is the heaviest of the ten. The transport read path enforced no upper bound on the packet length a peer declares. NVD states plainly that remote attackers can corrupt heap memory and achieve remote code execution. It is also the only one of the ten with a record of published exploit code among its references. The fix is commit 7acf3df.

CVE-2026-55199: an extension count of 0xFFFFFFFF stops the client dead

During key exchange the server announces how many extensions follow. Set that to the maximum value and the client spins that many times. NVD notes it burns CPU for over 60 seconds, and that the session timeout does not apply to a CPU-bound loop. Pre-authentication. The fix is commit 1762685.

CVE-2025-15661: resolving a symbolic link reads past the buffer

This is in the response handling for SFTP READLINK and REALPATH. The returned length is copied without validation, so heap contents leak or the process crashes. NVD says a man-in-the-middle can trigger it too, so a malicious server is not the only precondition. The fix is commit 2dae302.

CVE-2026-58050 and CVE-2026-58051: two more in the key listing

Both come from the same public key listing code as July's CVE-2026-66034. CVE-2026-58050 overflows the multiplication that sizes the attribute array, producing an undersized buffer on 32-bit platforms. CVE-2026-58051 grows the list without zeroing the new entries, so a parse failure that reaches cleanup frees a pointer whose contents were never set. That is three findings from one feature in three months.

CVE-2026-7598: username length arithmetic overflows

The oldest of the ten, disclosed May 1: the password authentication path overflows when computing username and password lengths. Red Hat has published its own advisory for this one, and Ubuntu shipped a fix on May 5. The fix is commit 256d04b.

Why "just upgrade" is not something we can write here

This is where libssh2 gets awkward. Walk down the libssh2 release list: 1.11.0 in May 2023, 1.11.1 on October 16, 2024, and nothing since. The project's own site still reads "libssh2 1.11.1, released on 2024-10-16."

Development itself has not stopped. Every one of the ten has a corresponding commit or pull request merged upstream. The result is that the source is fixed while the newest shipped artifact is nearly two years old. Ten advisories say "through 1.11.1" and there is no version number to point at as the answer. That is what makes this different from an ordinary CVE story.

Distributions fill the gap. They keep the version string at 1.11.1 and cherry-pick the fixes. Opening the package changelog on Ubuntu 26.04 makes that visible.

$ zcat /usr/share/doc/libssh2-1t64/changelog.Debian.gz | head -30
libssh2 (1.11.1-1ubuntu0.26.04.3) resolute-security; urgency=medium

  * SECURITY UPDATE: Multiple security issues in publickey
    - debian/patches/CVE-2026-58051.patch: fix potential OOB read in
      libssh2_publickey_list_fetch().
    - debian/patches/CVE-2026-58050.patch: cap variable-length packet element
      sizes.
    - CVE-2026-58050
    - CVE-2026-58051

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Tue, 07 Jul 2026 14:23:05 -0400

June's batch went in on July 7, and the June 29 entry before it covers CVE-2025-15661, CVE-2026-55199 and CVE-2026-55200. The four disclosed on July 24 are not in there. As of this writing the newest libssh2 package offered on Ubuntu 26.04 is 1.11.1-1ubuntu0.26.04.3, and its contents stop at July 7.

Distribution status as of July 29

For Debian, the official tracker publishes the state of each issue. The Ubuntu 26.04 column comes from reading the package changelog shown above on a live machine.

Three things to read out of that. First, the July 24 four are absent from every version people actually run; the only place they are fixed is Debian unstable, which changes daily and is not a deployment target. Second, Debian 12 (bookworm) is untouched even for the June batch — the tracker records those as open. Third, the two from June 28 are still "undetermined" on the Debian side while Ubuntu shipped them on July 7, so the two distributions have reached different conclusions about the same defects.

For RHEL-family systems, Red Hat has published its page for CVE-2026-7598; check each vendor's own advisories for the July batch.

What to do while you wait for your distro's update

With no version to upgrade to, the work is to reduce exposure and to watch.

Start by confirming that distribution updates are actually landing — apt list --upgradable and friends. A host where automatic updates quietly stopped months ago is the worst case here. The three June issues are already shipping almost everywhere, so if those are not applied, fix that before worrying about July.

Next, narrow where you connect to. All ten require that you initiate the connection. If every destination is a server you control, the preconditions get much harder to meet. The dangerous shapes are an SFTP endpoint operated by someone else, a URL supplied from outside and passed straight through, and a screen where users type in a hostname for the server to connect to. That last one is the worst possible combination with this set of bugs, because an attacker only has to enter the address of their own machine.

Third, avoid libssh2 where you can. If file transfers run through curl or your own code, switching to invoking the OpenSSH sftp / scp commands takes you out of range of all ten. libgit2 can likewise be built to shell out to OpenSSH instead. A component chosen for speed or convenience is now on the side where releases have stalled, and simply knowing that changes the calculus.

Finally, if you ship libssh2 inside your own product, distribution updates will never reach you. You either backport the commits yourself or wait for a release. The same "the component itself has stalled" situation showed up with the Bouncy Castle crypto library and with the node-forge signature verification flaw.

FAQ

Q. We do not expose any SSH server. Does this apply to us?

Yes. What matters is not whether you publish a server but whether your programs connect out to someone else's SSH or SFTP server. File exchange with partners, pulls from external repositories, backups pushed offsite — any outbound connection puts you in scope.

Q. Is this the same as an OpenSSH vulnerability?

No. The ssh command and the OpenSSH server are a separate implementation. Updating OpenSSH does not close libssh2's holes, and conversely, code that shells out to OpenSSH is outside the scope of all ten.

Q. curl -V says 1.11.1. Does that mean all ten are open?

No. That string is the upstream version and does not reflect distribution backports. Look at the package version instead (for example 1.11.1-1ubuntu0.26.04.3). As the table shows, the typical state right now is "June and earlier applied, the four from July 24 still open."

Q. Is anyone actually exploiting these?

As of this writing, none of the ten appear in the CISA Known Exploited Vulnerabilities catalog. That said, CVE-2026-55200 carries a reference recording published exploit code. Observed exploitation and the existence of a working tool are different claims; the second one is already true.

Q. Does this mean the project is abandoned?

No. Fixes and pull requests keep landing, so the code is alive. What has stalled is the publishing of releases. We could not find any published schedule for the next version as of this writing.

Revision history

Sources

• ▸ NVD - CVE-2026-66035 (pre-authentication heap buffer overflow, published July 24, 2026)
• ▸ NVD - CVE-2026-66033 (pre-authentication integer underflow, AES-GCM)
• ▸ NVD - CVE-2026-66032 (double free in sftp_open(), CVSS 3.1 of 8.8)
• ▸ NVD - CVE-2026-66034 (missing bounds check in the publickey subsystem)
• ▸ VulnCheck - libssh2 heap buffer overflow via ETM cipher negotiation (reporter of CVE-2026-66035)
• ▸ VulnCheck - libssh2 double-free heap corruption via sftp_open (reporter of CVE-2026-66032)
• ▸ libssh2 official site ("libssh2 1.11.1, released on 2024-10-16")
• ▸ GitHub - libssh2 releases (1.11.1 of October 16, 2024 is the newest)
• ▸ Debian Security Tracker - libssh2 (per-release status)
• ▸ Ubuntu - changelog for libssh2 1.11.1-1ubuntu0.26.04.3 (three security revisions: May 5, June 29, July 7)
• ▸ Red Hat - CVE-2026-7598
• ▸ PHP Manual - ssh2 extension requirements (libssh2 1.2 or newer)
• ▸ libgit2 - SSH provided by libssh2 or by invoking OpenSSH