libcurl CVE-2026-61813

Exploitation requires (1) the affected application to perform an outbound HTTPS fetch using libcurl configured with weak hostname verification - consistent with CURLOPT_SSL_VERIFYHOST not being set to the strict value (2) so a certificate whose Common Name/SAN does not match the requested host is accepted; and (2) an active adversary-in-the-middle position on the network path (rogue access point, ARP/DNS spoofing, malicious upstream proxy, or control of a routing hop) to present the mismatched certificate and intercept traffic. Limiting factors: the attack is not exploitable by a purely remote attacker lacking a traffic-interception position, and clients that only ever connect over fully trusted network paths are not realistically exposed. The exact affected product, versions, and whether the weak setting is default or configuration-dependent are not specified in the available data.

No CVSS vector, EPSS score, KEV listing, or POC is provided in the input, so quantitative exploitation signals are entirely absent and cannot be compared. The only hard facts are the vulnerability class (weak libcurl TLS hostname verification during HTTPS fetches, consistent with CWE-297 Improper Validation of Certificate with Host Mismatch) and that it was reported via vendor:ubuntu against a GitHub Security Advisory (GHSA-2vqc-36qp-ccmw). This is a classic transport-security weakness: the real-world risk is conditional rather than universal because successful attack requires an adversary-in-the-middle (AITM) position on the network path between the affected client and the HTTPS endpoint. That positioning requirement typically lowers practical exploitability relative to a raw 'network' vector, so even if a high CVSS were assigned it would likely overstate everyday risk for clients on trusted networks while understating it for clients that routinely traverse hostile networks (public Wi-Fi, untrusted upstreams, cloud egress through untrusted proxies). Because no EPSS or KEV data is present, there is no evidence of active or widespread exploitation - exploitation status is 'no public exploit identified at time of analysis.' The affected product is not explicitly named in the input, which is the single largest gap: without it, the deployment footprint and blast radius cannot be reliably scoped. This should be triaged as a genuine confidentiality/integrity-of-transit defect to patch, not a mass-exploitation emergency.

An attacker who can position themselves on the network path (e.g., rogue Wi-Fi access point, ARP/DNS spoofing, or a compromised upstream proxy) intercepts the affected application's outbound HTTPS request. Because libcurl hostname verification is weak, the attacker presents a certificate whose hostname does not match the intended server, and the client accepts it, letting the attacker decrypt, read, and tamper with the supposedly secure traffic. No public exploit code is identified at time of analysis, but exploitation requires only standard AITM tooling once positioning is achieved.