In September 2025, the curl project disclosed CVE-2025-9086, an out-of-bounds read in libcurl that can crash applications and, in rare cases, let attackers overwrite secure cookies. The flaw touches every Windows machine that ships or bundles the popular networking library—from the operating system’s own curl.exe to third‑party tools like Git for Windows, backup agents, and development SDKs. While the upstream fix landed quickly in curl 8.16.0, the real work for administrators and power users is finding and updating every embedded copy across an estate.

A single bad comparison breaks memory safety

The bug sits inside libcurl’s cookie path comparison routine. When a server sets a cookie over HTTPS with the Secure attribute, the browser—or in this case, the library—should never send that cookie over plain HTTP, and equally, an HTTP response should never be able to supersede it. But a logic error introduced in an earlier commit upset that rule.

Here is the triggering sequence: an HTTPS endpoint sets a secure cookie for a hostname. Later, a connection to the same hostname over HTTP (thanks to a redirect, a scheduled job, or an attacker who controls the unencrypted side) responds with a cookie that has the same name and a path of “/”. When libcurl compares the new cookie’s path against the existing one, an off‑by‑one mis‑check causes it to read beyond the allocated buffer—a one‑byte heap region that stores the path.

The out‑of‑bounds read can end in one of two ways. Most often, the process crashes with a segfault or abort, creating a denial‑of‑service condition for whatever service or application embeds libcurl. Less frequently, the read returns a value that tricks the comparison logic into believing the old and new paths are different, leading libcurl to silently accept the insecure cookie and overwrite the secure one in memory. That second outcome requires unpredictable heap content and timing, so exploitation is fragile, but it remains a plausible attack surface on long‑running processes.

Why Windows users cannot ignore this advisory

Many readers will see “curl” and assume this is a Linux server problem. That would be a mistake. Modern Windows builds include curl.exe and the libcurl library as part of the operating system; the version shipped in Windows 11 or Windows Server 2022 may well sit between 7.31.0 and 8.15.0—the entire vulnerable range. The system copy is not the only one to worry about.

Windows applications that perform their own HTTP transfers frequently bundle a private libcurl rather than relying on whatever the OS provides. Git for Windows ships its own curl.exe and libcurl‑4.dll. Package managers like Chocolatey, NuGet clients, container runtimes, backup utilities, and many enterprise agent services embed the library. A single workstation can contain five or six distinct copies of libcurl, each with its own patch schedule. A vulnerable DLL loaded into a long‑running service—a synchronization agent or an updater—is a soft target for a network attacker who can arrange an HTTPS‑to‑HTTP redirect.

The curl project noted that the standalone command‑line tool is not considered vulnerable in the same sense as a programmatic consumer of libcurl, because cookie override inside an interactive session is less impactful. The risk concentrates in servers, agents, and apps that manage cookies programmatically on behalf of users or backend systems. Windows admins should treat any process that loads libcurl and talks to the internet as potentially affected until proven otherwise.

How to detect vulnerable libcurl copies on Windows

Start with the system‑provided curl. Open a PowerShell or Command Prompt window and type curl --version. If the reported version is 7.31.0 through 8.15.0, the system copy needs an update. Microsoft typically patches in‑box curl through its monthly security rollups, so a fully updated Windows machine should receive a fixed binary; verify that your patch management is catching it.

System curl is only the first stop. The harder part is inventorying third‑party bundles. Here is a practical path:

  1. Search for libcurl*.dll inside Program Files, Program Files (x86), and any common data directories.
  2. On the command line, run where /R C:\ libcurl*.dll (this can be slow; limit to areas that hold applications).
  3. For each located file, right‑click → Properties → Details tab to inspect the file version, or use PowerShell’s Get-Item to read version metadata.
  4. For applications that ship curl.exe (like Git), run the same --version check against the full path.

Enterprise admins can lean on software inventory tools, endpoint detection and response queries, and software bills of materials (SBOMs) that some vendors now provide. Filter for process images that load libcurl libraries and tag them for remediation.

