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 dyn
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2016-4802
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 1 Nov 2026, 09:35 UTC · Revision 1
Source evidence
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 dyn
osv:CURL-CVE-2016-4802
Complete source record
{
"id": "4f3d519320bd936fc3e6a96be6ae506ced3c6d135e9effd80d40735cbc92789b",
"url": "https://osv.dev/vulnerability/CURL-CVE-2016-4802",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Windows DLL hijacking",
"summary": "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 dyn",
"evidence": "osv:CURL-CVE-2016-4802",
"products": [],
"severity": "high",
"structured": {
"id": "CURL-CVE-2016-4802",
"aliases": [
"CURL-CVE-2016-4802",
"CVE-2016-4802"
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "7.11.1"
},
{
"fixed": "7.49.1"
}
]
}
],
"versions": [
"7.49.0",
"7.48.0",
"7.47.1",
"7.47.0",
"7.46.0",
"7.45.0",
"7.44.0",
"7.43.0",
"7.42.1",
"7.42.0",
"7.41.0",
"7.40.0",
"7.39.0",
"7.38.0",
"7.37.1",
"7.37.0",
"7.36.0",
"7.35.0",
"7.34.0",
"7.33.0",
"7.32.0",
"7.31.0",
"7.30.0",
"7.29.0",
"7.28.1",
"7.28.0",
"7.27.0",
"7.26.0",
"7.25.0",
"7.24.0",
"7.23.1",
"7.23.0",
"7.22.0",
"7.21.7",
"7.21.6",
"7.21.5",
"7.21.4",
"7.21.3",
"7.21.2",
"7.21.1",
"7.21.0",
"7.20.1",
"7.20.0",
"7.19.7",
"7.19.6",
"7.19.5",
"7.19.4",
"7.19.3",
"7.19.2",
"7.19.1",
"7.19.0",
"7.18.2",
"7.18.1",
"7.18.0",
"7.17.1",
"7.17.0",
"7.16.4",
"7.16.3",
"7.16.2",
"7.16.1",
"7.16.0",
"7.15.5",
"7.15.4",
"7.15.3",
"7.15.2",
"7.15.1",
"7.15.0",
"7.14.1",
"7.14.0",
"7.13.2",
"7.13.1",
"7.13.0",
"7.12.3",
"7.12.2",
"7.12.1",
"7.12.0",
"7.11.2",
"7.11.1"
],
"database_specific": {
"source": "https://curl.se/docs/CURL-CVE-2016-4802.json"
}
}
],
"modified": "2026-10-24T23:17:46Z",
"provider": "osv",
"references": [],
"provider_metadata": {
"CWE": {
"id": "CWE-94",
"desc": "Improper Control of Generation of Code ('Code Injection')"
},
"URL": "https://curl.se/docs/CVE-2016-4802.json",
"www": "https://curl.se/docs/CVE-2016-4802.html",
"affects": "both",
"package": "curl",
"severity": "High",
"last_affected": "7.49.0"
}
},
"related_cves": [
{
"value": "CVE-2016-4802",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/database_specific/severity"
},
"source_id": "core-osv",
"document_id": 444199,
"published_at": "2016-05-30T08:00:00+00:00"
}