curl EUVD-2026-105359

Requires an application that sets CURLOPT_INTERFACE (or the curl CLI --interface option) using one of the documented prefixes if!, host!, or ifhost!, AND that performs multiple transfers to the same destination host/port where connections are eligible for curl's connection-reuse pool, with at least two of those transfers requesting different source bindings. Exploitation is limited by the fact that there is no remote attacker vector - the defect is a local library logic error triggered by the application's own transfer sequence; it does not manifest for applications that never set an interface binding, that disable connection reuse, or that always use a single consistent source.

No CVSS vector, EPSS, KEV, or POC data was provided for this issue, so quantitative exploitation signals are entirely absent and the assessment rests on the description and the Ubuntu advisory alone. The flaw is a connection-reuse logic defect in curl: because the CURLOPT_INTERFACE binding (and its if!/host!/ifhost! prefixes) is omitted from the connection-reuse hash key, a later transfer that requests a different source interface or address can silently reuse an existing pooled connection and egress from the earlier transfer's source address. This is a correctness/network-isolation bug rather than a memory-safety or code-execution flaw - there is no attacker-controlled input path, no privilege escalation, and no service disruption. Real-world risk is LOW: it is not remotely triggerable by an adversary and only manifests inside applications that both set the interface binding with the documented prefixes and multiplex multiple transfers to the same host/port. The practical impact is a potential source-based network policy bypass or leakage of which interface/source address traffic appears to originate from. There is no indication of active exploitation (no KEV) and no public exploit identified; this is a defensive correctness fix, not an urgent patch-now priority, though curl's ubiquity means the patch should be adopted during normal update cycles.

An application uses libcurl with CURLOPT_INTERFACE set to a specific source (e.g. if!eth1) for one transfer, then issues a second transfer to the same host requesting a different source binding; curl reuses the first connection and the second transfer silently egresses from the original source address, defeating source-based segmentation or multi-homing intent. This is a latent correctness fault triggered by normal application behavior rather than a crafted attacker payload. No public exploit code has been identified for this issue at the time of analysis.