Curl 8.17.0 landed this week with an uncommonly decisive security fix: the experimental wolfSSH backend has been ripped out entirely. The reason? A five‑year‑old omission left SFTP connections without host‑key verification, enabling a classic man‑in‑the‑middle scenario if an attacker could intercept traffic. The vulnerability, tracked as CVE‑2025‑10966, may carry a low severity score, but for Windows shops that rely on custom‑built tools, embedded devices, or CI/CD pipelines, it’s a prod to inventory every copy of the ubiquitous data‑transfer utility.

The Vulnerability: What Was Missing

SSH depends on a simple trust mechanism: when you first connect to a server, your client stores its public host key. On every subsequent connection, that key must match—otherwise, the client warns you or bails out. This prevents an attacker from slipping between you and the server and decrypting the session. Curl’s wolfSSH backend, introduced in libcurl 7.69.0 and present through 8.16.0, never implemented that check. It simply accepted any key the server offered, no questions asked.

The result is textbook CWE‑322 (Key Exchange without Entity Authentication). Any active network adversary positioned between a vulnerable curl client and an SFTP server could impersonate the server and read or tamper with data in transit. The curl project’s security advisory classified the bug as low severity, primarily because the wolfSSH backend was marked experimental and saw scant real‑world adoption. Public vulnerability trackers reflect that tempered view, with CVSS base scores hovering around 4.3 to 5.x.

The fix is unambiguous: curl 8.17.0 completely removes the wolfSSH backend. There is no patch to retrofit host verification onto wolfSSH—the code path is gone. Going forward, SFTP transfers will use only the mature libssh2 or libssh backends, which have full host‑key checking.

Are You Affected? Decoding the Risk for Windows Shops

For the vast majority of Windows users who install curl from winget, Chocolatey, or the official win64 builds, the wolfSSH backend has never been part of the package. Those mainstream binaries are compiled with libssh2 or use the operating system’s native SSH capabilities. Ubuntu’s security advisory for CVE‑2025‑10966 explicitly states its curl packages do not rely on wolfSSH, and the same is true for most distribution‑packaged builds on Windows and Linux.

But “most” isn’t “all.” The risk lies in the long tail of niche and embedded use:

  • Custom‑compiled applications that statically link libcurl with the --with-wolfssl-ssh build option. Developers who pulled in libcurl for an internal tool five years ago may have inadvertently enabled the insecure backend and never revisited the configuration.
  • Container images and WSL distros where curl was built from source with non‑default flags. A bespoke Docker image used for build automation could host a vulnerable binary.
  • Third‑party software vendors that ship curl as part of their Windows utilities. Installers for backup agents, file sync tools, or management consoles sometimes include a private curl build. If the vendor activated wolfSSH, those clients are exposed.
  • Embedded devices and IoT appliances that Windows administrators connect to, manage, or rely on. A network‑attached storage unit, an industrial controller, or a middleware appliance running a statically linked libcurl with wolfSSH remains vulnerable until the vendor pushes a firmware update.
  • CI/CD runners on Windows that pull files via sftp:// URLs as part of automated builds. Even if the runner itself uses a safe curl build, a script might call a tool that bundles a vulnerable version.

For IT admins, the takeaway is clear: you cannot trust that “no one uses wolfSSH” without actually verifying every instance of curl under your care. The backend was experimental, but that designation doesn’t prevent it from being compiled into production binaries.

The Curious Case of the Forgotten Backend

How does a security‑critical feature like host verification get omitted from a major open‑source project for five years? The answer lies in the nature of experimental code and the quiet life of an unmaintained backend.

WolfSSH is a lightweight SSH library provided by wolfSSL, built for embedded and resource‑constrained environments. The libcurl project added support for it as an alternative to libssh2 in 2020, but the integration was never completed. The known_hosts file—the standard mechanism for storing and checking host keys—was never wired up. Over time, the backend fell out of active attention; it compiled, it functioned in basic tests, and nobody noticed the missing verification step.

When the omission was reported to the curl security team, the response was swift and proportionate. Rather than attempt to retrofit host verification onto a backend that was already struggling to gain production traction, the project simply cut the cord. The curl advisory notes that wolfSSH was an “experimental” feature and that dropping it was the cleanest way to ensure the vulnerability could never recur.

This is not the first time a shared library’s optional component has introduced a weakness that administrators overlook. OpenSSL’s “heartbleed” was present in every build, but less‑used SSH backends like wolfSSH demonstrate the hidden risk of optional code paths. For Windows environments, where software often arrives as opaque binaries without build‑time transparency, the lesson is to treat every embedded library as a component requiring active lifecycle management.

What to Do: A Four‑Step Remediation Checklist

If you rely on curl for SFTP transfers—or if you simply maintain a fleet of Windows machines that might include curl from any source—these steps will close the exposure.

1. Identify Every curl Instance

