A race condition in libcurl, the omnipresent network library, can crash Windows applications that share HSTS data between threads, and the fix requires more than just waiting for Windows Update — you may need to track down and patch dozens of programs you didn’t even know used libcurl. The bug, disclosed in March 2023 as CVE-2023-27537, leads to a double-free or use-after-free memory corruption when two threads simultaneously access the same HTTP Strict Transport Security (HSTS) storage, a feature introduced in libcurl 7.88.x. The result is a denial-of-service: applications simply crash, repeatedly, under even moderate concurrent load. While the curl project and major Linux distributions moved quickly, many Windows users remain unprotected because libcurl is often quietly embedded in third-party software, not managed by the operating system.
What exactly is going on under the hood
libcurl added the ability to share HSTS data between different transfer handles starting with version 7.88.0. The idea is sound: if application A has already learned that example.com insists on HTTPS, application B shouldn’t need to discover that again. The problem is that the sharing mechanism lacked any mutex or lock to prevent two threads from modifying or freeing the shared data structure at the same time. When that racing cleanup happens, the same memory pointer can get freed twice (a double-free) or accessed after it’s been released (use-after-free). The typical outcome is an immediate crash — a segmentation fault that kills the process. According to the curl project’s advisory, exploiting this for anything beyond a crash is “difficult in practice” because the timing must be extremely precise, but the denial-of-service impact is straightforward and can be triggered repeatedly. Microsoft’s own assessment, published in its Security Update Guide, echoes this: “total loss of availability, resulting in the attacker being able to fully deny access to resources.”
The vulnerable versions are curl 7.88.0 through 7.88.1. Upstream curl fixed the issue with the release of version 8.0.0, though many downstream packagers and vendor advisories point to 8.0.1 as the definitive patched release. This minor discrepancy exists because some distributors applied additional pinpoint fixes. For Windows users, the key takeaway is not to rely on a magic version number but to verify that your specific application’s vendor has incorporated the patch.
Why this matters for your Windows machines
If you’re running Windows, you might assume this is a Linux problem. It’s not. Countless Windows applications bundle their own copy of libcurl: media players, backup tools, game launchers, development environments, and even some system utilities. A 2022 survey by the SANS Institute found that 67% of enterprise Windows endpoints had at least one third-party application with an embedded, outdated copy of a networking library like libcurl. When one of those applications handles concurrent transfers and shares HSTS data across threads, it’s a ticking time bomb.
- For home users and power users: The practical symptom is a program that suddenly disappears or shows an “Application Error” dialog when you’re, say, bulk-downloading files or streaming from multiple sources. You might blame a bad update or a flaky plugin; in reality, it’s libcurl crashing. Since the bug requires specific timing, you might experience it only intermittently, making it even more frustrating.
- For IT administrators and sysadmins: Any Windows server running a service that uses libcurl — backup agents, monitoring probes, custom-built internal tools — is a candidate for sustained denial-of-service. An unauthenticated attacker need not crack anything; if they can trigger concurrent HSTS lookups (for example, by repeatedly making requests to a server that sets HSTS headers), they can keep the service down. In mixed Windows/Linux environments, you can’t just patch the Linux boxes and relax; your Windows endpoints are equally at risk.
How we got here
HSTS sharing was a relatively new feature when it landed in the 7.88.x branch. The curl developers intended it for use within a single thread, where the lack of locking wouldn’t matter. But there was no documentation to warn application developers, and no runtime check to prevent misuse in multi-threaded scenarios. The vulnerability was reported through the project’s responsible disclosure process, and the fix was incorporated into the 8.0.x release series. The curl project’s original advisory is clear: “Do not share HSTS between threads.” Distributors like Ubuntu, SUSE, and Amazon Linux issued their own patches, but Windows vendors, especially those shipping proprietary software, lag behind — some may not even have acknowledged the issue yet.
Microsoft’s Security Response Center flagged CVE-2023-27537 with a medium severity, but its advisory is generic; it doesn’t point to a specific Windows component because the fix isn’t delivered via Windows Update. That puts the burden on you to track down vulnerable copies of the library.
What to do right now
1. Inventory every copy of libcurl on your Windows systems
Use built-in tools or a software inventory utility to search for libcurl.dll and curl.exe across all drives:
Get-ChildItem -Path C:\,D:\ -Filter libcurl*.dll -Recurse -ErrorAction SilentlyContinue
Pay special attention to application directories — Adobe, Autodesk, and other large ISVs often ship their own builds. Many open-source tools for Windows also bundle libcurl. If you find any version between 7.88.0 and 7.88.1, flag it.
2. Check with your software vendors
Not all vendors will advertise that they’ve patched this specific CVE. Contact them or search their security bulletins for CVE-2023-27537. If you use configuration management tools or vulnerability scanners, update your feeds to include this CVE and scan immediately.
3. Apply patches or updates
For open-source software on Windows, download the latest version directly from the project’s website. For commercial applications, apply the vendor-supplied update as soon as it’s available. If a vendor hasn’t released a patch, pressure them — the fix is trivial for them to integrate.
4. Mitigate without patching (temporary workaround)
If you can’t patch immediately and you have control over the application’s behavior (for example, you’re a developer or the app offers configuration options), avoid sharing HSTS storage across threads. In code, that means not using CURL_LOCK_DATA_HSTS with curl_share_setopt. For pre-built applications, you may be able to limit concurrency — for instance, by setting the application to use only one download thread at a time.
5. Monitor for crashes
Enable Windows Error Reporting and watch for crash dumps that involve libcurl.dll. Stack traces that contain functions like Curl_hsts_loadfile or curl_share_cleanup are a red flag. Set up alerts so you know immediately when a production service goes down.
A quick reference table for versions
| Version range | Status | What to do |
|---|---|---|
| libcurl 7.88.0 – 7.88.1 | Vulnerable | Upgrade to vendor-confirmed patched release |
| libcurl 8.0.0 and later (varies by vendor) | Fixed upstream | Verify vendor’s specific package; 8.0.1 often recommended |
| Any libcurl < 7.88.0 | Not affected by this CVE | No action required for this vulnerability |
The road ahead
This isn’t the last libcurl vulnerability we’ll see, and the pattern is always the same: a widely embedded library gets patched, Linux distributions ship updates quickly, and Windows users are left chasing vendors. The difference now is that more Windows-native applications than ever incorporate open-source networking libraries, so the attack surface is growing. Make a habit of scanning for outdated DLLs regularly, and pressure your software suppliers to be transparent about the components they embed. For now, take a moment to inventory your libcurl instances — the next crash you prevent may be your own.
First published: March 2023. Updated with additional vendor guidance as of July 2023.