SSH connections are normally associated with protecting remote administration and file transfers. However, a new security advisory shows that the software initiating an SSH or SFTP connection can still be placed at risk when the server on the other end is malicious or compromised.
Four high-severity vulnerabilities have been identified in libssh2, a widely used C library that adds SSH2 support to applications. Successful exploitation could lead to crashes, memory corruption and, in the most serious circumstances, potential code execution on the client system connecting to the hostile server.
What Is libssh2?
libssh2 is not a standalone SSH application that most users intentionally open. It is a software library incorporated into other products that need SSH or SFTP functionality.
Remote administration utilities, automated deployment systems, backup platforms, file-transfer applications and SFTP clients may all rely on libssh2 behind the scenes. This means an organisation could be using the library without seeing its name anywhere in the main application interface.
That hidden dependency is one reason the vulnerabilities deserve attention. Updating a familiar SSH client may not be enough when the same library is separately bundled inside backup agents, automation software or proprietary business applications.
The Unusual Risk Comes from the Server Side
In a conventional security discussion, organisations are usually warned about attackers connecting to exposed SSH servers.
These vulnerabilities reverse that situation. The potentially affected system is the client that initiates the connection, while the attacker controls—or has compromised—the SSH or SFTP server.
A malicious server can send specially manipulated responses during the connection or file-transfer process. If the client application processes those responses incorrectly, libssh2 may read or write outside the memory it was assigned, free memory improperly or crash before authentication is completed.
This means that merely restricting login credentials does not address every scenario. Two of the reported flaws can be triggered before the client has authenticated, while another becomes relevant after an SFTP session has been established.
CVE-2026-66032: A Double-Free Flaw in SFTP Handling
The most critical issue is CVE-2026-66032, which carries a CVSS 4.0 base score of 8.7.
The vulnerability affects the sftp_open() function within src/sftp.c. It occurs after an authenticated client has opened an SFTP session and sends an SSH_FXP_OPEN request.
A malicious server can return an improperly constructed success response that causes libssh2 to mishandle memory. The advisory describes this as a double-free weakness, meaning the software may attempt to release the same memory allocation more than once.
In practical terms, incorrectly freeing memory can damage the application's internal memory-management structures. On systems using the glibc heap allocator, the flaw could result in duplicated tcache entries and overlapping memory allocations.
The advisory warns that an attacker may be able to corrupt application memory and potentially overwrite function pointers. That raises the impact beyond a straightforward denial-of-service crash, as control over a function pointer could potentially influence what the affected application executes.
The vulnerability does require the client to authenticate and establish the SFTP session first. Nevertheless, this does not make it harmless. A user may connect to a server believed to be legitimate while the server itself has already been compromised.
CVE-2026-66033: A Client Crash Before Authentication
The second high-severity vulnerability, CVE-2026-66033, also has a CVSS 4.0 score of 8.7.
It affects the ssh2_cipher_crypt() function in src/openssl.c and can be triggered before authentication is completed.
During the SSH handshake, a hostile server can negotiate AES-GCM encryption in a way that triggers an integer underflow during the calculation of a packet's size. That incorrect calculation may cause an out-of-bounds read and result in memcpy() being called with an extremely large size value.
The expected result described in the advisory is an immediate client crash.
The pre-authentication nature of the flaw is particularly important. The client does not need to complete a login or open an SFTP file before being affected. The malicious behaviour can occur during the earlier negotiation stage of the SSH connection.
This could make the issue relevant to automated systems that regularly attempt to connect to configured hosts. If one destination becomes malicious or its DNS, routing or infrastructure is compromised, the client software may encounter the vulnerability before credentials are even accepted.
CVE-2026-66034: Unsafe Length Handling in the Public-Key Subsystem
The third vulnerability is CVE-2026-66034, with a CVSS 4.0 base score of 7.7.
This issue affects libssh2's public-key subsystem. According to the advisory, a malicious server can supply an unsafe length value that causes the parser to read beyond the allocated heap buffer.
Software parsers depend heavily on length values to determine how much data should be read from a packet or buffer. When that value is not validated properly, the application may attempt to access memory beyond the region that actually belongs to the received data.
The advisory also notes a problem in the associated error-handling path, which may attempt to free an uninitialised pointer.
Error handling is supposed to help an application recover safely from unexpected data. In this case, however, the cleanup process could introduce another memory-safety problem when it responds to the malicious input.
The potential outcome is again memory corruption rather than merely a rejected connection.
CVE-2026-66035: Heap Buffer Overflow During Packet Processing
The fourth vulnerability, CVE-2026-66035, also carries a CVSS 4.0 score of 7.7.
It is a pre-authentication heap buffer overflow affecting the fullpacket() function in src/transport.c.
During Encrypt-then-MAC cipher negotiation, a malicious server can send a packet smaller than the negotiated cipher block size. libssh2 may then allocate a buffer that is too small and copy more data into it than the buffer can safely contain.
A heap buffer overflow occurs when an application writes beyond the boundary of a memory allocation. The immediate consequence may be a crash, but the overwritten memory could also affect neighbouring application data.
As with CVE-2026-66033, this vulnerability can be reached before authentication. The attacker therefore does not necessarily need valid credentials or access to an established SFTP session.
Why Memory-Corruption Bugs Are Taken Seriously
All four vulnerabilities involve unsafe memory behaviour in one form or another.
Memory corruption can make an application unstable, terminate a service or damage internal program data. In some situations, carefully controlled memory corruption can also be used to alter program execution.
Not every crash automatically becomes remote code execution. The practical outcome depends on the affected application, operating system, memory allocator, compiler protections and how reliably an attacker can control the corrupted data.
Nevertheless, the possibility of function-pointer overwrites, heap-buffer overflows and overlapping allocations is why the advisory classifies these vulnerabilities as high severity rather than ordinary connection-handling errors.
Backup and Automation Systems May Be Especially Important
The affected library appears in categories of software that frequently run with elevated privileges or access sensitive environments.
A backup platform may have permission to read important files and connect to storage servers. An automated deployment tool may possess credentials for production systems. A remote administration application may run under an account with significant access.
If one of these products bundles a vulnerable libssh2 version, a successful attack may affect more than the individual application process.
Organisations should therefore examine not only interactive SFTP clients used by employees, but also scheduled jobs, backup agents, integration servers and deployment pipelines that establish SSH connections automatically.
The advisory does not provide a complete list of affected products, so identifying exposure will require organisations to inspect their own software inventories and vendor documentation.
Updating the Operating-System Package May Not Be Enough
One of the most important points in the advisory concerns statically bundled copies of libssh2.
Some applications use the shared libssh2 package installed by the operating system. In those cases, updating the system package may resolve the vulnerability for every application that dynamically loads it.
Other products compile or package their own private copy of libssh2. Those applications may continue using the vulnerable code even after the operating system's library has been patched.
The advisory specifically recommends identifying software packages that statically bundle libssh2 because updating the operating-system package alone may not protect every affected application.
This creates an inventory challenge. Security teams need to know not just whether libssh2 is installed as a visible package, but whether it is embedded inside other executables, appliances, containers or vendor products.
Fixes Are Available for All Four Vulnerabilities
The advisory identifies upstream fixes for each flaw.
CVE-2026-66032 is addressed by commit 5e47761, while CVE-2026-66033 is fixed through commit a2ed82d. The patches for CVE-2026-66034 and CVE-2026-66035 are contained in commits a13bb6c and 42e33d8, respectively.
Organisations are advised to update libssh2 to a release containing all four fixes. Where a suitable packaged release is not yet available, the advisory recommends rebuilding the library with the corresponding upstream patches.
Applying only one patch would leave the remaining attack paths open. The safer objective is to ensure that every deployed libssh2 copy includes all four corrections.
What Organisations Should Review
The first step should be identifying where libssh2 is used.
That review should cover operating-system packages, containers, desktop applications, backup software, SFTP tools, deployment platforms and internally developed applications. Vendor-supplied appliances and software packages should also be checked for embedded versions.
Teams should then determine whether each copy is dynamically linked to a system library or statically bundled into the application.
For vendor-managed products, organisations may need to request confirmation that all four CVEs have been addressed. Simply seeing that the operating system is fully patched does not confirm that a third-party product has replaced its internal libssh2 build.
Automated SSH and SFTP jobs also deserve attention because they may connect without direct user supervision. Reviewing their destination servers and temporarily limiting connections to trusted hosts could reduce exposure while patches are being deployed.
Final Thoughts
These four libssh2 vulnerabilities demonstrate that an encrypted protocol does not automatically make every part of the software handling it safe.
SSH may protect data travelling between a client and server, but the client still has to parse messages received from the remote system. When packet lengths, memory allocations or error-handling paths are not validated correctly, a malicious server can turn that trusted connection process against the client itself.
CVE-2026-66032 carries the most serious potential impact because the double-free condition may corrupt memory and overwrite function pointers after an SFTP session is established. CVE-2026-66033 can crash a client during the pre-authentication handshake, while CVE-2026-66034 and CVE-2026-66035 introduce additional out-of-bounds and heap-buffer risks.
The fixes are available, but deployment may be less straightforward than installing one operating-system update. Applications that bundle their own libssh2 copy must be identified and updated separately.
For organisations using SSH and SFTP throughout backup, administration and automation workflows, the safest response is to treat libssh2 as a potentially hidden dependency: locate every copy, verify that all four fixes are included and avoid assuming that a fully patched operating system automatically means every application is protected.
Comments 0