CVE-2026-107929 in curl
Summary
by MITRE • 10/21/2026
When `CURLOPT_INTERFACE` (or the command line tool's `--interface` option) is set with one of the documented prefixes (`if!`, `host!`, `ifhost!`), that binding is not part of the connection reuse key, so a later transfer asking for a different source can silently reuse an existing connection and go out from the earlier transfer's source address
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in libcurl involves a critical flaw in how network interface bindings are managed during HTTP or protocol transfers. Specifically, when the CURLOPT_INTERFACE option is configured with one of its documented prefixes such as if or ifhost!, the resulting binding configuration is inadvertently excluded from the connection reuse key calculation. This oversight means that the internal mechanism responsible for determining whether an existing persistent connection can be reused does not account for the specific source address or network interface associated with a previous transfer. Consequently, when a subsequent request requires a different source IP address or network interface, libcurl may incorrectly determine that a previously established connection is suitable and reuse it without re-binding to the newly requested interface.
This behavior leads to a silent failure where data intended for one specific network path or source identity is instead transmitted through another. For organizations relying on multi-homed systems or complex routing configurations, this can result in traffic egressing from an unintended network interface. The implications are significant as it undermines the predictability of network flows and can lead to connectivity issues if the reused connection's associated IP address is not routable for the destination required by the new request. Furthermore, in security-sensitive environments where source IP addresses are used for access control or auditing purposes, this behavior could allow traffic to bypass intended restrictions simply because a persistent connection was retained from an earlier session with different binding parameters.
From a vulnerability classification perspective, this issue aligns with CWE-20 Improper Input Validation as the library fails to properly validate that all relevant context variables are included in state management decisions for connection pooling. It also relates to CWE-671 Lack of Default Protection Against Connection Reuse Attacks because the reuse logic does not sufficiently isolate connections based on distinct binding criteria, potentially allowing unintended data leakage across different logical network paths. In terms of MITRE ATT&CK mapping, this flaw could be leveraged in scenarios involving Network Service Scanning or Defense Evasion if an attacker can manipulate connection states to mask their true origin point, although the primary impact here is functional reliability rather than direct exploitation for malicious access.
To mitigate this risk, users should ensure they are running a version of libcurl where this bug has been patched and that the connection reuse key logic correctly incorporates interface binding details into its hash or comparison process. Developers integrating libcurl must be aware that relying on persistent connections across requests with varying source interfaces requires explicit disconnection handling to prevent unintended reuse. It is advisable to disable connection pooling for transfers involving dynamic interface selection or to explicitly close existing connections when switching between different network bindings. Regular updates and adherence to best practices in managing HTTP client state are essential to maintaining the integrity of multi-homed network operations.