CVE-2026-58051

What it actually does

libssh2 clients through 1.11.1 can mishandle memory while parsing responses from an SSH server's publickey subsystem. The library expands a publickey list with realloc-like behavior but does not initialize newly added entries before parsing completes. If a malicious or compromised SSH server sends a malformed response that forces parsing to fail, cleanup code may attempt to free an uninitialized, attacker-influenceable attrs pointer. The most likely result is client-side process termination or memory allocator abort; under favorable heap conditions, limited memory corruption may be possible, though the CVSS vector indicates high attack complexity and primarily availability impact.

Why it matters to the business

Applications, automation jobs, deployment tooling, file-transfer workflows, scanners, or embedded products that use libssh2 to connect to SSH servers could crash when connecting to a malicious or compromised server. This can interrupt operational workflows that rely on outbound SSH connections, especially where systems connect to third-party, user-supplied, or dynamically discovered SSH endpoints. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity, so urgency is lower than for actively exploited vulnerabilities; however, exposure should still be reduced because exploitation requires only that a vulnerable client connect to an attacker-controlled SSH service.

How an attack unfolds

An attacker first obtains a position where they can act as the SSH server reached by a vulnerable libssh2-based client. This could be done by operating a malicious server, compromising a legitimate SSH server, redirecting traffic through DNS or configuration manipulation, or targeting software that connects to user-supplied SSH endpoints. When the client negotiates the SSH session and interacts with the publickey subsystem, the server returns a malformed publickey response crafted to make libssh2 grow its internal publickey list and then fail during parsing before all new entries are initialized. The client enters the cleanup path and calls the publickey-list free routine, which may treat uninitialized memory as a valid attrs pointer and pass it to the allocator. Depending on heap state and platform allocator behavior, the vulnerable client process may abort, crash with a segmentation fault, or exhibit memory corruption. Reliable code execution is not established from the provided information and would likely be difficult; denial of service against client-side software is the primary practical outcome.

How to fix it

Upgrade libssh2 to a vendor-fixed release as soon as one is available, or apply the relevant operating-system or distribution backport that fixes this memory-initialization flaw. Because no exact fixed version was provided, treat libssh2 versions through 1.11.1 as affected until the package maintainer documents a patched build. Rebuild or redeploy statically linked applications, containers, appliances, and language bindings that bundle libssh2 rather than relying only on host package updates. Where immediate patching is not possible, reduce exposure by preventing vulnerable clients from connecting to untrusted or user-supplied SSH servers, enforcing strict host-key verification, allowlisting approved SSH destinations, restricting outbound SSH from automation environments, disabling unused publickey-subsystem functionality where supported, and running libssh2-consuming tools with least privilege and process isolation.

How to confirm the fix worked

Confirm exposure by inventorying libssh2 versions with package managers, SBOM tooling, container scans, and binary dependency checks. Look specifically for libssh2 versions up to and including 1.11.1, including statically linked copies inside applications. On Linux, use commands such as package-manager queries, ldd against relevant binaries, strings on statically linked binaries, and container image scans to identify embedded versions. Validate remediation by confirming the installed or bundled libssh2 build is documented by the vendor or distribution as patched, then restart or redeploy dependent services and jobs. For higher assurance, run regression tests that exercise SSH publickey-subsystem interactions against a controlled malformed-response test server under AddressSanitizer or equivalent memory diagnostics and confirm there is no invalid free, allocator abort, or crash.

Typical attack path

1. Identify software or automation that uses libssh2 through 1.11.1 and connects outward to SSH servers.
2. Place or compromise an SSH server that the vulnerable client will connect to, or influence the client to connect to an attacker-controlled SSH endpoint.
3. Offer or respond through the SSH publickey subsystem during the client session.
4. Send a malformed publickey response that causes parsing failure after the publickey list has been reallocated but before new entries are initialized.
5. Trigger the libssh2 cleanup path so libssh2_publickey_list_free attempts to free an uninitialized attrs pointer.
6. Cause the client process to crash or potentially corrupt memory, disrupting the application or job that embedded libssh2.

How to detect it

To determine whether this was already exploited, focus on client-side evidence rather than server-side compromise. Review logs and telemetry from applications, automation runners, file-transfer tools, scanners, and services that use libssh2 for crashes occurring immediately after outbound SSH sessions, especially to newly observed, external, user-supplied, or unusual SSH servers. Useful sources include application logs, system journals, kernel crash logs, core dumps, endpoint detection telemetry, process crash reports, container termination reasons, CI/CD job logs, egress firewall logs, proxy or NetFlow metadata for TCP/22, DNS logs, and SSH client debug logs where available. In core dumps or stack traces, look for allocator errors or segmentation faults involving libssh2 publickey cleanup, particularly frames or symbols such as libssh2_publickey_list_free. Correlate crash timestamps with outbound connections to SSH servers and host-key changes. Indicators are likely to be behavioral because the malformed SSH response may not be logged by default, and successful exploitation may leave only a client crash or memory-corruption artifact.

• libssh2_publickey_list_free
• free(): invalid pointer
• free(): invalid size
• munmap_chunk(): invalid pointer
• double free or corruption
• malloc(): memory corruption
• Segmentation fault
• SIGSEGV
• SIGABRT
• AddressSanitizer: attempting free on address which was not malloc()-ed
• AddressSanitizer: heap-use-after-free
• AddressSanitizer: SEGV
• invalid free
• publickey subsystem
• SSH publickey subsystem
• core dumped

What your security team should do

• Prioritize inventory of internet-facing, automation, CI/CD, backup, monitoring, file-transfer, vulnerability-scanning, and orchestration tools that initiate outbound SSH connections using libssh2.
• Patch or replace libssh2 versions through 1.11.1 when a vendor-fixed build or distribution backport is available, and rebuild statically linked applications and containers.
• Until patched, restrict vulnerable clients to known-good SSH destinations using network egress controls and strict host-key verification.
• Review workflows that accept user-supplied SSH hostnames, repository URLs, deployment targets, or scanning targets, because these increase the chance of connecting to an attacker-controlled SSH server.
• Enable core-dump capture and crash telemetry for libssh2-consuming services to support detection of allocator aborts or segmentation faults after SSH connections.
• Hunt for recent crashes in software that embeds libssh2, especially crashes occurring immediately after outbound SSH connections to new or unusual servers.
• Monitor vendor advisories for the exact fixed libssh2 release and update vulnerability-management policies once fixed package versions are published.
• Because EPSS is low, there is no KEV listing, and no known ransomware use is reported, schedule remediation according to normal patch SLAs unless the organization connects to untrusted SSH servers at scale, in which case accelerate mitigation.