On April 7, 2026, the Okta Red Team reported a denial-of-service condition in HTTP/2 flow control via VINCE that could allow a remote, unauthenticated threat actor to exhaust server memory and disrupt service. This attack uses a setting that is valid under the HTTP/2 specification, where no malformed frames or protocol violations are required.
HTTP/2 allows a client to tell a server how much response data it is ready to receive. By setting SETTINGS_INITIAL_WINDOW_SIZE to zero, a threat actor can prevent the server from sending response data while continuing to issue requests.
The server must honor that instruction. It can continue processing requests, but it cannot transmit the resulting response data until the client opens the flow-control window. If the server does not impose its own limits or timeouts, those responses remain in memory while the threat actor keeps the connection open.
By requesting large resources across many streams, a threat actor can make response data accumulate rapidly while using very little bandwidth. In testing, a single machine was able to create significant memory and swap pressure. When the connection closed, releasing the blocked data also caused sharp CPU and I/O spikes, potentially resulting in a complete service outage.
Recent HTTP/2 denial-of-service vulnerabilities have often been addressed with implementation-level safeguards, such as stricter timeouts or stream limits. This issue is different: the behavior follows the protocol as written.
RFC 9113 permits a zero-sized flow-control window but does not require a memory cap, timeout, or maximum lifetime for streams whose responses cannot be sent. HTTP/2-enabled application servers, proxies, and load balancers may therefore need to account for this condition independently.
It’s recommended that operators assess HTTP/2 implementations for memory growth when response data is flow-control blocked. Relevant safeguards may include connection, stream, buffering, and timeout limits, along with monitoring for unusual zero-window connections.
For more background, see RFC 9113, including its sections on flow control and HTTP/2 settings. For vulnerability-related details, see the related CVE records:
This research was conducted to explore an emerging security challenge and help strengthen the resilience of the broader cyber community, as part of Okta’s broader commitment to secure identity. Through the Okta Secure Identity Commitment (OSIC), we’re raising the bar for the industry by investing in stronger protections, greater transparency, and collaboration across the security community.
Okta also participates in the broader ethical security community through its Bugcrowd security research engagement, and welcomes collaboration with security researchers and supports disclosure reporting through its Responsible Disclosure Program.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。