CVE-2026-85197 in Red Hat
Summary
by MITRE • 09/04/2026
A flaw was found in libsoup. A malicious HTTP/2 server or a Man-in-the-Middle (MITM) attacker can exploit a heap use-after-free vulnerability in the HTTP/2 client implementation. This occurs when a GNOME application uploads a file using HTTP/2, and the server sends a GOAWAY frame while the file body is being read asynchronously. This can lead to memory corruption, potentially resulting in information disclosure or arbitrary code execution.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within libsoup represents a critical heap use-after-free condition embedded deep within its HTTP/2 client implementation. This flaw arises from an improper handling of asynchronous operations during file uploads when the connection state changes unexpectedly. Specifically, the issue is triggered when a GNOME-based application initiates a file upload via HTTP/2 and the server responds with a GOAWAY frame while the body data is still being read asynchronously in the background. The GOAWAY frame signals to the client that the server will no longer accept new requests on this connection, typically due to administrative shutdown or internal errors. However, libsoup fails to properly synchronize the lifecycle of the asynchronous I/O operations with the termination of the HTTP/2 stream and session context. Consequently, memory buffers associated with the pending read operation are freed prematurely by the connection teardown logic while pointers to these buffers remain active in the async task queue.
From a technical perspective, this race condition allows for heap corruption because the application continues to access or attempt to free already released memory regions. In C-based libraries like libsoup, which manage memory manually, such use-after-free scenarios are particularly dangerous as they can lead to undefined behavior depending on how quickly the freed memory is reallocated by other processes or threads. If an attacker controls the data written into these reused heap slots during the window between deallocation and subsequent access, they may achieve arbitrary code execution with the privileges of the vulnerable application. Even without successful exploitation for code execution, the mere act of reading from invalid memory can result in information disclosure, leaking sensitive contents stored adjacent to the freed buffer or causing crashes that disrupt service availability.
The operational impact is significant because libsoup serves as a foundational HTTP client library used by many prominent GNOME applications and desktop environments. An attacker positioned as a malicious HTTP/2 server or acting as a Man-in-the-Middle can exploit this vulnerability remotely without requiring user interaction beyond the initial network connection establishment, provided the victim application performs an upload operation over HTTPS using HTTP/2. This expands the attack surface considerably compared to vulnerabilities that require specific file types or complex input vectors. The ability to trigger memory corruption through standard protocol frames like GOAWAY means that any infrastructure component interacting with untrusted servers via libsoup is potentially at risk, affecting data integrity and confidentiality across a wide range of enterprise and consumer software ecosystems.
This vulnerability aligns closely with CWE-416, which describes Use After Free errors where program execution continues after memory has been freed, leading to unpredictable behavior. Furthermore, the exploitation vector relates to ATT&CK technique T1059, Command and Scripting Interpreter, if the use-after-free is leveraged to execute arbitrary commands on the host system through heap spraying or other code reuse techniques common in modern exploit development. The MITM aspect also touches upon aspects of session hijacking or protocol downgrade attacks where an attacker forces a connection state change to trigger the race condition.
Mitigation strategies must focus on both immediate patching and architectural improvements within application logic. Developers should update libsoup to versions that include fixes for this asynchronous cleanup synchronization issue, ensuring that pending I/O tasks are properly cancelled and their resources safely released before any stream or session teardown occurs. For organizations relying on GNOME applications, applying system-level package updates is the primary defense vector. Additionally, network security controls such as strict TLS certificate validation can help mitigate Man-in-the-Middle scenarios by preventing attackers from intercepting traffic to inject malicious GOAWAY frames. Long-term remediation should involve implementing stricter state management in HTTP/2 clients, ensuring that all asynchronous operations are explicitly aborted and their memory contexts invalidated before any connection closure logic is executed, thereby eliminating the race window entirely.