curl libcurl CVE-2026-86415

Requires an application built on libcurl that uses automatic client-certificate selection on a TLS backend supporting it, AND connection reuse/pooling active across transfers whose client-certificate requirements differ. Limiting factors that reduce real-world risk: this is not remote unauthenticated exploitation of a default config - it depends on the host application's specific client-certificate and reuse configuration, is not triggerable by an arbitrary external attacker sending a single request, and only manifests when multiple transfers with differing certificate expectations share a connection; versions after 8.22.0 (i.e. 8.23.0+) are fixed.

This is genuinely a LOW-severity issue, not a high-CVSS-but-low-risk inflation case - the severity rating of LOW is assigned directly by the curl project (the authoritative vendor) in its official 8.23.0 advisory. No CVSS vector, CWE, EPSS probability, KEV listing, SSVC decision, or public PoC was provided in the input, so there is no signal of active or likely exploitation; the only strong signal present is the vendor's own LOW classification. The flaw is a connection-reuse logic error (a pooled TLS connection established with automatic client-certificate selection being reused for a transfer with mismatched client-cert expectations), which is a correctness/confidentiality concern affecting applications that use libcurl in a specific way rather than a directly attacker-driven remote compromise. Because CVSS/EPSS/KEV/PoC data are all absent, authentication and exploitability cannot be independently confirmed from the input - the assessment below is inferred from the vulnerability title and curl's known connection-reuse behavior and should be verified against the per-CVE page at curl.se/docs/security.html. Net: low operational priority, patch in normal maintenance cycle.

An application using libcurl with automatic client-certificate selection performs multiple transfers over a shared connection pool; curl reuses a connection originally negotiated with a client certificate for a subsequent request that should have used a different certificate or none, causing the wrong client identity to be presented to (or confused across) origins. No public exploit code was identified in the provided data, and exploitation depends on the host application's reuse pattern and TLS backend rather than a single crafted network message.