Introduction
An insecure default configuration in the libssh library quietly gave every unprivileged Windows user the ability to hijack SSH connections made by any application on the same machine. CVE-2025-14821, scored at CVSS 7.8, demonstrates how a Unix directory convention ported to Windows without adjusting for the platform's permission model can turn a configuration file path into a full local man in the middle attack vector.
The libssh library provides a programmable SSH2 implementation used by developers to embed secure shell functionality into applications. Its adoption footprint is significant: GitHub uses libssh to power its git SSH infrastructure (serving millions of daily requests), KDE integrates it for SFTP file transfers, and Cockpit relies on it for SSH public key authentication across bastion hosts. Any Windows deployment embedding libssh was potentially affected.
Technical Information
The root cause of CVE-2025-14821 falls under CWE-427 (Uncontrolled Search Path Element). On Windows systems, libssh defaults to loading its configuration from the C:\etc directory. This is a direct carry over from Unix conventions, where /etc is a system owned directory protected by strict file permissions. The critical distinction on Windows is that the root of the C: drive typically permits standard, unprivileged users to create new directories when they do not already exist.
Attack Flow
The exploitation path is straightforward and requires no sophisticated tooling:
-
Directory creation: An unprivileged local user identifies that the
C:\etcdirectory does not exist on the target Windows system, or that it exists with permissive ACLs. The attacker createsC:\etcif necessary. -
Configuration injection: The attacker places a crafted libssh configuration file within
C:\etc. This file can specify custom trusted host keys, preferred cipher suites, proxy commands, or other SSH parameters. -
Automatic ingestion: When any application on the system that embeds libssh initializes an SSH connection, the library automatically reads and applies the attacker controlled configuration during its startup sequence.
-
Trusted host manipulation: Through the malicious configuration, the attacker can alter the known hosts database or redirect host key verification, causing the victim application to trust attacker controlled endpoints.
-
Security downgrade: The configuration can force weaker cryptographic algorithms or disable security features on SSH connections, making interception and decryption feasible.
-
Man in the middle positioning: With redirected connections or weakened cryptography, the attacker can intercept, read, and potentially modify SSH traffic in transit.
Why This Matters
The simplicity of this attack is what makes it noteworthy. There is no memory corruption, no race condition, and no complex exploit chain involved. The entire vulnerability hinges on a platform assumption: that the configuration directory is protected by the operating system. On Unix, /etc is owned by root and writable only by privileged users. On Windows, C:\etc has no such inherent protection.
This affects all three pillars of the CIA triad. Confidentiality is compromised through interception of SSH traffic. Integrity is undermined by the ability to modify trusted host keys and connection parameters. Availability can be impacted through denial of service via malformed configurations that cause connection failures.
Affected Systems and Versions
The vulnerability affects libssh installations on Windows systems running versions prior to the security releases. Specifically:
| Component | Vulnerable Versions | Patched Version | Release Date |
|---|---|---|---|
| libssh stable branch | Versions prior to 0.11.4 | 0.11.4 | February 10, 2026 |
| libssh new release branch | Versions prior to 0.12.0 | 0.12.0 | February 10, 2026 |
The vulnerability is specific to Windows deployments. Unix and Linux systems are not affected because /etc is a system protected directory by default. Any Windows application that links against or bundles a vulnerable version of libssh is potentially exposed, including applications that may not be obviously SSH related but use libssh as a dependency for secure communications.
Vendor Security History
The libssh maintainers have demonstrated a proactive security posture. The February 10, 2026 security release that addressed CVE-2025-14821 also resolved multiple other vulnerabilities concurrently, including SCP protocol path traversal issues and buffer underflow conditions. The breadth of fixes in a single coordinated release suggests the team conducted a broader internal security audit rather than addressing only the reported issue. This pattern of concurrent, multi class vulnerability resolution is a positive indicator of the project's security maturity.
