Vulnerability
curl/libcurl: Reusing authenticated connection when unauthenticated
libcurl keeps a pool of its last few connections around after use to facilitate easy, convenient and completely transparent connection reuse for applications. When doing HTTP requests NTLM authenticated, the entire connection becomes authenticated and not only the specific HTTP request which is otherwise how HTTP works. This makes NTLM special and a subject for special treatment in the code. With NTLM, once the connection is authenticated, no further authentication is necessary until the connection gets closed. libcurl's connection reuse logic selects an existing connection for reuse when asked to do a request, and when asked to use NTLM libcurl have to pick a connection with matching credentials only. If a connection was first setup and used for an NTLM HTTP request with a specific set of credentials, that same connection could later wrongly get reused in a subsequent HTTP request that was made to the same host - but without having any credentials set! Since an NTLM connection was already authenticated due to how NTLM works, the subsequent request could then get sent over the wrong connection appearing as the initial user. This problem is similar to the previous problem known as [CVE-2014-0015](https://curl.se/docs/CVE-2014-0015.html). The main difference this time is that the subsequent request that wrongly reuse a connection does not ask for NTLM authentication.
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.
Above the FIRST 'patch on a priority schedule' threshold.
No VEX statements published for CVE-2015-3143. 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