A missing null check in libssh’s SFTP directory listing code lets a malicious server crash clients, but real-world exploitability is extremely constrained. CVE-2026-0968 is an out-of-bounds heap read in sftp_parse_longname(), triggered when an SFTP client processes a crafted SSH_FXP_NAME response with a malformed longname field. Red Hat, which serves as the CNA (CVE Numbering Authority) for this vulnerability, scored it 3.1 (Low), while Amazon Linux independently scored it 4.2 (Medium). Despite claims of a 9.8 Critical NVD score circulating in some scanner outputs, NVD has not published an independent CVSS assessment. The only authoritative scores on record are the vendor-provided ones.

The fix shipped in libssh 0.12.0 and 0.11.4 on February 10, 2026, part of a coordinated batch addressing seven security issues. Every major Linux distribution has already released patches.

Inside the Bug: A Null Pointer Meets Heap Memory

The vulnerability lives in the sftp_parse_longname() function, which processes directory listing responses from SFTP servers. When a client calls an SFTP readdir operation (the protocol equivalent of ls), the server replies with SSH_FXP_NAME messages containing file metadata. Each entry includes a longname field, the human-readable ls -l style output string.

The bug: libssh failed to check whether longname was null before attempting to parse it. A server that omits or malforms this field causes the library to read past allocated heap memory.

The CWE classification is CWE-476 (NULL Pointer Dereference), though functionally the behavior is better described as CWE-125 (Out-of-bounds Read). The practical outcome is an application crash when the read crosses into unmapped memory. Ubuntu’s advisory adds the standard caveat that an attacker could “possibly execute arbitrary code,” but this is boilerplate language. The CVSS impact scores from all assessors reflect no confidentiality or integrity impact, only a low availability impact.

Two upstream commits fix the issue: 796d85f786dff62bd4bcc4408d9b7bbc855841e9 and 212121971fb26e1e00b72bd5402c0454a4d84c03, available in libssh’s git repository. The researcher credited is nevv from CTyun Red-Shield Security Lab, alongside Jakub Jelen, the libssh maintainer at Red Hat. The CVE was reserved on January 14, 2026, reported to Red Hat on February 4, and made public alongside the fix on February 10.

The CVSS Score Gap Tells a Story About Vulnerability Scoring Itself

The most interesting angle of this CVE isn’t the bug itself. It’s the scoring discrepancy. Some vulnerability scanners and third-party databases have flagged CVE-2026-0968 at 9.8 Critical, likely based on automated worst-case analysis. The actual vendor scores paint a different picture:

Assessor	CVSS Score	Severity	Key vector differences
Red Hat (CNA)	3.1	Low	AC:H, UI:R, C:N, I:N, A:L
Amazon Linux	4.2	Medium	AC:H, UI:R, C:L, I:N, A:L
Ubuntu	3.1	Low (priority: Medium)	Same as Red Hat
NVD	Not independently scored	n/a	CNA score displayed

Red Hat’s full vector is CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L. The critical metrics driving the low score are Attack Complexity: High and User Interaction: Required. A hypothetical 9.8 score would require AC:L (Low complexity), UI:N (no interaction), and High impact across all three CIA pillars. Those assumptions simply don’t match this vulnerability’s actual attack chain.

Red Hat evaluates CVEs in the context of how their products actually build and deploy the affected software, factoring in compiler hardening, SELinux policies, and realistic attack paths. NVD, when it does score independently, evaluates worst-case scenarios without product-specific mitigations. Amazon Linux’s slightly higher 4.2 score reflects their assessment that the OOB read could expose some heap memory contents (C:L rather than C:N), a reasonable interpretation given that heap reads can theoretically leak adjacent data.

For security teams, the lesson is clear: a CVSS score without context is noise. Automated scanners that assign worst-case scores without evaluating attack prerequisites create alert fatigue and misallocate remediation effort.

What an Attacker Actually Needs to Exploit This