Start with your own endpoints, then expand to the devices and services you interact with.

  • Windows desktops and servers: Use where.exe curl in Command Prompt or Get-Command curl in PowerShell to locate all curl executables in the PATH. Run curl --version and look for the supported protocols list. If sftp appears and the version is between 7.69.0 and 8.16.0, you need to investigate further. On standard Windows builds, you’ll typically see “Protocols: … sftp” but no mention of wolfSSH; instead, libssh2 or similar will be listed as the SSH backend.
  • Custom directories and tools: Scan common install locations (C:\Program Files, C:\Program Files (x86), %APPDATA%) for curl.exe or libcurl*.dll. Tools like Everything search can help. Check the digital signatures and file properties to trace the origin.
  • Containers and WSL: Run a similar audit inside any Linux environments you manage. Use docker exec or access WSL distros and run which curl + curl --version.
  • Appliances and firmware: Request a software bill of materials (SBOM) from vendors or use binary scanning tools like Dependency‑Track, Black Duck, or Snyk to detect embedded libcurl versions and compile‑time options.

2. Patch or Replace

Once you’ve found a wolfSSH‑based curl, the fix depends on how you obtained it.

  • Official builds: Download the latest curl for Windows from curl.se/windows. Version 8.17.0 or later is safe. Winget users can run winget upgrade curl.curl.
  • Package managers: For Chocolatey, choco upgrade curl. For MSYS2, pacman -S curl. Verify the version afterward.
  • Custom builds: If you maintain your own curl builds, recompile without the --with-wolfssl-ssh flag. If you need an SSH backend, use --with-libssh2 or --with-libssh.
  • Vendor‑provided binaries: Contact the vendor for a patched update. If none is forthcoming, consider replacing the tool with a known‑good curl build or an alternative SFTP client.
  • Embedded devices: Apply firmware updates from the manufacturer. Until patched, apply network‑level mitigations (see step 3).

3. Reduce Exposure During the Wait

Patching all devices instantly isn’t feasible. While you line up fixes, these compensatory controls lower the risk:

  • Restrict SFTP traffic: Use firewalls to limit outbound SFTP connections from potentially vulnerable systems to only IP addresses and networks you explicitly trust. On Windows, Windows Defender Firewall with Advanced Security can enforce such rules.
  • Bastion and proxy: Route SFTP transfers through a hardened intermediary that performs host verification on behalf of the client. A jump host with a patched curl acting as a proxy eliminates the exposure.
  • Disable sftp:// in automation: Audit scripts, Scheduled Tasks, and CI/CD pipelines for sftp:// URLs. Temporarily switch to alternative protocols (e.g., HTTPS‑based file transfers) or replace curl invocations with a dedicated SFTP client like sftp (the OpenSSH client built into Windows 10/11) that always performs host‑key checking.
  • Segment networks: Place vulnerable appliances in a restricted VLAN with no direct internet access, reducing the attack surface.

4. Validate and Monitor

After patching, confirm the fix took:

  • Run curl --version again and ensure the version is 8.17.0 or greater, and that the SSH backend is now libssh2 or libssh.
  • Test an SFTP connection to a known server and observe that host keys are checked. A first connection will prompt you to accept the key; subsequent connections should succeed silently.
  • Set up ongoing monitoring: look for unexpected SFTP handshakes in network logs, especially from endpoints that normally don’t use SFTP. Sudden changes in server host keys can be a red flag.
  • Enable detailed curl logging (curl --verbose sftp://...) in test scripts to capture key exchange details once, ensuring verification is active.

Beyond Patching: Supply Chain Blind Spots

CVE‑2025‑10966 is not a blockbuster vulnerability. Its low severity rating reflects the reality that very few production environments ever touched wolfSSH. Yet the bug reveals a persistent operational weakness: we don’t always know what’s inside the binaries we trust.

Windows administrators are accustomed to patching operating systems through Microsoft Update. But curl is not a Microsoft product. Its inclusion in third‑party tools, appliances, and custom code means patch responsibility fragments across dozens of vendors. An IT team may have no central inventory of where curl lives, let alone which SSH backend it uses.

Software composition analysis (SCA) tools can help. These scanners inspect binaries and container images for known open‑source components and their versions. When coupled with vulnerability databases, they can flag CVE‑2025‑10966 automatically. However, SCA tools are only as good as their signature databases, and many still struggle to identify compile‑time feature flags like “wolfSSH enabled.” That means a manual verification step may still be needed for high‑risk systems.

For embedded devices, the problem is worse. An industrial sensor or a storage array might run Linux internally with curl compiled five years ago. The vendor may have no mechanism for distributing patches, and IT may lack access to the underlying OS. In such cases, network isolation becomes the primary defense—underscoring the need to treat every device as potentially vulnerable until proven otherwise.

Looking Ahead: Better Visibility for Embedded Components

The curl project’s transparency in this incident is commendable: a clear advisory, a definitive fix, and timely distribution of the patch. But the episode should also prompt Windows‑focused organizations to tighten their grip on third‑party and embedded software.

Expect to see more security advisories that hinge on obscured build‑time choices. As open‑source libraries proliferate inside commercial products, the old model of “patch the OS and you’re done” no longer suffices. Vendors will need to provide SBOMs as part of their support contracts. IT teams will need to demand them.

In the near term, the practical lessons are straightforward: inventory your curl instances, update to 8.17.0 wherever possible, and apply network mitigations for devices you cannot immediately patch. CVE‑2025‑10966 might qualify as “low,” but in the hands of an attacker with network access, even a low‑severity bug can become a stepping stone. The fix exists. Now it’s your move.