Security advisory watch
A newly documented HTTP/2 denial-of-service issue shows how stalled flow-control behavior can turn ordinary web requests into server-side memory pressure. The issue is tracked by CERT/CC as VU#885548 and affects some HTTP/2 server implementations that continue generating response bodies even when a client prevents outbound data from being sent.
The practical takeaway is not that HTTP/2 is broken. The operational risk is that some implementations and default configurations may not enforce resource ceilings aggressively enough when streams stall.
Published: July 25, 2026
Primary topic: Cybersecurity / Infrastructure Security
Status: Developing vendor remediation and configuration review story
What happened
CERT/CC published Vulnerability Note VU#885548, describing a denial-of-service condition in some HTTP/2 server implementations. The issue involves stalled flow-control conditions where a remote, unauthenticated client can advertise a very small or zero receive window, withhold WINDOW_UPDATE frames, and keep multiple request streams open.
In affected implementations, the server may keep processing requests and generating responses even though the response data cannot be sent to the client. That response data can remain buffered in memory until the connection closes, a timeout fires, or the service runs out of usable resources.
Cyber Security News summarized the issue on July 24, reporting that the bug can allow unauthenticated attackers to crash vulnerable servers through memory exhaustion. The more useful operational framing is narrower: exposed HTTP/2 services should be checked for affected implementations, patched vendor builds, stalled-stream handling, and memory or connection safeguards.
Why this matters
This is a resource-exhaustion problem, not a traditional bandwidth flood. That distinction matters because a service can be in trouble even when network traffic volume does not look dramatic. A small number of carefully handled HTTP/2 connections may create disproportionate memory pressure if the server buffers responses without enforcing practical limits.
Administrator guidance: Do not rely only on perimeter DDoS volume metrics. Also watch worker memory, HTTP/2 stream counts, stalled connections, response buffering, swap activity, and connection pool exhaustion.
CERT/CC says that permissive resource limits can lead to excessive memory use, swap exhaustion, service instability, or system crashes. Even in more conservative environments, the same pattern can exhaust workers or connection resources and temporarily block legitimate users from establishing sessions.
Who is affected
The affected surface is implementation-specific. CERT/CC lists several vendors and projects as affected, not affected, or still under various status states. The vendor table includes affected entries for Apache Traffic Server, Citrix NetScaler ADC and NetScaler Gateway in certain HTTP/2-enabled configurations, F5 Networks, Meta, Red Hat, SUSE Linux, and Yahoo.
CERT/CC also lists a number of vendors or projects as not affected, including Cloudflare, Fastly, GitHub, Go, gRPC, HAProxy, hyperium, lighttpd, LiteSpeed Technologies, nghttp2, and others. That split is important: the issue should be treated as a class of HTTP/2 implementation and configuration failure, not as a universal statement that every HTTP/2 deployment is vulnerable.
| Environment | Review priority |
|---|---|
| Public HTTP/2 reverse proxies | High. Review vendor advisories, stream limits, memory ceilings, and timeout behavior. |
| Load balancers and ADCs | High. Confirm whether HTTP/2 is enabled on affected profiles, virtual servers, or services. |
| Self-hosted web stacks | Medium to high. Check whether the exposed component terminates HTTP/2 and whether it has fixed builds. |
| CDN-fronted sites | Variable. Confirm the CDN/provider status and whether origin HTTP/2 is exposed directly. |
| Internal-only services | Medium. Risk depends on trust boundary, segmentation, and whether untrusted clients can reach the service. |
Technical details in plain terms
HTTP/2 uses flow control so that one side of a connection does not overwhelm the other side with more data than it is prepared to receive. A client advertises how much data it is willing to accept. Normally, as data is processed, the client sends WINDOW_UPDATE frames to allow more data to be transmitted.
The failure pattern described by CERT/CC happens when the client intentionally stalls that outbound path. For example, the client may advertise SETTINGS_INITIAL_WINDOW_SIZE = 0 or withhold WINDOW_UPDATE frames. If the server keeps generating response bodies anyway, those responses may accumulate in memory instead of being sent across the network.
That makes the attack efficient. The attacker does not need to send massive traffic. The server does the expensive part by creating and holding response data for streams that are intentionally prevented from draining.
What administrators should do now
- Inventory exposed HTTP/2 termination points. Include reverse proxies, application delivery controllers, load balancers, web servers, API gateways, service meshes, and CDN-to-origin paths.
- Check vendor status against CERT/CC VU#885548. Do not assume one web server, proxy, or appliance status applies to another.
- Apply fixed vendor builds where available. CERT/CC notes that several vendors have already addressed the issue in recent updates.
- Review HTTP/2 stream and connection limits. Lower concurrent stream ceilings where practical, especially on services that do not require high multiplexing levels.
- Enforce response-buffer memory ceilings. Implementations should not allow stalled streams to accumulate unbounded response data.
- Terminate stalled flow-control behavior. Time out or reset connections that keep streams open while refusing to receive response data.
- Monitor for symptoms. Look for rising worker RSS, swap churn, elevated HTTP/2 stream counts, unusual connection duration, stalled responses, and connection pool exhaustion.
Operational perspective: The best mitigation pattern is layered. Patch the affected implementation, then make sure resource ceilings and stalled-stream timeouts would still protect the service if a similar protocol-level resource abuse pattern appears later.
Vendor-specific notes
Citrix told CERT/CC that NetScaler ADC and NetScaler Gateway are impacted when HTTP/2 is enabled in the HTTP Profile and associated with certain virtual server or service configurations. Citrix recommended fixed builds and, for environments not using HTTP Strict Profiles, setting the new Http2SmallWndTimeout parameter after upgrading.
Yahoo’s statement in the CERT/CC note describes Apache Traffic Server behavior where the HTTP/2 stream limit was advisory rather than hard-enforced. Yahoo says the issue was fixed in Apache Traffic Server 9.2.14 and 10.1.3 by hard-enforcing limits with REFUSED_STREAM.
F5 is listed by CERT/CC as affected, with a reference to its BIG-IP HTTP/2 advisory for CVE-2026-59762. Operators with BIG-IP in front of production services should review that vendor advisory directly rather than relying on generic HTTP/2 guidance.
What remains uncertain
As of this writing, the CERT/CC vendor table still contains mixed statuses, unknown CVE applicability for some vendors, and vendor-specific remediation details. That means the safe answer is not “turn HTTP/2 off everywhere.” The safer answer is to identify where HTTP/2 is terminated, match each product to current vendor guidance, and apply both patches and configuration controls.
There is also a terminology trap around “HTTP/2 Bomb.” Some public discussion has used that label for several related but distinct HTTP/2 resource-exhaustion ideas, including header compression and slow-stream patterns. CERT/CC’s current VU#885548 advisory is specifically about stalled flow-control conditions and buffered response data in affected implementations.
RavenHawkTech analysis
This is the kind of vulnerability that rewards boring operational discipline. The organizations in the best position are the ones that already know where HTTP/2 terminates, which devices and proxies sit on the edge, what version they run, and what resource limits are actually enforced.
The larger lesson is that modern protocols often move risk from raw bandwidth toward state, buffering, queues, and implementation behavior. A service can be harmed not only by too much traffic, but by traffic that causes it to hold the wrong kind of state for too long.
For small businesses, homelab operators, and self-hosters, the practical move is simple: do not expose origin services directly if a CDN or reverse proxy is supposed to be absorbing internet-facing protocol weirdness. If origin HTTP/2 is exposed, verify whether that is intentional. If it is not needed, reducing the exposed protocol surface may be a reasonable temporary control while patches and vendor guidance are reviewed.
Sources and further reading
- CERT/CC VU#885548: Denial-of-service vulnerability in HTTP/2 servers via stalled flow-control conditions
- Cyber Security News: New HTTP/2 vulnerability lets hackers crash servers with memory exhaustion attacks
- oss-sec: CVE-2026-59173 — Apache Traffic Server stalled HTTP/2 flow-control issue
RavenHawkTech will update this article if vendor guidance changes or if additional affected implementations are confirmed.