libsoup CVE-2026-85197

Exploitation requires the victim to be running a GNOME application that performs HTTP/2 file uploads (not all libsoup usage is HTTP/2 or file-upload based - HTTP/1.x connections are not affected). The attacker must control the HTTP/2 server the application connects to (direct malicious server) or be in a network position to intercept and inject HTTP/2 frames (MITM). The victim must actively initiate the upload (confirmed by UI:R in the CVSS vector). Factors limiting exploitation: the race window between GOAWAY receipt and async read completion is narrow and may require timing or repeated attempts; reliable RCE further requires heap-layout manipulation; and TLS (HTTPS) connections defeat passive MITM unless certificates are compromised. HTTP/1.x-only deployments of libsoup are entirely unaffected.

The provided CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H yields 7.6, which is a reasonable baseline. AV:N/AC:L reflects that the malicious-server scenario requires no special network position, while the MITM scenario would imply AC:H - the OR condition justifies AC:L for the worst case. UI:R is accurate: exploitation requires the victim's GNOME application to initiate an HTTP/2 file upload to an attacker-controlled endpoint. The A:H rating reflects near-certain crash on heap corruption; C:L and I:L acknowledge that full RCE - while theoretically possible - requires reliable heap layout control. No EPSS score is provided in the input and no CISA KEV listing exists. No public exploit or proof-of-concept code has been identified. In practice, this is a client-side vulnerability requiring either social engineering (directing users to a malicious server) or network-level MITM - both raise the real-world exploitation bar above what the CVSS score alone implies. Organizations running GNOME desktops in threat models where users access untrusted or attacker-influenced HTTP/2 services (file sync clients, update mechanisms, web-based GNOME apps) should prioritize patching.

An attacker registers or compromises an HTTP/2-capable server that a victim's GNOME application uploads files to - for example, a Nextcloud or WebDAV endpoint, or a compromised Flatpak remote. When the victim's GNOME application initiates a file upload, the attacker's server immediately responds with an HTTP/2 GOAWAY frame, racing with the asynchronous body read in libsoup. The freed buffer is accessed by the dangling callback, corrupting heap memory in the GNOME application process, potentially allowing the attacker to redirect execution to shellcode or leak heap contents. No public proof-of-concept code is known at this time.