Exploits

libssh2 CVE-2026-55200 Critical Heap Overflow Flaw

Published  ·  5 min read

libssh2

Proof of concept released to the public for CVE-2026-55200 – an extremely critical vulnerability in libssh2 where a malicious SSH server can cause memory corruption in the connecting client. Zero authentication required. Zero user interaction required.

The bug affects every libssh2 release up to and including 1.11.1. It carries a CVSS 4.0 score of 9.2.

libssh2 is a client-side SSH library, not a server. That distinction matters. It is embedded in curl, Git, PHP, backup agents, firmware updaters, and a long tail of appliances. Anything that links it and reaches out to an untrusted SSH endpoint is a potential target.

Many of those copies are statically linked. A distro package update will not touch them. You may not know they are there.

How the Bug Works

The libssh2 CVE-2026-55200 heap overflow lives in ssh2_transport_read() in transport.c, the function that parses incoming SSH packets during the handshake. 

It read the attacker-controlled packet_length field and rejected only values below 1.  It never enforced an upper bound.

The size calculation adds packet_length to a couple of small values using 32-bit arithmetic. A length of 0xffffffff wraps around to a tiny number. libssh2 then allocates a buffer sized for the tiny number, while later code writes the full, oversized packet into it.

The result is an out-of-bounds heap write, classed as CWE-680, integer overflow to buffer overflow. That is a classic primitive for code execution.

The fix adds the missing check, rejecting any packet_length above LIBSSH2_PACKET_MAXPAYLOAD before the math runs.

A Familiar Story

libssh2 has tripped over this before. In 2019, it shipped version 1.8.1 to fix a batch of nine flaws led by CVE-2019-3855. That was a near-identical integer overflow in its transport read that also let a malicious server run code on a connecting client.
Seven years later, the same class of bug is back in the same code.

The Timeline

Security researcher Tristan Madani reported the issue. Maintainers merged the patch through pull request #2052 on June 12. VulnCheck published the CVE on June 17.

A public proof-of-concept has been published in "exploitarium," a GitHub archive of exploit code. The author says entries were posted without prior reporting. The archive contains a locally verified SSH trigger scaffold and a controlled local RCE harness for the libssh2 bug, not a turnkey remote exploit.

Reliable code execution against a live application would still depend on the target binary, allocator behavior, mitigations, and how the software embeds libssh2.

The Context

The author concedes the archive went out incomplete, with some entries weak and AI driving the fuzzing. As of now, CISA's exploitation rating for the CVE still reads none. No in-the-wild use has been reported.

What to Do

There is no fixed libssh2 release yet. The patch sits in the mainline source. A tagged release is still being prepared. Linux distributions and downstream projects are backporting it themselves. Debian, for one, already has a repaired build in testing.

NHS England Digital has issued an advisory urging affected organizations to update:

1. Inventory everything that links libssh2. This includes static or bundled copies that package managers will not flag. curl, Git, and PHP deployments are common carriers. You may have libssh2 embedded in appliances, backup agents, and firmware updaters.

2. Deploy a build with commit 97acf3d included. This may be a distro backport or patched source build. Monitor your vendor’s security advisory feed for release information.

3. Control outbound SSH traffic. As far as a solution is available, control your outbound SSH traffic to your trusted servers and validate their keys.

4. Focus on high-risk clients. Focus on the clients that have remote access to SSH hosts or name which can be taken advantage of by the attacker.

5. Notice abnormal events. Notice large packets size and client crash events.

6. Patch the rest of the batch too:
CVE-2026-55199 (CVSS 8.2): Denial of service that traps a connecting client in a CPU loop via a bogus extension count.
CVE-2025-15661 (CVSS 8.3): SFTP heap over-read.

The Core Issue

The libssh2 CVE-2026-55200 heap overflow is a pre-auth memory-corruption bug in code that ships inside more clients and appliances than anyone has fully mapped.

The open questions are how fast someone turns the local harness into a dependable remote exploit, and how many bundled copies stay vulnerable because no one remembers they shipped libssh2 inside.

The Bottom Line

The libssh2 CVE-2026-55200 heap overflow is a critical vulnerability with a public PoC. No patch release yet. Statically linked copies are everywhere. Inventory everything that links libssh2. Apply commit 97acf3d. Restrict outbound SSH connections.

And remember: a malicious SSH server can crash your client and maybe run code.

FAQ Section

What is CVE-2026-55200?

CVE-2026-55200 is a critical heap overflow bug in libssh2. An attacker controlled SSH server will cause memory corruption in the connecting client machine, which can be exploited to execute code.

What version of libssh2 is vulnerable?

All the versions before and including 1.11.1 are vulnerable. There is no patch available as of yet.

How does the attack take place?

A malicious packet is created with packet_length variable that is manipulated in such a way that causes an integer overflow resulting in a small sized buffer being allocated with huge data, creating a heap overflow.

Is this vulnerability being exploited in the wild?

Not yet. CISA's exploitation rating for the CVE still reads none. No in-the-wild use has been reported.

What should I do?

Inventory everything that links libssh2, including statically linked copies. Apply commit 97acf3d. Restrict outbound SSH connections to trusted servers.

Is there a fixed libssh2 release?

Not yet. The patch is in mainline but a tagged release is still being prepared. Distributions are backporting the fix themselves.

Source: The Hacker News
Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067