CVE-2026-85534 in Red Hat
Summary
by MITRE • 09/04/2026
A flaw was found in libsoup. When a client sends an HTTP/2 request body from a non-pollable input stream, the library can buffer more data than the current flow-control window later allows. A malicious HTTP/2 server can shrink SETTINGS_INITIAL_WINDOW_SIZE while that buffered read is still in progress. The client then copies the full buffer into a smaller DATA callback without a runtime bounds check, which can abort the process or fail the HTTP/2 session.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within libsoup represents a critical flaw in the handling of HTTP/2 flow control mechanisms during data transmission from non-pollable input streams. In standard network programming, an input stream is considered pollable if its readiness for reading can be determined without blocking, typically via event notification systems like epoll or kqueue. However, when dealing with non-pollable sources such as certain file descriptors or memory buffers that do not support immediate status checks, the library employs a buffering strategy to manage data availability. The core technical flaw arises from a mismatch between the amount of data buffered by libsoup and the current flow-control window size advertised by the server. Specifically, when a client initiates an HTTP/2 request with a body sourced from such a non-pollable stream, libsoup may buffer more data than is permitted by the dynamic flow control limits established during the session setup or modified subsequently.
This discrepancy becomes exploitable through a specific sequence of actions orchestrated by a malicious HTTP/2 server. The attacker leverages the ability to send SETTINGS frames that adjust the INITIAL_WINDOW_SIZE parameter after the client has already begun buffering data for transmission. By shrinking this window size while the buffered read operation is still in progress, the server effectively reduces the allowable amount of data that can be sent without triggering a flow control error. Despite this reduction, libsoup proceeds to copy the entire pre-buffered content into the DATA frame callback mechanism responsible for transmitting payload data over the network connection. Crucially, this copying process lacks runtime bounds checking against the newly restricted window size. This absence of validation means the library attempts to transmit more data than the protocol allows, violating HTTP/2 flow control rules which are designed to prevent sender congestion and ensure fair resource usage across multiplexed connections.
The operational impact of this vulnerability is primarily characterized by service disruption rather than remote code execution or information disclosure in its current manifestation. When libsoup detects that it has exceeded the allowed window size during transmission, or when the underlying HTTP/2 stack encounters an invalid frame due to excessive data length relative to the flow control state, the process typically aborts abruptly. This results in a denial of service for the client application utilizing libsoup, as the connection is terminated and any ongoing transactions are failed. For applications relying on continuous connectivity or high-throughput data uploads, such abrupt terminations can lead to significant operational instability, requiring manual intervention or complex retry logic that may not fully recover from protocol-level errors caused by malformed state transitions.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-401 Missing Release of Memory after Successful Exit if the buffer management leads to resource leaks upon abort. In terms of adversarial tactics, it relates to MITRE ATT&CK techniques involving protocol manipulation, specifically those that exploit state machine inconsistencies or flow control mechanisms to disrupt service availability. The flaw highlights a common challenge in network library development where asynchronous I/O patterns and dynamic protocol parameters must be synchronized with strict validation checks at every stage of data processing.
Mitigation strategies for this vulnerability involve both immediate patching by the maintainers of libsoup and defensive programming practices for developers integrating the library. The primary remediation is to apply updates that include bounds checking within the DATA callback logic, ensuring that any buffered data exceeding the current flow control window is either truncated safely or handled through a retry mechanism that respects dynamic window adjustments. Developers should also consider implementing custom stream handling routines that monitor flow control states more aggressively when using non-pollable inputs, potentially by polling for readiness before buffering large chunks of data. Additionally, configuring client-side timeouts and connection reset policies can help mitigate the impact of such disruptions in production environments where malicious servers might be encountered.