FKIE_CVE-2026-1965

Vulnerability from fkie_nvd - Published: 2026-03-11 11:15 - Updated: 2026-03-12 14:11
Severity ?
6.5 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Summary
libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
References
2499f714-1537-4658-8207-48ae4bb9eae9https://curl.se/docs/CVE-2026-1965.htmlPatch, Vendor Advisory
2499f714-1537-4658-8207-48ae4bb9eae9https://curl.se/docs/CVE-2026-1965.jsonVendor Advisory
Impacted products
Vendor Product Version
haxx curl *
To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:haxx:curl:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "16DD9E3A-305E-4F7E-A8A1-FFFD1D44B147",
              "versionEndExcluding": "8.19.0",
              "versionStartIncluding": "7.10.6",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "libcurl can in some circumstances reuse the wrong connection when asked to do\nan Negotiate-authenticated HTTP or HTTPS request.\n\nlibcurl features a pool of recent connections so that subsequent requests can\nreuse an existing connection to avoid overhead.\n\nWhen reusing a connection a range of criterion must first be met. Due to a\nlogical error in the code, a request that was issued by an application could\nwrongfully reuse an existing connection to the same server that was\nauthenticated using different credentials. One underlying reason being that\nNegotiate sometimes authenticates *connections* and not *requests*, contrary\nto how HTTP is designed to work.\n\nAn application that allows Negotiate authentication to a server (that responds\nwanting Negotiate) with `user1:password1` and then does another operation to\nthe same server also using Negotiate but with `user2:password2` (while the\nprevious connection is still alive) - the second request wrongly reused the\nsame connection and since it then sees that the Negotiate negotiation is\nalready made, it just sends the request over that connection thinking it uses\nthe user2 credentials when it is in fact still using the connection\nauthenticated for user1...\n\nThe set of authentication methods to use is set with  `CURLOPT_HTTPAUTH`.\n\nApplications can disable libcurl\u0027s reuse of connections and thus mitigate this\nproblem, by using one of the following libcurl options to alter how\nconnections are or are not reused: `CURLOPT_FRESH_CONNECT`,\n`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the\ncurl_multi API)."
    },
    {
      "lang": "es",
      "value": "libcurl puede en algunas circunstancias reutilizar la conexi\u00f3n incorrecta cuando se le pide que realice una solicitud HTTP o HTTPS autenticada con Negotiate.\n\nlibcurl cuenta con un grupo de conexiones recientes para que las solicitudes posteriores puedan reutilizar una conexi\u00f3n existente y evitar la sobrecarga.\n\nAl reutilizar una conexi\u00f3n, una serie de criterios deben cumplirse primero. Debido a un error l\u00f3gico en el c\u00f3digo, una solicitud emitida por una aplicaci\u00f3n podr\u00eda reutilizar err\u00f3neamente una conexi\u00f3n existente al mismo servidor que fue autenticado usando credenciales diferentes. Una raz\u00f3n subyacente es que Negotiate a veces autentica *conexiones* y no *solicitudes*, al contrario de c\u00f3mo HTTP est\u00e1 dise\u00f1ado para funcionar.\n\nUna aplicaci\u00f3n que permite la autenticaci\u00f3n Negotiate a un servidor (que responde queriendo Negotiate) con \u0027user1:password1\u0027 y luego realiza otra operaci\u00f3n al mismo servidor tambi\u00e9n usando Negotiate pero con \u0027user2:password2\u0027 (mientras la conexi\u00f3n anterior sigue activa) - la segunda solicitud reutiliz\u00f3 err\u00f3neamente la misma conexi\u00f3n y dado que luego ve que la negociaci\u00f3n de Negotiate ya est\u00e1 hecha, simplemente env\u00eda la solicitud a trav\u00e9s de esa conexi\u00f3n pensando que usa las credenciales de user2 cuando de hecho sigue usando la conexi\u00f3n autenticada para user1...\n\nEl conjunto de m\u00e9todos de autenticaci\u00f3n a usar se establece con \u0027CURLOPT_HTTPAUTH\u0027.\n\nLas aplicaciones pueden deshabilitar la reutilizaci\u00f3n de conexiones de libcurl y as\u00ed mitigar este problema, usando una de las siguientes opciones de libcurl para alterar c\u00f3mo las conexiones son o no son reutilizadas: \u0027CURLOPT_FRESH_CONNECT\u0027, \u0027CURLOPT_MAXCONNECTS\u0027 y \u0027CURLMOPT_MAX_HOST_CONNECTIONS\u0027 (si se usa la API curl_multi)."
    }
  ],
  "id": "CVE-2026-1965",
  "lastModified": "2026-03-12T14:11:19.070",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 6.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-03-11T11:15:59.177",
  "references": [
    {
      "source": "2499f714-1537-4658-8207-48ae4bb9eae9",
      "tags": [
        "Patch",
        "Vendor Advisory"
      ],
      "url": "https://curl.se/docs/CVE-2026-1965.html"
    },
    {
      "source": "2499f714-1537-4658-8207-48ae4bb9eae9",
      "tags": [
        "Vendor Advisory"
      ],
      "url": "https://curl.se/docs/CVE-2026-1965.json"
    }
  ],
  "sourceIdentifier": "2499f714-1537-4658-8207-48ae4bb9eae9",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-305"
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "type": "Secondary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.