Skip to content
Heist/ feed
Back to feed
High

lingering HTTP credentials in connection reuse

Type: advisorySources: OSV

libcurl can wrongly send HTTP credentials when reusing connections. libcurl allows applications to set credentials for the upcoming transfer with HTTP Basic authentication, like with `CURLOPT_USERPWD` for example. Name and password. Like all other libcurl options the credentials are sticky and are kept associated with the "handle" until something is made to change the situation. Further, libcurl offers a `curl_easy_reset()` function that resets a handle back to its pristine state in terms of all settable options. A reset is of course also supposed to clear the credentials. A reset is typically used to clear up the handle and prepare it for a new, possibly unrelated, transfer. Within such a handle, libcurl can also store a set of previous connections in case a second transfer is requested to a hostname for which an existing connection is already kept alive. With this flaw present, using the handle even after a reset would make libcurl accidentally use those credentials in a subsequent request if done to the same hostname and connection as was previously accessed. An example case would be first requesting a password protected resource from one section of a website, and then do a second request of a public resource from a completely different part of the site without authentication. This flaw would then inadvertently leak the credentials in the second request.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2015-3236
Confirmed fixed CVEs
Not specified
Updated in this feed
1 Nov 2026, 09:35 UTC · Revision 1

Source evidence

lingering HTTP credentials in connection reuse

core-osv · Original source

Published 17 Jun 2015, 08:00 UTC

libcurl can wrongly send HTTP credentials when reusing connections. libcurl allows applications to set credentials for the upcoming transfer with HTTP Basic authentication, like with `CURLOPT_USERPWD` for example. Name and password. Like all other libcurl options the credentials are sticky and are kept associated with the "handle" until something is made to change the situation. Further, libcurl offers a `curl_easy_reset()` function that resets a handle back to its pristine state in terms of all settable options. A reset is of course also supposed to clear the credentials. A reset is typically used to clear up the handle and prepare it for a new, possibly unrelated, transfer. Within such a handle, libcurl can also store a set of previous connections in case a second transfer is requested to a hostname for which an existing connection is already kept alive. With this flaw present, using the handle even after a reset would make libcurl accidentally use those credentials in a subsequent request if done to the same hostname and connection as was previously accessed. An example case would be first requesting a password protected resource from one section of a website, and then do a second request of a public resource from a completely different part of the site without authentication. This flaw would then inadvertently leak the credentials in the second request.

osv:CURL-CVE-2015-3236
Complete source record
{
  "id": "eb354ad29a4622e5c2332b30fe990ebbe5eba02aae9390aedbe81a8d9a8646bb",
  "url": "https://osv.dev/vulnerability/CURL-CVE-2015-3236",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "lingering HTTP credentials in connection reuse",
    "summary": "libcurl can wrongly send HTTP credentials when reusing connections. libcurl allows applications to set credentials for the upcoming transfer with HTTP Basic authentication, like with `CURLOPT_USERPWD` for example. Name and password. Like all other libcurl options the credentials are sticky and are kept associated with the \"handle\" until something is made to change the situation. Further, libcurl offers a `curl_easy_reset()` function that resets a handle back to its pristine state in terms of all settable options. A reset is of course also supposed to clear the credentials. A reset is typically used to clear up the handle and prepare it for a new, possibly unrelated, transfer. Within such a handle, libcurl can also store a set of previous connections in case a second transfer is requested to a hostname for which an existing connection is already kept alive. With this flaw present, using the handle even after a reset would make libcurl accidentally use those credentials in a subsequent request if done to the same hostname and connection as was previously accessed. An example case would be first requesting a password protected resource from one section of a website, and then do a second request of a public resource from a completely different part of the site without authentication. This flaw would then inadvertently leak the credentials in the second request.",
    "evidence": "osv:CURL-CVE-2015-3236",
    "products": [],
    "severity": "high",
    "structured": {
      "id": "CURL-CVE-2015-3236",
      "aliases": [
        "CURL-CVE-2015-3236",
        "CVE-2015-3236"
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "SEMVER",
              "events": [
                {
                  "introduced": "7.40.0"
                },
                {
                  "fixed": "7.43.0"
                }
              ]
            }
          ],
          "versions": [
            "7.42.1",
            "7.42.0",
            "7.41.0",
            "7.40.0"
          ],
          "database_specific": {
            "source": "https://curl.se/docs/CURL-CVE-2015-3236.json"
          }
        }
      ],
      "modified": "2026-10-24T23:17:46Z",
      "provider": "osv",
      "references": [],
      "provider_metadata": {
        "CWE": {
          "id": "CWE-305",
          "desc": "Authentication Bypass by Primary Weakness"
        },
        "URL": "https://curl.se/docs/CVE-2015-3236.json",
        "www": "https://curl.se/docs/CVE-2015-3236.html",
        "affects": "both",
        "package": "curl",
        "severity": "High",
        "last_affected": "7.42.1"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2015-3236",
        "evidence": "/aliases"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/database_specific/severity"
  },
  "source_id": "core-osv",
  "document_id": 444196,
  "published_at": "2015-06-17T08:00:00+00:00"
}