CVE-2026-58050

What it actually does

libssh2 versions through 1.11.1 can trust an attacker-supplied 32-bit attribute count returned by an SSH server's publickey subsystem. On 32-bit client builds, the calculation for allocating an array of libssh2_publickey_attribute structures can integer-overflow, producing an undersized heap allocation. The subsequent attribute parsing loop then writes past the allocated buffer, causing heap memory corruption. Practical outcomes include client process crash, denial of service, and potentially code execution in the context of the affected client process depending on allocator behavior, compiler hardening, and surrounding application design.

Why it matters to the business

Applications, appliances, build systems, file-transfer tools, embedded devices, and other software that use libssh2 as an SSH client may be crashed or potentially compromised if they connect to a malicious or compromised SSH server. The risk is highest for 32-bit deployments and for automated systems that connect outbound to externally controlled or partner-managed SSH/SFTP infrastructure. This issue is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but it should still be prioritized where libssh2 is embedded in unattended workflows because exploitation can be triggered remotely by a server response.

How an attack unfolds

An attacker first needs to operate, compromise, or impersonate an SSH server that a vulnerable libssh2-based client will contact. When the client invokes the SSH publickey subsystem, the malicious server returns a crafted response containing an excessively large 32-bit attribute count. On a 32-bit client, libssh2 multiplies that count by the size of a publickey attribute structure without validating that the multiplication fits. The wrapped result causes libssh2 to allocate a buffer smaller than required. The same server response then drives the parser to write attribute entries beyond the end of that buffer. The most likely observable result is a crash of the client process; in less constrained conditions, the heap corruption may be shaped toward execution of attacker-controlled code within the client application's privileges.

How to fix it

Upgrade libssh2 to a vendor-fixed release as soon as one is available, or apply the relevant distribution/vendor backport that adds bounds checking for the publickey-subsystem attribute count and allocation size. Because the provided data does not list fixed versions, treat libssh2 through 1.11.1 as affected until your operating system, package vendor, or application vendor confirms a patched build. Prioritize 32-bit builds and statically linked applications, since they may not be fixed by updating only the system shared library. If immediate patching is not possible, reduce exposure by preventing vulnerable clients from connecting to untrusted SSH servers, allowlisting outbound SSH/SFTP destinations, disabling features that use the SSH publickey subsystem where feasible, and running libssh2-based clients with least privilege, sandboxing, and process isolation.

How to confirm the fix worked

Confirm exposure by inventorying all libssh2 usage, including operating system packages, bundled libraries, containers, firmware, appliances, language bindings, and statically linked binaries. Identify versions reported as libssh2 1.11.1 or earlier and determine whether they are 32-bit builds. Validate remediation by confirming the runtime library version or vendor package changelog includes the fix, then restart dependent services and applications so they load the patched library. For dynamically linked binaries, use package manager queries, SBOM data, ldd or equivalent dependency inspection, and runtime library path checks. For statically linked software, verify the application vendor has rebuilt against a fixed libssh2. Where safe, use a controlled regression test with a malformed publickey-subsystem response or a vendor-provided test case to confirm the client rejects oversized attribute counts without crashing.

Typical attack path

1. Identify software or appliances that use libssh2 as an SSH/SFTP client and perform publickey-subsystem operations.
2. Gain control of an SSH server the vulnerable client is expected to contact, or position a malicious SSH server where the client will connect.
3. Complete enough SSH negotiation for the client to request or use the publickey subsystem.
4. Return a crafted publickey-subsystem response with an attacker-controlled attribute count large enough to overflow allocation arithmetic on 32-bit builds.
5. Cause libssh2 to allocate an undersized heap buffer and then parse more attributes than fit in that buffer.
6. Trigger client-side heap corruption, typically resulting in process termination and potentially enabling further exploitation depending on runtime protections.

How to detect it

Look for evidence of vulnerable clients connecting to suspicious, newly observed, or untrusted SSH servers, followed by crashes or heap-corruption reports in the client process. Useful sources include endpoint crash logs, application logs, systemd journal entries, core dump indexes, EDR process telemetry, network flow logs for outbound TCP/22 or alternate SSH ports, proxy/firewall logs, and SSH client debug logs if available. Triage crashes that occur during or immediately after publickey-subsystem operations, particularly in software known to link against libssh2. On Linux and Unix-like systems, review coredumpctl, /var/log/syslog, /var/log/messages, kernel Oops logs, allocator diagnostics, and application-specific logs for heap corruption signatures. On Windows, review Windows Error Reporting, Application event logs, EDR crash telemetry, and application dump files for libssh2.dll in the loaded module list. Because exploitation is server-driven and does not require a distinctive file drop, prioritize behavioral correlation: vulnerable libssh2 version, 32-bit process architecture, outbound SSH session to an unusual server, and immediate memory-corruption crash.

• libssh2_publickey_attribute
• libssh2_publickey_list_fetch
• libssh2_publickey_init
• publickey subsystem
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• malloc(): corrupted top size
• malloc(): memory corruption
• free(): invalid next size
• double free or corruption
• corrupted size vs. prev_size
• glibc detected
• libssh2.dll
• libssh2.so.1
• coredumpctl

What your security team should do

• Prioritize inventory of libssh2 clients in 32-bit systems, embedded devices, network appliances, CI/CD tooling, file-transfer automation, and products that connect to external SSH/SFTP servers.
• Upgrade or apply vendor backports for all libssh2 builds through 1.11.1 once fixed packages are available; do not assume container images or statically linked binaries inherit host-level fixes.
• Restrict outbound SSH/SFTP connections from automated systems to approved destinations and monitor for new or unexpected SSH server endpoints.
• Review crash telemetry for libssh2-based applications, especially crashes occurring immediately after SSH publickey-subsystem activity or connections to unfamiliar SSH servers.
• Run vulnerable clients with least privilege and isolation to reduce the consequence of a successful heap-corruption exploit.
• Ask third-party software and appliance vendors whether their products embed libssh2 through 1.11.1 and whether they use 32-bit builds or publickey-subsystem functionality.