curl libcurl CVE-2026-94266

Exploitation requires the specific combination: the application must supply a URL containing embedded userinfo credentials (username:password@host), and must then call CURLINFO_EFFECTIVE_URL and expose or persist the returned string (logging, UI display, telemetry, or forwarding). The password is only leaked for curl/libcurl versions 7.62.0 through 8.22.0; it is fixed in 8.23.0. Limiting factors: there is no remote attacker vector - disclosure is to a sink the host application already controls, so impact depends entirely on how the application handles the effective URL; deployments that do not put passwords in URLs or do not read this info field are unaffected.

This is a LOW severity information-disclosure flaw as rated by the curl project itself (the authoritative vendor), and no independent severity signals contradict or elevate that. No CVSS vector, CWE, EPSS score, KEV listing, or POC is present in the input, so automated exploitation-probability signals are entirely absent - this is not a KEV-listed or known-exploited issue ('no public exploit identified at time of analysis'). The weakness is that libcurl's CURLINFO_EFFECTIVE_URL returns the final URL with the cleartext password preserved in the userinfo component, so an application that reads and then logs, displays, or forwards that string can inadvertently expose a credential that the developer assumed curl would redact. The real-world risk is modest and contingent: it requires an application that (a) passes credentials embedded in the URL and (b) consumes and exposes the effective URL. There is no remote attacker primitive here - the signal set is consistent (vendor LOW, no exploitation data), and the honest read is 'low real risk despite curl's ubiquity,' because the affected code path depends on specific application behavior rather than default remote-reachable exposure. Note the absence of a CVSS vector means authentication/attack-vector characteristics are inferred, not confirmed.

An application uses libcurl with a URL containing embedded credentials (e.g. https://user:secret@host/path) and, after the transfer, queries CURLINFO_EFFECTIVE_URL and writes the result to a log file, telemetry stream, or UI. The returned URL still contains the cleartext password, so the secret is leaked into whatever sink the application exposes it to. No public exploit code is identified; exploitation is passive credential disclosure rather than an active remote attack.