libsoup EUVD-2026-25306

Successful exploitation requires a two-tier HTTP/1 deployment where libsoup acts as the backend HTTP processor behind a reverse proxy, load balancer, or CDN that parses Content-Length headers differently - specifically, where the intermediary and libsoup disagree on which Content-Length value takes precedence when multiple are present. The CVSS AC:H metric directly encodes this constraint. Direct connections to libsoup without an intermediary do not produce a smuggling condition, as there is no second parser to desynchronize against. No authentication is required (PR:N), and no user interaction is needed (UI:N). The vulnerability is limited to HTTP/1 header processing; HTTP/2 connections, which frame body length differently, are not affected by this specific code path. Exploitation is not automatable per SSVC (Automatable: no), further indicating the need for precise architectural preconditions.

Multiple signals converge on low real-world priority. CVSS 3.7 reflects AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N - the High attack complexity (AC:H) is the critical limiting factor, requiring a specific two-tier architecture where an HTTP/1 intermediary (reverse proxy or load balancer) sits in front of a libsoup-backed service and the two components disagree on Content-Length interpretation. EPSS at 0.03% (8th percentile) indicates near-zero observed exploitation pressure. SSVC confirms exploitation: none, automatable: no, technical impact: partial - aligning with the CVSS assessment. The vulnerability is not in CISA KEV and no public exploit code has been identified. The integrity-only impact (I:L, C:N, A:N) further limits blast radius; this is a request injection path, not a code execution primitive. Real-world risk is low unless libsoup applications are deployed behind HTTP/1 proxies without header normalization - an uncommon production pattern for a desktop-oriented HTTP library.

An attacker targeting an application where a front-end reverse proxy (e.g., nginx or HAProxy) forwards HTTP/1 requests to a libsoup-backed backend crafts a request containing two Content-Length headers with different values - for example, Content-Length: 0 followed by Content-Length: 44. The front-end proxy consumes the request body based on the first value (0 bytes), while libsoup reads 44 bytes from what the proxy considers the start of the next pipelined request, effectively treating the attacker-supplied data as a new HTTP request. This allows the attacker to inject an unauthorized request into the server's processing queue, potentially targeting other users' sessions or bypassing path-based access controls enforced only at the proxy layer.