Skip to content
Heist/ feed
Back to feed
High

Windows DLL hijacking

Type: advisorySources: OSV

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

Windows DLL hijacking

core-osv · Original source

Published 30 May 2016, 08:00 UTC

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"
}