CVE-2026-3731

What it actually does

libssh versions up to and including 0.11.3 contain an out-of-bounds read in the SFTP extension handling code, specifically in sftp_extensions_get_name and sftp_extensions_get_data in src/sftp.c. A remotely influenced idx value can cause libssh to read outside the expected SFTP extension array or buffer. The published impact is limited to availability: exploitation can destabilize or crash the process using libssh, disrupting SFTP or applications embedding libssh. The available CVSS vector does not indicate confidentiality or integrity impact, and no public exploit maturity is reported.

Why it matters to the business

Applications, appliances, or services that embed vulnerable libssh versions may be remotely disrupted if they process crafted SFTP extension data. For organizations relying on libssh-backed file transfer, automation, backups, deployment workflows, managed devices, or embedded products, this can cause failed transfers, service restarts, operational delays, and support incidents. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low and flat EPSS activity, and has no reported exploit maturity, so it is lower urgency than actively exploited remote code execution flaws but should still be remediated during normal patch cycles, especially on internet-facing SFTP services or widely distributed products.

How an attack unfolds

An attacker first identifies a reachable service, client workflow, or product that uses libssh 0.11.3 or earlier for SFTP functionality. The attacker then interacts with the SFTP extension negotiation or extension metadata path in a way that causes an invalid or unexpected extension index value to be processed. When the vulnerable code calls sftp_extensions_get_name or sftp_extensions_get_data with that index, libssh performs an out-of-bounds read instead of rejecting the request safely. Depending on how the embedding application handles the invalid memory access, the process may crash, terminate the SFTP session, restart under a supervisor, or experience degraded availability. There is no current public indication that this vulnerability enables code execution or data theft.

How to fix it

Upgrade libssh to a fixed release: 0.11.4 or 0.12.0, or apply the upstream patch identified as commit 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60 if consuming source directly. Rebuild and redeploy any applications that statically link libssh, and restart services that dynamically load the library so the fixed version is actually in use. Where immediate patching is not possible, reduce exposure by disabling SFTP features not required for operations, restricting SFTP access to trusted networks or authenticated users where supported, placing affected services behind access controls, and monitoring for repeated SFTP-triggered crashes. Package-based deployments should use vendor-fixed packages once available, because downstream distributions may backport the patch without changing the apparent upstream version number.

How to confirm the fix worked

Confirm the deployed libssh version is fixed by checking package manager output, build manifests, container image SBOMs, pkg-config data, application dependency listings, and runtime library resolution with tools such as ldd where appropriate. Validate that libssh reports 0.11.4, 0.12.0, or a vendor build containing upstream commit 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. For statically linked binaries, confirm the application was rebuilt after the patched library was introduced; simply updating the shared library may not be sufficient. After remediation, restart affected services and verify that SFTP workflows still operate normally. Exposure validation should include inventorying internet-facing SSH/SFTP services, embedded products, containers, appliances, and internal automation tools that include libssh rather than OpenSSH alone.

Typical attack path

1. Identify software or network services that expose SFTP functionality or initiate SFTP sessions using libssh 0.11.3 or earlier.
2. Establish a remote SFTP interaction with the vulnerable component, either as a client to a malicious server or as a server receiving crafted SFTP input, depending on how libssh is embedded.
3. Send crafted SFTP extension-related data that influences the extension index handled by libssh.
4. Trigger sftp_extensions_get_name or sftp_extensions_get_data with an out-of-range idx value.
5. Cause an out-of-bounds read that may crash or destabilize the application process.
6. Repeat the interaction to create a denial-of-service condition against affected SFTP-dependent functionality.

How to detect it

To determine whether this was already exploited, review logs and telemetry from services and applications that use libssh for SFTP. Focus on crashes, abnormal terminations, repeated connection resets, and service restarts associated with SFTP activity, especially after 2026-03-08. Useful sources include system logs, application logs, SSH/SFTP service logs, container runtime logs, process supervisor logs, kernel crash logs, core dump metadata, EDR process telemetry, and network flow records for repeated short-lived SFTP sessions. In forensic artifacts, look for stack traces or symbols referencing sftp_extensions_get_name, sftp_extensions_get_data, src/sftp.c, or libssh immediately before a segmentation fault or abort. Network evidence alone is unlikely to conclusively prove exploitation because the vulnerability is in protocol handling and no unique public exploit payload is known; correlate suspicious SFTP sessions with process crashes or restarts. There are no known named threat actors, ransomware campaigns, or public exploit kits associated with this issue at this time.

• sftp_extensions_get_name
• sftp_extensions_get_data
• src/sftp.c
• libssh.so
• libssh-0.11.3
• Segmentation fault
• segfault
• SIGSEGV
• core dumped
• systemd-coredump
• Process terminated by signal 11
• libssh

What your security team should do

• Inventory all products, appliances, containers, and internally built applications that use libssh, with priority on systems exposing or consuming SFTP over untrusted networks.
• Patch or upgrade affected libssh deployments to 0.11.4, 0.12.0, or a vendor-backported fixed build.
• Rebuild and redeploy statically linked applications and container images that bundle libssh 0.11.3 or earlier.
• Restrict network access to SFTP services using vulnerable libssh until patching is complete, especially where services are internet-facing.
• Enable crash monitoring and alerting for libssh-backed services to detect repeated SFTP-triggered failures.
• Review core dumps, system logs, and service supervisor logs for crashes involving libssh SFTP extension functions after the publication date.
• Track vendor advisories for downstream products that embed libssh, because the vulnerable library may be present even when libssh is not installed as a standalone package.