The attack chain for CVE-2026-0968 is specific and constrained. Here is what is required, step by step:

Step 1: The attacker must control an SFTP server. This means either standing up a malicious server and luring victims to connect, or compromising an existing SFTP server that victims already trust. Both require significant effort.

Step 2: A victim must connect to that server using a libssh-based client. Not just any SSH client. The victim’s application must be linked against libssh (not OpenSSH, not libssh2) and must use libssh’s SFTP subsystem. This rules out the vast majority of SSH connections in a typical environment.

Step 3: The victim must perform a directory listing operation. Connecting alone is not enough. The client must call an SFTP readdir function that triggers the server to respond with SSH_FXP_NAME messages. The server then sends a malformed longname field in that response.

Step 4: The client crashes. The missing null check causes an out-of-bounds heap read. If the read hits unmapped memory, the process segfaults and dies.

This means the attacker cannot reach out and exploit victims. The victim must come to the attacker. SSH’s host key verification provides a natural defense: if an attacker attempts a DNS hijack or man-in-the-middle to redirect an existing SFTP connection, the client will flag the changed host key. Exploitation succeeds only when the victim intentionally connects to an unknown or newly-compromised server.

The heap OOB read is also fundamentally different from a write primitive. Unlike Heartbleed (CVE-2014-0160), where the out-of-bounds read data was transmitted back to the attacker over the network, CVE-2026-0968’s read happens in client-side parsing code. The leaked heap contents are not sent back to the malicious server, making information disclosure effectively impossible in standard configurations. The impact ceiling is denial of service through application crash.

Blast Radius: Where libssh Actually Lives in Your Infrastructure

Understanding who is affected requires knowing where libssh is deployed, and just as importantly, where it is not.

libssh is not the same as libssh2. This is a crucial distinction. libssh2 is the library used by curl and historically by libgit2, with a BSD license and client-only functionality. libssh is a separate LGPL-licensed project supporting both client and server implementations. Red Hat deliberately removed libssh2 from RHEL 8 onward, making libssh the standard SSH library for the entire Red Hat ecosystem.

The three most prominent consumers of libssh are:

KDE desktop environment. The kio_sftp worker in kio-extras uses libssh directly for all sftp:// operations in Dolphin and other KDE applications. This is the largest desktop-facing attack surface. A user clicking a malicious sftp:// link would trigger a directory listing and potentially crash.

Cockpit. Red Hat’s web-based server management console depends on libssh via its cockpit-ssh component, shipped by default on RHEL, Fedora, and CentOS systems.

Ansible (pylibssh). Since ansible.netcommon v3.0.0, libssh is the default SSH transport for network device automation. The ansible-pylibssh Python package bundles libssh directly in its PyPI wheels.

Notably, libssh is not present in minimal container base images. Not in Alpine, not in Ubuntu minimal, not in distroless. It enters container images only when explicitly installed as a dependency. Standard CI/CD runners, Terraform, and most cloud management tools use OpenSSH or libssh2, not libssh. The practical exposure is concentrated on RHEL-family servers running Cockpit, KDE desktops, and Ansible automation infrastructure.

Determining Your Exposure

Here is how to check if your systems or containers are affected:

Check if libssh is installed on a host:

# Debian/Ubuntu

dpkg -l | grep libssh

# RHEL/Fedora/CentOS

rpm -qa | grep libssh

# Check the version of the shared library

find / -name "libssh.so*" 2>/dev/null

Check a container image:

docker run --rm <image> sh -c "find / -name 'libssh*' 2>/dev/null"

Check if Ansible is using pylibssh:

pip show ansible-pylibssh

Check which processes are currently using libssh:

lsof | grep libssh.so

If libssh is present and the version is older than 0.11.4 or 0.12.0, you are running a vulnerable version. If none of your workloads make outbound SFTP connections to untrusted servers, the practical risk is minimal even without patching, but patching is still recommended.

Remediation

