Vulnerability
curl/libcurl: Windows DLL hijacking
libcurl would load Windows system DLLs in a manner that may make it vulnerable to a DLL hijacking (aka binary planting) attack in certain configurations. libcurl has a unified code base that builds and runs on a multitude of different versions of Windows. To make that possible, when libcurl is built with SSPI or telnet is used, it dynamically loads some of the necessary system DLLs at runtime by calling `LoadLibrary()`. No path is specified for these DLLs. To find a DLL when no path is specified `LoadLibrary()` follows [DLL search order](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx#search_order_for_desktop_applications) to load it. If it is a "known DLL" no searching is done, the system copy is used. If it is not a "known DLL": The application directory is searched first. The current directory is searched next, if DLL safe search mode is not enabled. The system directory is searched next. The 3 system DLLs libcurl loads dynamically are `security.dll`, `secur32.dll` and `ws2_32.dll` (a "known DLL" when installed). These DLLs may not be present on some versions of Windows, which is why they are loaded dynamically. Depending on a number of factors outlined in the DLL search order document it may be possible for an attacker to plant a DLL of the same name in the user's current directory, application directory or other directory in the DLL search order, thereby possibly causing it to be loaded first. **Recent versions of Windows include all 3 of those dynamically loaded system DLLs and also enable safe DLL search mode by default. Therefore in such a case `ws2_32.dll` could not be planted, and `security.dll` or `secur32.dll` could only be planted in the application directory.** To address this issue we have changed libcurl so that any system DLL it dynamically loads in Windows is done in the most secure way available. Note if an attacker has the ability to write new files to your application directory they can likely still plant DLLs to be loaded in any case, load-time or runtime. This is by design in Windows DLL loading (refer to the DLL search order doc). For example it may be possible to override DLL search paths by planting an app.exe.local file or possibly a fake manifest. There is nothing we can do to prevent against this. We advise you to guard write permissions on your application directory. **Also note it is may still be possible for planting attacks to be done against load-time DLLs used by libcurl and the curl tool. This is because Windows loads those DLLs and their dependencies without specifying a path. There is nothing we can do to fix this, it is endemic in the design of Windows. We advise you to guard write permissions on your application directory.**
No CVSS 3.x base score yet. Since April 2026 NVD only enriches priority CVEs (KEV, federal and critical software), so most CVEs are scored only if the assigning CNA included a score in the CVE record, or by GHSA for open-source packages. Last record update .
For interim severity, fall back on KEV / EXPLOIT signals and the EPSS percentile (lower panel). Re-check this CVE after one cron tick — the score lands automatically when the source publishes.
Low exploitation likelihood — defer if no other signals fire.
No VEX statements published for CVE-2016-4802. Vendors publish VEX (Vulnerability Exploitability eXchange) to assert per-product whether a CVE is actually exploitable in their distribution.
No exploitation, limited impact or prevalence