libsoup EUVD-2026-46361

Exploitation requires three simultaneous conditions: (1) a libsoup-based application must have a prior session where it successfully authenticated to a proxy, leaving credentials cached in SoupAuthManager with no binding to the original proxy host:port; (2) the system proxy configuration must change mid-session - specifically the proxy host, port, or both must differ from the configuration under which credentials were cached, triggered via manual system settings change, WPAD/PAC response change, or network-level DHCP/DNS manipulation; and (3) the newly configured proxy endpoint must be attacker-controlled or observable. The vulnerability does not trigger in static single-proxy environments where the proxy host:port never changes. The UI:R CVSS metric indicates that a libsoup application must make at least one HTTP request after the proxy configuration change for the cached Proxy-Authorization header to be sent. The PR:H metric in the NVD-assigned vector suggests the exploitation context involves elevated access, though whether this reflects attacker privileges or a privileged configuration path is not fully confirmed by available data.

The NVD-assigned CVSS 3.1 score of 3.4 with vector AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:N/A:N is low, reflecting partial confidentiality impact only. The PR:H assignment in this vector warrants scrutiny: from a pure attacker perspective, operating a receiving proxy does not inherently require high privileges on the victim system, suggesting the metric may reflect the complexity of achieving a proxy configuration change in a controlled environment rather than a strict privilege escalation requirement. EPSS data was not provided; the vulnerability is absent from the CISA KEV catalog and no public proof-of-concept has been identified, indicating no confirmed or widespread exploitation. The scope change (S:C) is meaningful - leaked proxy credentials may grant access to protected network resources behind the original proxy. In enterprise environments where dynamic proxy configuration via WPAD or Group Policy is common, the trigger condition is plausible and not merely theoretical. Overall, real-world risk is low for static-proxy deployments but low-to-medium in dynamic proxy environments with sensitive authentication schemes such as Basic or NTLM.

An attacker operating a rogue proxy endpoint positions it to become the victim system's active proxy - either by poisoning a WPAD DNS or DHCP response, or by being the destination of a pushed proxy configuration change via Group Policy. When a GNOME application on the victim's RHEL 10 system makes its next HTTP request, libsoup's SoupAuthManager forwards the cached Proxy-Authorization header from the previous legitimate proxy session to the attacker's proxy, delivering the victim's proxy credentials. The attacker then reuses those credentials to authenticate to the original proxy or pivot to other systems protected by the same credential.