The fix landed on February 10, 2026 with the coordinated release of libssh 0.12.0 (new major version with post-quantum cryptography support) and 0.11.4 (stable branch security backport). This CVE was one of seven security issues fixed simultaneously.

Distribution patches rolled out rapidly:

• Fedora 42 and 43: Updated February 13 (FEDORA-2026-0d8264f449)
• Ubuntu: USN-8051-1 on February 18 (noble, jammy, questing), USN-8051-2 on February 23 for older LTS releases under Ubuntu Pro (focal, bionic, xenial)
• Red Hat: RHSA-2026:0428 and RHSA-2026:0431 for RHEL 9.4 and 9.6 EUS
• openSUSE: Factory updated February 14
• Slackware: SSA:2026-047-01 on February 17
• Amazon Linux 2023: Listed as “Pending” as of early April

All libssh versions with SFTP client support are affected. The breadth of Ubuntu’s backports (spanning versions 0.6.3 through 0.11.x) confirms the bug has existed in the codebase for many years. Remediation is straightforward: update to 0.12.0 or 0.11.4 upstream, or apply your distribution’s patched package.

Historical Context: libssh’s SFTP Code Has a Pattern

CVE-2026-0968 is not an isolated incident. The SFTP subsystem in libssh has been a recurring source of memory safety vulnerabilities, reflecting the inherent complexity of parsing untrusted binary protocol messages in C.

CVE-2025-5318, an out-of-bounds read in sftp_handle() due to an incorrect comparison check, is a near-identical class of bug fixed just months earlier in libssh 0.11.2. The simultaneous fix for libssh-2026-sftp-extensions (a read buffer overrun in SFTP extension handling) makes three SFTP memory safety issues in roughly a year.

The broader libssh vulnerability history includes a famous authentication bypass (CVE-2018-10933) where a client could skip authentication entirely by sending SSH2_MSG_USERAUTH_SUCCESS to the server, and a heap buffer overflow during rekeying (CVE-2021-3634) that could cause reads and writes beyond buffer limits. A 2019 Mozilla MOSS-funded security audit by Cure53 produced 133 patches across 72 files, suggesting the codebase’s security posture has improved but remains an area requiring ongoing attention.

In the broader SSH library ecosystem, libssh2 had nine CVEs simultaneously disclosed in March 2019, including multiple OOB reads in SFTP packet parsing. CVE-2019-13115 in libssh2, an integer overflow leading to an OOB read during Diffie-Hellman key exchange, was also triggered by connecting to a malicious server. GitHub Security Lab’s analysis showed that vulnerability could potentially achieve remote information disclosure back to the attacker, demonstrating that seemingly low-impact heap reads in SSH libraries can sometimes have greater consequences than initial assessments suggest.

Conclusion

CVE-2026-0968 is a textbook case of why vulnerability management requires context beyond a CVSS number. The bug is real and affects a widely-deployed library, but the attack prerequisites (requiring a victim to connect to an attacker-controlled SFTP server and perform a directory listing) dramatically constrain real-world risk. The scoring discrepancy between automated worst-case analysis and vendor assessments highlights a systemic problem in vulnerability prioritization: organizations that triage purely by CVSS base score will spend equal effort on this 3.1 Low as on a genuinely network-exploitable 9.8 Critical.

This is exactly the kind of context that runtime security adds to vulnerability management. At ARMO, our approach to cloud application security is built on runtime intelligence. Rather than treating every CVE as equally urgent based on a base score alone, ARMO Platform correlates vulnerability data with actual workload behavior: is the vulnerable library loaded in memory? Is the affected code path reachable? Is the workload making outbound SFTP connections to external servers? By grounding vulnerability prioritization in what is actually running and how it is actually exposed, security teams can focus remediation effort where risk is real, not where a scanner says it might be.

The fix is already available in every major distribution. Patch at your normal cadence, prioritize systems running KDE desktops or Cockpit with SFTP operations to untrusted servers, and use this CVE as an example of why attack-path analysis matters more than a single number.