curl’s SFTP support shipped with a wolfSSH backend that never performed host‑key verification, creating CVE‑2025‑10966 — a subtle but meaningful libcurl vulnerability that was fixed by removing the wolfSSH backend in curl 8.17.0 and replacing it with safer defaults.
Background
The libcurl project supports multiple SSH backends for SFTP operations; one of them — the wolfSSH integration — was added, left functionally incomplete, and never implemented the usual known‑hosts / host‑key verification checks that protect SSH connections from man‑in‑the‑middle (MITM) attacks. The omission was reported to the curl team, assigned CVE‑2025‑10966, and remedied by dropping wolfSSH support entirely in curl 8.17.0. Why this matters: host‑key verification is the canonical defence that lets an SSH client detect that the server it’s talking to is the same server it connected to previously (or is otherwise trusted). When a client omits that check, an active network adversary can intercept or impersonate the server and decrypt or tamper with the session. In the case of libcurl’s wolfSSH backend, that safeguard simply wasn’t present.Overview of the vulnerability
What the bug is
- The vulnerability is an implementation omission: the wolfSSH backend in libcurl did not perform host verification (no known‑hosts support and no host‑key checking) for SFTP connections. This maps to CWE‑322: Key Exchange without Entity Authentication.
- Affected libcurl versions: 7.69.0 through 8.16.0. The bug was introduced in a change series and fixed by removing the wolfSSH backend in curl 8.17.0.
Severity and exploitability
- The curl security team rated the flaw Low severity for general use, and many downstream distributors likewise treated it as a lower priority because the wolfSSH backend was known to be incomplete and appeared rarely used in production.
- Public vulnerability aggregators report CVSS scores in the low‑to‑medium range (NVD and other trackers have recorded base scores around 4.3 to 5.x), reflecting a network attack vector but limited real‑world exposure. There are no widely reported public proof‑of‑concept exploits or observed in‑the‑wild attacks tied to CVE‑2025‑10966 at the time of disclosure.
Technical analysis
How SSH host verification should work
SSH clients typically perform host authenticity checks during the key exchange:- The server presents its host key as part of the protocol.
- The client checks that key against an authoritative store (for example, the user’s known_hosts file) or an explicit policy.
- If the presented key differs from the record, the client warns or aborts the connection to prevent a MITM scenario.
Why wolfSSH backend exposure was limited — and why that doesn’t mean “no risk”
Two operational realities reduced the immediate blast radius:- The wolfSSH backend for libcurl was documented as experimental and rarely used in default distro builds and mainstream Windows packages, which typically compile libcurl with other SSH backends (libssh2 or libssh) or use platform TLS/SSH stacks. Several distributors noted that their curl packages do not use wolfSSH.
- The curl team removed wolfSSH support entirely in the fix, preventing future builds from continuing the insecure behavior.
- libcurl is widely embedded and linked into third‑party applications, appliances, and firmware. Some vendors build curl with custom backends or static linkages; if any build used the wolfSSH backend, that product remained vulnerable until rebuilt with a different SSH backend or replaced with curl 8.17.0+.
- Embedded and IoT devices can lag upstream fixes for months or years. A vulnerable static build on an appliance in the field is the primary operational risk from a bug like this.
Who and what is affected
Directly affected
- Any application or system using libcurl compiled with the wolfSSH backend for SFTP operations between curl versions 7.69.0 and 8.16.0. That includes the curl command line tool when built the same way. The curl project’s advisory lists the affected range and the fix.
Indirect and downstream risk
- Third‑party software vendors and embedded device manufacturers that statically linked an affected libcurl build could ship vulnerable firmware or binaries. Those products will not receive the remedy until the vendor rebuilds and redistributes updated firmware or software.
- Software composition and supply‑chain scanners may not always surface embedded wolfSSH usage correctly. SCA and binary scanning are necessary to find static linkages.
Practical remediation and mitigation
Immediate steps (recommended, in order)
- Upgrade curl to 8.17.0 or later — this release removes the wolfSSH backend and eliminates the insecure code path. This is the primary, definitive remediation.
- If you build curl from source, ensure you do not enable wolfSSH as the SSH backend; instead, compile with a supported backend (for example, libssh2 or another maintained SSH implementation) or rely on your platform’s native SSH bindings.
- Inventory: use software composition analysis, package manifests, and binary scanning to find instances of curl/libcurl in your environment and identify which backend was used at build time. Treat appliances and firmware as high‑priority items.
- For devices you cannot patch immediately, apply network compensations: restrict access to SFTP endpoints to trusted networks, place vulnerable devices behind hardened proxies or bastions, and apply per‑host network ACLs and rate limits. These are imperfect stopgaps but reduce exposure while waiting for vendor updates.
- Where feasible, disable or avoid using sftp:// URIs in automated scripts or integration points until you can verify the curl backend and patch status. The curl advisory specifically lists avoiding sftp:// as an interim mitigation.
Validation steps after patching
- Confirm version strings: curl —version should show 8.17.0 or later (or your distro’s packaged curl that incorporates the 8.17.0 change). On packaged systems, consult your vendor’s security advisory and package changelog.
- For binary‑only appliances where patching isn’t possible, request a firmware or software update from the vendor. If vendors do not provide timely updates, escalate to procurement and risk teams and isolate the device where possible.
Detection and hunting guidance
- Network telemetry: look for traffic patterns showing SFTP handshakes to internal servers from endpoints that shouldn’t be making SFTP connections, or repeated connections with sudden key changes. Monitor for unexplained handshakes that lack prior known‑host entries. These are noisy signals but can highlight misuse or probing.
- Host checks: where you manage endpoints that run curl in scripts or automation, search for references to sftp:// in code repositories, automation scripts, and scheduled tasks. Identify which builds are in use and whether they were custom‑compiled.
- Firmware and binary scanning: use SCA tools capable of detecting static linkages of wolfSSH or build metadata that indicates wolfSSH was enabled. If you cannot scan firmware automatically, sample and inspect critical appliances manually.
- Log correlation: pair SFTP connection logs with network captures and with alerts from your IDS/WAF to spot unusual man‑in‑the‑middle‑style failures or repeated session establishments from new network locations.
Why this matters to Windows administrators
- Windows users often interact with mixed‑platform fleets and shared services — a vulnerable appliance or Linux/Unix server can be used by Windows clients and defeat endpoint protections. Even if typical Windows-distributed curl binaries don’t use wolfSSH, Windows administrators should still verify the SFTP infrastructure they rely on (for instance, automated SFTP servers, appliances, or middleware components). Distributors and OS packaging decisions differ: Ubuntu’s advisory explicitly notes that the distro package does not use the wolfSSH backend, but not every environment mirrors that configuration.
- Administrators should audit CI/CD systems, build agents, and custom toolchains that might compile curl with unusual options — these are the most likely places where a nonstandard backend like wolfSSH was selected and introduced into production artifacts.
Strengths of the vendor response — and remaining concerns
Notable strengths
- Rapid, transparent advisory: the curl project published a clear security advisory explaining the omission, the affected versions, and the exact remediation (removal of wolfSSH). The advisory also includes timeline and credits. That level of public detail helps administrators verify fixes.
- Definitive fix strategy: removing the insecure backend is a robust corrective action — it eliminates the insecure code path entirely rather than attempting a piecemeal patch against a backend that the project viewed as experimental.
- Distribution tracking: major OS vendors and vulnerability databases (NVD, Ubuntu, OSV, Amazon Linux advisories) have consumed the advisory and mapped it into their tracking systems, which assists enterprise patch management.
Remaining concerns and risks
- Embedded devices and vendor firmware remain the classic long tail: many appliances ship with statically linked libraries and seldom get rebuilt in a timely manner. Those devices can remain vulnerable even after upstream fixes are published. Administrators should treat that as a high‑priority discovery problem.
- Supply chain blind spots: organizations often rely on third‑party tools and libraries without clear visibility into how libcurl was built or which SSH backend was used. Automated SCA and binary scanning are required to close this gap.
- Variable CVSS/priority signals: trackers and distros may assign differing CVSS scores and priorities, so a binary “low” designation from one source should not be used as justification to ignore inventory and remediation. The operational context (publicly reachable SFTP endpoints, low‑latency internal networks) changes risk calculus materially.
Recommended checklist for administrators (practical, prioritized)
- Inventory: Identify every instance of curl/libcurl in your environment (hosted servers, build agents, containers, appliances, firmware). Use SCA tools and binary scanning where available.
- Verify build options: For each instance, determine whether wolfSSH was enabled as the SSH backend. If you cannot determine this via package metadata, treat the instance as potentially vulnerable until proven otherwise.
- Patch: Upgrade to curl 8.17.0 or apply vendor-supplied packages that incorporate the change. For appliances, request patched firmware and prioritize internet‑facing devices.
- Temporary compensations: Limit access to SFTP ports, replace SFTP endpoints with patched reverse proxies or terminate SFTP at a hardened intermediary, and avoid sftp:// in automation until you can confirm your client stacks are patched.
- Monitor and hunt: Add rules for unusual SFTP handshake patterns, and correlate those with process and network telemetry. Preserve relevant logs and captures if suspicious activity coincides with vulnerable components.
Final assessment
CVE‑2025‑10966 is a textbook example of a correctness/omission bug whose real‑world impact depends heavily on how the affected code was used in practice. The curl project fixed the issue decisively by removing the wolfSSH backend in 8.17.0, and major distributors have ingested the advisory into their tracking systems. That said, the vulnerability highlights persistent operational challenges:- Embedded and firmware‑embedded copies of open source libraries are the long tail of risk and require vendor engagement and proactive inventory.
- Supply‑chain and build invisibility can leave organizations exposed even when upstream fixes are available.
- Even “low severity” or “rare backend” vulnerabilities must be treated as actionable in environments where the vulnerable path could be present (custom builds, appliances, CI/CD artifacts).
By following the checklist above, verifying your curl/libcurl builds, and prioritizing firmware and appliance vendors for updates, teams can close the gap CVE‑2025‑10966 exposed and substantially reduce the risk of SSH MITM attacks arising from this implementation omission.
Source: MSRC Security Update Guide - Microsoft Security Response Center
