Introduction
An insecure default configuration in the libssh library let every unprivileged Windows user hijack SSH connections made by any application on the same machine. CVE-2025-14821, scored at CVSS 7.8, shows 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.
libssh is a programmable SSH2 implementation that developers use to embed secure shell functionality in applications. It is widely deployed. GitHub uses it to power its git SSH infrastructure, which serves millions of requests a day. KDE uses 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, libssh loads its configuration from the C:\etc directory by default. The path is a direct carry-over from Unix, where /etc is a system-owned directory protected by strict file permissions. Windows is different: the root of the C: drive typically lets standard, unprivileged users create new directories that do not already exist.
Attack Flow
Exploitation is straightforward and needs no sophisticated tooling.
-
An unprivileged local user finds that
C:\etcdoes not exist on the target Windows system, or that it exists with permissive ACLs. If necessary, the attacker createsC:\etc. -
The attacker places a crafted libssh configuration file in
C:\etc. The file can specify custom trusted host keys, preferred cipher suites, proxy commands, or other SSH parameters. -
When any application on the system that embeds libssh initializes an SSH connection, the library automatically reads and applies the attacker-controlled configuration during startup.
-
Through that configuration, the attacker can alter the known hosts database or redirect host key verification, so the victim application trusts attacker-controlled endpoints.
-
The configuration can also force weaker cryptographic algorithms or disable security features on SSH connections, which makes interception and decryption feasible.
-
With connections redirected or cryptography weakened, the attacker can intercept, read, and potentially modify SSH traffic in transit.
Why This Matters
What makes this attack noteworthy is how simple it is. It involves no memory corruption, race condition, or complex exploit chain. The whole vulnerability rests on one platform assumption, which is that the operating system protects the configuration directory. On Unix, /etc is owned by root and writable only by privileged users. On Windows, C:\etc has no such inherent protection.
The flaw touches all three parts of the CIA triad. An attacker who intercepts SSH traffic breaks confidentiality. The ability to modify trusted host keys and connection parameters undermines integrity. A malformed configuration that causes connection failures can deny service, which hurts availability.
Affected Systems and Versions
The vulnerability affects libssh installations on Windows running versions earlier than the security releases:
| 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 |
Only Windows deployments are affected. Unix and Linux systems are not, 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. That includes applications that may not look SSH-related but use libssh as a dependency for secure communications.
Vendor Security History
The libssh maintainers have shown a proactive approach to security. The February 10, 2026 security release that fixed CVE-2025-14821 also fixed several other vulnerabilities, including SCP protocol path traversal issues and buffer underflow conditions. That many fixes in one coordinated release suggests the team ran a broader internal security audit instead of patching only the reported issue. Fixing several classes of vulnerability at once is a good sign of the project's security maturity.
