Daniel Stenberg explains why curl's maintainers cannot patch a vulnerable libcurl.dll found lurking in Windows System32 folders. Third-party applications bundle their own libcurl.dll files during installation, sometimes dropping them in system32, and only the app that built and shipped that specific file can safely rebuild and update it. Microsoft's own bundled curl in Windows is statically linked and never produces a libcurl.dll, so any such file comes from another installed application. The curl team's advice: use tools like tasklist to identify which running application depends on the DLL, then get that vendor to rebuild with a patched curl. The team offers build guidance, long-term stable releases, and security backports, but cannot runtime-patch someone else's Windows installation.
Questions this post answers
Why does my vulnerability scanner flag an outdated libcurl.dll in C:\Windows\System32 that I can't seem to update?
That libcurl.dll was not installed by Windows itself; Microsoft's bundled curl links libcurl statically and never ships a separate DLL file. Some third-party Windows application installed it, often during its own setup process, sometimes placing it directly in system32. Only the vendor that built that specific DLL can safely rebuild and update it, since replicating its exact build configuration is nearly impossible for anyone else. daily.dev helps developers track curl security advisories when triaging vulnerability scanner findings like this.
How do I find out which application is using a specific DLL file on Windows?
Use the tasklist command to check which currently running processes are using a specific DLL, or use a dedicated scanning tool designed to inspect executable files for DLL dependencies. This is the recommended approach when a vulnerability scanner flags a shared library like libcurl.dll but does not identify which installed application owns it. Developers debugging DLL dependency issues can follow security guidance like this on daily.dev.