CVE-2026-7598

What it actually does

libssh2 versions up to and including 1.11.1 contain an integer overflow in the user authentication password path, specifically in userauth_password in src/userauth.c. If extremely large username_len or password_len values are processed, internal packet-size calculations can wrap, causing libssh2 to allocate or validate a buffer smaller than required before copying authentication data. In applications where those length values can be influenced remotely, this can lead to memory corruption, process crashes, and potentially limited compromise of confidentiality, integrity, or availability in the process embedding libssh2.

Why it matters to the business

Applications, appliances, agents, backup tools, deployment systems, file-transfer tools, and other products that embed libssh2 may be exposed to remotely triggered crashes or memory corruption during SSH password authentication. The current public exploitation signal is low: EPSS is 0.00466, it is not listed in CISA KEV, it is not marked as ransomware-associated, and no mature public exploit is indicated. However, because libssh2 is commonly embedded as a dependency, exposure may exist in downstream software even where libssh2 is not directly deployed or visible to operators.

How an attack unfolds

An attacker first identifies software that uses vulnerable libssh2 versions for SSH password authentication. The most direct exploitation scenario is an application that accepts or derives SSH usernames or passwords from remote input and passes attacker-controlled length values or oversized authentication fields into libssh2. The attacker submits specially crafted authentication data with lengths large enough to trigger arithmetic wraparound in the libssh2 packet construction logic. Once the overflowed size calculation causes an undersized buffer or incorrect bounds decision, subsequent processing can corrupt memory. The observable outcome is often a crash or denial of service in the application using libssh2; depending on compiler protections, allocator behavior, platform architecture, and how the application embeds the library, more severe memory-corruption outcomes may be possible.

How to fix it

Upgrade libssh2 to a vendor-provided fixed release once available, or apply the upstream patch identified as commit 256d04b60d80bf1190e96b0ad1e91b2174d744b1. Treat libssh2 versions up to and including 1.11.1 as affected. Because no fixed version list was provided, rely on distribution vendor advisories, package changelogs, or source commits to confirm the patch is present. Rebuild and redeploy software that statically links or vendors libssh2, since updating the system library alone will not remediate embedded copies. As defense in depth, enforce strict maximum lengths for SSH usernames and passwords before calling libssh2 authentication APIs, reject oversized or malformed authentication inputs, and ensure compiler hardening options such as stack protection, ASLR, PIE, RELRO, FORTIFY_SOURCE, and allocator hardening are enabled where applicable.

How to confirm the fix worked

Inventory all direct and transitive uses of libssh2, including OS packages, containers, appliances, statically linked binaries, language bindings, vendor-supplied tools, and embedded copies. Confirm that no deployed component is using libssh2 1.11.1 or earlier unless the patch commit 256d04b60d80bf1190e96b0ad1e91b2174d744b1 has been backported. Validate package status using package managers, SBOMs, binary inspection, container scans, and vendor advisories. For source builds, confirm the patched userauth.c logic is present. Functionally test SSH password-authentication paths with oversized username and password inputs in a non-production environment and verify the application rejects the input cleanly without crashing, logging memory errors, or producing sanitizer findings. Monitor after remediation for continued loading of older libssh2 shared objects or bundled libraries.

Typical attack path

1. Identify an internet-facing or remotely reachable product, service, agent, or workflow that uses libssh2 for SSH password authentication.
2. Confirm or infer that the embedded libssh2 version is 1.11.1 or earlier, for example through software banners, package metadata, SBOMs, vendor advisories, or crash behavior.
3. Find an input path where SSH username or password data, or the associated length values, can be influenced remotely.
4. Submit authentication data with abnormally large username or password lengths designed to trigger integer wraparound in libssh2's userauth_password logic.
5. Cause malformed packet construction and memory corruption in the process embedding libssh2.
6. Observe denial of service, instability, abnormal process termination, or, in more favorable conditions for the attacker, attempt further memory-corruption exploitation.

How to detect it

To determine whether this vulnerability was already exploited, review logs and crash artifacts from applications that use libssh2 for SSH password authentication. Focus on abnormal process exits, segmentation faults, heap corruption messages, sanitizer findings, core dumps, and application errors occurring immediately after SSH authentication attempts involving unusually large usernames or passwords. Useful sources include application logs, system journals, syslog, container logs, endpoint detection telemetry, crash dump repositories, package/runtime inventory data, and web/API access logs for services that accept SSH credentials and then initiate libssh2 connections. Investigate repeated crashes in the same process, authentication requests with unusually large credential fields, memory-corruption exceptions referencing libssh2, and stack traces containing userauth_password or libssh2_userauth_password_ex. If core dumps are available, inspect backtraces for libssh2 frames and determine whether attacker-controlled authentication strings were present near the crash. Absence of these artifacts does not prove non-exploitation, especially if crash dumps are disabled or credential fields are not logged.

• userauth_password
• libssh2_userauth_password_ex
• src/userauth.c
• libssh2.so
• libssh2.dll
• libssh2.dylib
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow in userauth_password
• runtime error: unsigned integer overflow
• heap-buffer-overflow
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid next size
• double free or corruption
• Segmentation fault
• SIGSEGV
• core dumped
• libssh2 1.11.1
• libssh2/1.11.1
• 256d04b60d80bf1190e96b0ad1e91b2174d744b1

What your security team should do

• Prioritize inventory of products and services that perform outbound SSH connections using libssh2, especially internet-facing portals, automation platforms, file-transfer systems, backup tools, deployment tooling, and managed appliances.
• Patch or rebuild all software using libssh2 1.11.1 or earlier; where no packaged fixed release exists, apply the upstream patch commit 256d04b60d80bf1190e96b0ad1e91b2174d744b1 or obtain a vendor backport.
• Identify statically linked and vendored copies of libssh2, not just operating-system packages, because downstream software may remain vulnerable after system package updates.
• Add input validation that caps SSH username and password lengths before invoking libssh2 APIs, especially where values originate from remote users, APIs, configuration files, queues, or identity workflows.
• Review crash telemetry and logs for unexplained failures in processes that link libssh2, with emphasis on SSH authentication workflows and oversized credential input.
• Because EPSS is currently low and the issue is not in CISA KEV, handle as priority patching for exposed or dependency-heavy systems rather than emergency incident response unless exploitation indicators are observed.
• Request vendor attestations or SBOM updates for third-party products that embed libssh2 and cannot be directly inspected.