Patching and mitigating the risk

The authoritative fix is to upgrade every instance of libcurl to version 8.16.0 or later. How you get there depends on where the library lives:

  • System‑supplied curl: Install the latest Windows security updates. Confirm by re‑running curl --version and checking that the version is 8.16.0 or above.
  • First‑party and custom applications: If your organization builds internal tools that statically or dynamically link libcurl, rebuild them against the patched source and redeploy.
  • Third‑party applications: Check each vendor’s security advisory. Many software vendors backport fixes and ship new releases; apply those updates promptly. If an application’s vendor is slow to respond, consider substituting an alternative or isolating the software on a separate network segment.

Where an immediate upgrade is impossible, temporary mitigations can lower the attack surface:

  • Block insecure redirects: Configure clients to refuse redirects from HTTPS to HTTP. In libcurl code, set CURLOPT_REDIR_PROTOCOLS to exclude CURLPROTO_HTTP; for command‑line curl, use --proto-redir -http.
  • Disable cookie handling in high‑risk contexts: If the workflow does not need cookies, disable them entirely by not setting a cookie jar or by using CURLOPT_COOKIEFILE NULL.
  • Network hardening: Enforce HTTPS‑only policies on sensitive services, monitor for unexpected HTTP traffic on hosts that should stay encrypted, and limit exposure to untrusted networks where a man‑in‑the‑middle is more feasible.
  • Increase logging and alerting: Watch for crash dumps whose stack traces reference libcurl cookie routines (curl_cookie_add, cookie_path_match) and for network events showing HTTPS‑to‑HTTP redirect sequences involving the same hostname.

After patching, don’t rely on the installer alone. Re‑run curl --version on the system copy, re‑inspect application directories, and restart services that load libcurl to ensure the old DLL is unloaded.

The winding road from commit to disclosure

libcurl’s cookie path parsing has seen subtle changes over a decade. The flawed comparison logic was introduced in a commit that touched code first shipped in libcurl 7.31.0 (released in 2013). For years it lay dormant until an independent researcher, reporting through the project’s bug bounty, triggered the memory error in August 2025. The curl security team confirmed the out‑of‑bounds read and prepared a patch that landed in the official repository within weeks. curl 8.16.0, released in early September 2025, is the first version to carry the fix.

Because libcurl underpins everything from mobile apps to server‑side frameworks, the disclosure set off a chain of downstream advisories. Linux distributions, BSDs, and embedded vendors released their own updated packages. Windows, however, often resides outside the immediate focus of open‑source patching conversations, making it easier for vulnerable copies to languish on enterprise desktops and servers.

Looking ahead: Memory safety and supply‑chain hygiene

CVE-2025-9086 is not the most severe libcurl vulnerability ever disclosed, but it exemplifies a pattern that shows no sign of disappearing: a tiny programming mistake in a ubiquitous C library ripples into millions of devices. The curl project’s own security practices—fuzzing, peer review, and a well‑structured disclosure process—are strong, yet memory‑safety bugs in C can slip through.

The industry’s move toward memory‑safe languages for parsing and network handling (Rust, for instance, in Firefox’s networking stack) offers a long‑term answer. In the meantime, practical hygiene beats theoretical perfection:

  • Maintain a current inventory of all third‑party libraries, especially those that parse network input.
  • Require SBOMs from software suppliers and use them to trigger patching alerts.
  • Automate dependency scanning in CI/CD pipelines, blocking builds that contain known vulnerable versions.
  • Treat library vulnerabilities as a signal to patch quickly, even when the CVSS score appears low—because in a multi‑component system, the interaction of a low‑severity flaw with other conditions can escalate impact.

For the Windows user or admin, the immediate task is modest: check your versions, update where you can, and apply the mitigations where you cannot. The longer‑term task is to build processes that make the next libcurl CVE a non‑event instead of a fire drill.