HTTP/2 Bomb is a newly disclosed remote denial-of-service attack, published in early June 2026 by Calif researchers, that can exhaust memory on default HTTP/2 deployments of nginx, Apache HTTP Server, Microsoft IIS, Envoy, and Cloudflare’s Pingora. The uncomfortable part is not that HTTP/2 has another bug; it is that ordinary protocol machinery can be turned into a surprisingly efficient memory trap. The attack is a reminder that “modern web performance” often means moving complexity from the wire into the server. When that complexity is undercounted, attackers do not need much bandwidth to make a system do expensive work.
HTTP/2 was designed to make the web less wasteful. It multiplexes requests over fewer connections, compresses headers, and gives clients and servers better control over how data flows between them. For users, that usually means faster pages and fewer visible seams. For administrators, it means more state, more accounting, and more ways for an apparently small request to become large inside the server.
HTTP/2 Bomb exploits that gap between what crosses the network and what the server must remember. The attacker is not blasting a site with huge payloads in the classic volumetric style. Instead, the client sends compact HTTP/2 header references and then uses flow-control behavior to keep the server from clearing the resulting state.
That distinction matters. Many organizations have spent years hardening against big requests, oversized headers, and floods that show up clearly in bandwidth graphs. HTTP/2 Bomb is more subtle: the traffic can be comparatively small, while the memory growth happens after decoding, bookkeeping, queuing, and response stalling.
The reported test numbers make the point bluntly. Envoy 1.37.2 reportedly reached 32 GB of memory consumption in about 10 seconds, Apache httpd 2.4.67 in about 18 seconds, nginx 1.29.7 in about 45 seconds, and Microsoft IIS on Windows Server 2025 reached 64 GB in about 45 seconds. Even allowing for lab conditions, those are not nuisance figures; they are outage figures.
But compression always has a dangerous edge. A tiny thing on the wire can become a much bigger thing after expansion. That principle is old, but HTTP/2 Bomb shows how it still matters when the “big thing” is not merely the decoded byte count but the collection of objects and metadata created as the server processes the request.
The researchers’ account says the attack sends small indexed header references that expand into larger server-side allocations. In other words, the server is induced to do the normal job HTTP/2 requires it to do: interpret compressed headers and construct an internal representation of the request. The payload does not need to look obviously abusive if the abuse is in the ratio between network input and internal state.
That is why this is not just a story about maximum header size. A server can enforce a limit on decoded bytes and still be vulnerable if it allows too many individual header fields, too much per-header bookkeeping, or too much intermediate state per stream. The accounting boundary is not the same as the cost boundary.
In this attack, the mechanism becomes a holding pattern. The client can stall the response path so the server cannot promptly release allocations associated with streams, headers, and response handling. Instead of a burst of work that finishes and frees memory, the server is pushed into retaining state long enough for the attacker to stack more pressure on top.
That makes HTTP/2 Bomb feel less like a single exotic vulnerability and more like a composition attack. HPACK creates asymmetry. Flow control preserves the cost. Multiplexing lets the pattern repeat across streams. The server’s default willingness to support many polite-looking HTTP/2 interactions becomes the resource the attacker spends.
This is also why “just block big headers” is not enough. The issue is the lived behavior of an HTTP/2 session under adversarial timing, not merely the size of one request field. Defenses that measure only the obvious payload miss the invisible mass of internal objects.
That sounds like a narrow implementation detail until you view it through an attacker’s eyes. If one logical category of header can be represented as many physical header objects without being counted the way administrators expect, then a server’s configured limits become less meaningful. The system looks guarded from the outside while leaving a side door open in its own accounting model.
The lesson is not that cookies are uniquely dangerous. The lesson is that protocol convenience tends to create ambiguity, and ambiguity tends to create cost. A limit that says “maximum decoded header size” may satisfy an administrator’s mental model while failing to constrain the number of objects, references, buffers, and per-stream structures the server actually creates.
This is where HTTP/2 Bomb becomes relevant well beyond the immediate patch list. The web platform has spent decades abstracting complexity away from application developers and users. Attackers, naturally, look for the places where those abstractions are charged to the server but not charged to the client.
Apache’s fix is available in mod_http2 2.0.41, where Cookie headers are counted against
That gap matters because Apache deployments often sit behind distribution packaging, enterprise support channels, container images, control panels, and hosting stacks. “Fixed upstream” is not the same thing as “fixed on the box serving traffic.” Administrators need to trace the actual module version and package path, not merely assume their platform has absorbed the change.
For nginx users who cannot upgrade immediately, the suggested temporary mitigation is to disable HTTP/2. For Apache users in the same bind, the recommended mitigation is to restrict protocols to HTTP/1.1. Lowering
That diversity is the warning. HTTP/2 is not just something exposed by a web server package on a Linux host. It is part of the connective tissue of modern infrastructure, from reverse proxies and load balancers to application gateways and internal service-to-service communication.
At the time of disclosure, the patch picture for IIS, Envoy, and Pingora was less settled than for nginx and Apache. Calif later reportedly said Envoy released patches on June 3, with validation still ongoing. For IIS and Pingora, administrators had to rely on mitigation guidance where no confirmed fix was available.
In a Windows-heavy environment, the IIS angle deserves special attention. Many IIS servers are not managed by the same teams that manage Linux edge proxies, and HTTP/2 may be enabled as part of a broader TLS and performance posture rather than treated as a high-risk feature. If those servers are public-facing, they now need the same urgent inventory treatment as any nginx or Apache fleet.
The trade-off is straightforward. Falling back to HTTP/1.1 may cost performance and connection efficiency, but it can remove the vulnerable HTTP/2 state machine from the exposed path. That is especially attractive for smaller organizations that cannot quickly validate exact server versions, module builds, or reverse-proxy behavior.
Larger environments should resist the temptation to treat “HTTP/2 disabled at the edge” as the whole answer. Internal gateways, Kubernetes ingress controllers, sidecars, API platforms, and service meshes may still speak HTTP/2 in places that are reachable by untrusted or semi-trusted clients. The attack surface is not always the public website; sometimes it is the shared internal platform that every team assumed someone else was hardening.
The better long-term answer is strict header-count enforcement, sane per-stream and per-connection memory limits, and fast patch adoption. But during the first days of a disclosure, the best answer is often the one that stops the bleeding while teams verify the details.
HTTP/2 Bomb is different, but it rhymes. Rapid Reset was about creating and canceling streams at abusive rates. HTTP/2 Bomb is about inflating and retaining memory through compression and flow control. Both attacks exploit the same basic reality: HTTP/2 gives a single connection much more expressive power than HTTP/1.1 ever did.
That expressive power is useful when clients are honest. It lets browsers and proxies make efficient use of the network. Under adversarial control, however, it means one client can ask the server to juggle many pieces of protocol state at once.
The industry has a habit of treating each HTTP/2 denial-of-service finding as a discrete implementation issue. That is technically useful but strategically incomplete. The pattern is that richer protocols need richer resource accounting, and defaults that were reasonable for performance testing may not survive hostile economics.
Defaults are policy. They encode vendor assumptions about the average deployment, the average client, and the average risk. When a default permits too many headers, too much retained state, or too generous a flow-control interaction, that choice propagates across hosting providers, appliances, containers, documentation examples, and cloud images.
This is particularly awkward for HTTP/2 because enabling it has often been sold as a performance checkbox. Turn it on, get better multiplexing, improve browser behavior, move on. Few administrators think of header object counts as part of the operational budget for that checkbox.
HTTP/2 Bomb forces a different framing. If a protocol feature changes how much memory a client can induce the server to allocate, then enabling that feature is also a capacity-planning and security decision. The default should not merely perform well; it should fail safely.
That does not mean every IIS deployment is equally exposed. Configuration, front-end proxies, load balancers, request limits, and whether HTTP/2 is reachable from untrusted clients all matter. But the Windows estate has its own version of the same problem: features enabled for compatibility and performance can become attack surfaces when protocol accounting falls short.
For many organizations, IIS may also sit behind an application delivery controller or cloud load balancer that terminates HTTP/2 before forwarding traffic. That can reduce exposure for the IIS server itself, but it shifts scrutiny to the component doing termination. If the front end is Envoy-based, appliance-based, or otherwise HTTP/2-capable, the risk may simply have moved one hop outward.
The practical WindowsForum.com takeaway is that this is not “a Linux web server bug.” It is a web infrastructure bug class touching Windows Server, reverse proxies, open-source servers, and modern edge components. Windows shops need to inventory HTTP/2 termination points, not just IIS roles.
AI did not invent HPACK. It did not invent flow control. It did not invent the old idea that compression and slow-reading clients can be abused. What matters is that these known ideas were combined effectively against modern defaults.
That is probably the more durable lesson about AI in security. The near-term impact may be less about machines discovering alien new bug classes and more about accelerating the recombination of existing techniques. A model that can help researchers explore protocol behavior can also help attackers search for edge cases in the giant state machines we have already deployed.
Defenders should respond by improving invariants, not by arguing about whether a finding is “really” AI-discovered. A server should have hard limits on the amount of memory any unauthenticated client can cause it to retain. That principle remains true whether the bug report came from a human, a fuzzing rig, or an AI-assisted workflow.
This sounds obvious after the disclosure. It was apparently less obvious in enough code paths to create a cross-implementation problem. That is how many denial-of-service issues work: they are not failures of cryptography or memory safety, but failures of budgeting.
The ideal defensive posture is layered. Header count limits should exist. Decoded header size limits should exist. Per-stream memory ceilings should exist. Per-connection stream limits, timeout behavior, and flow-control handling should be adversarially tested rather than tuned only for cooperative clients.
Administrators cannot rewrite HTTP/2 implementations this week. But they can pressure vendors and platform teams to expose meaningful knobs, set safer defaults, and document what each limit actually constrains. A setting that sounds protective but does not cover per-header bookkeeping is not a security boundary; it is a comfort blanket.
That makes HTTP/2 Bomb especially relevant for public-facing services with strict uptime expectations. E-commerce sites, APIs, login portals, update services, software repositories, and customer dashboards all depend on availability. A memory-exhaustion attack that can be driven from limited bandwidth is attractive because it lowers the attacker’s cost.
Organizations should also assume that bot operators will test variants. If the first public technique is mitigated by a simple header count, attackers may explore nearby implementation gaps: different header patterns, different flow-control timing, different stream concurrency, or different proxy chains. The right response is not panic, but it is urgency.
This is where patch management meets architecture. If your edge server can be drained of memory by unauthenticated protocol behavior, autoscaling may only multiply cost. If your reverse proxy dies before requests reach the application, application-layer rate limits may never fire. If your observability is focused on bandwidth and CPU, you may miss the memory curve until the process is already in trouble.
For nginx, the clean answer is to move to 1.29.8 or later and verify
The most dangerous response is to assume that existing decoded-size limits solve the issue. The researchers explicitly describe a condition where numerous small header fields, not one oversized blob, create the pressure. If a mitigation does not count fields, streams, and retained state, it may not mitigate the attack that was actually disclosed.
The second-most dangerous response is to assume the problem is only at the public edge. HTTP/2 is common in internal platforms, and internal denial-of-service can be just as painful when it takes down shared ingress, identity, observability, or API infrastructure.
The Web’s Fast Lane Just Became a Memory Sink
HTTP/2 was designed to make the web less wasteful. It multiplexes requests over fewer connections, compresses headers, and gives clients and servers better control over how data flows between them. For users, that usually means faster pages and fewer visible seams. For administrators, it means more state, more accounting, and more ways for an apparently small request to become large inside the server.HTTP/2 Bomb exploits that gap between what crosses the network and what the server must remember. The attacker is not blasting a site with huge payloads in the classic volumetric style. Instead, the client sends compact HTTP/2 header references and then uses flow-control behavior to keep the server from clearing the resulting state.
That distinction matters. Many organizations have spent years hardening against big requests, oversized headers, and floods that show up clearly in bandwidth graphs. HTTP/2 Bomb is more subtle: the traffic can be comparatively small, while the memory growth happens after decoding, bookkeeping, queuing, and response stalling.
The reported test numbers make the point bluntly. Envoy 1.37.2 reportedly reached 32 GB of memory consumption in about 10 seconds, Apache httpd 2.4.67 in about 18 seconds, nginx 1.29.7 in about 45 seconds, and Microsoft IIS on Windows Server 2025 reached 64 GB in about 45 seconds. Even allowing for lab conditions, those are not nuisance figures; they are outage figures.
HPACK Turns Compression Into a Multiplier
The first half of the attack leans on HPACK, the header compression system used by HTTP/2. HPACK exists for good reasons: HTTP headers are repetitive, especially across modern web applications with cookies, authentication fields, content negotiation, user-agent strings, and cache metadata. Compression saves bandwidth by allowing clients and servers to refer to known header fields compactly rather than sending the same strings again and again.But compression always has a dangerous edge. A tiny thing on the wire can become a much bigger thing after expansion. That principle is old, but HTTP/2 Bomb shows how it still matters when the “big thing” is not merely the decoded byte count but the collection of objects and metadata created as the server processes the request.
The researchers’ account says the attack sends small indexed header references that expand into larger server-side allocations. In other words, the server is induced to do the normal job HTTP/2 requires it to do: interpret compressed headers and construct an internal representation of the request. The payload does not need to look obviously abusive if the abuse is in the ratio between network input and internal state.
That is why this is not just a story about maximum header size. A server can enforce a limit on decoded bytes and still be vulnerable if it allows too many individual header fields, too much per-header bookkeeping, or too much intermediate state per stream. The accounting boundary is not the same as the cost boundary.
Flow Control Supplies the Fuse
The second half of HTTP/2 Bomb uses HTTP/2 flow control to keep memory tied up. Flow control is another feature that exists for sound engineering reasons. It lets receivers control how much data they are prepared to accept, preventing fast senders from overwhelming slow readers.In this attack, the mechanism becomes a holding pattern. The client can stall the response path so the server cannot promptly release allocations associated with streams, headers, and response handling. Instead of a burst of work that finishes and frees memory, the server is pushed into retaining state long enough for the attacker to stack more pressure on top.
That makes HTTP/2 Bomb feel less like a single exotic vulnerability and more like a composition attack. HPACK creates asymmetry. Flow control preserves the cost. Multiplexing lets the pattern repeat across streams. The server’s default willingness to support many polite-looking HTTP/2 interactions becomes the resource the attacker spends.
This is also why “just block big headers” is not enough. The issue is the lived behavior of an HTTP/2 session under adversarial timing, not merely the size of one request field. Defenses that measure only the obvious payload miss the invisible mass of internal objects.
The Cookie Detail Exposes a Bigger Accounting Failure
One of the more interesting parts of the disclosure is the role of Cookie headers. HTTP/2 permits Cookie headers to be split into separate fields, a design choice that can improve compression. In affected cases, the researchers say this behavior was not properly counted against request field limits.That sounds like a narrow implementation detail until you view it through an attacker’s eyes. If one logical category of header can be represented as many physical header objects without being counted the way administrators expect, then a server’s configured limits become less meaningful. The system looks guarded from the outside while leaving a side door open in its own accounting model.
The lesson is not that cookies are uniquely dangerous. The lesson is that protocol convenience tends to create ambiguity, and ambiguity tends to create cost. A limit that says “maximum decoded header size” may satisfy an administrator’s mental model while failing to constrain the number of objects, references, buffers, and per-stream structures the server actually creates.
This is where HTTP/2 Bomb becomes relevant well beyond the immediate patch list. The web platform has spent decades abstracting complexity away from application developers and users. Attackers, naturally, look for the places where those abstractions are charged to the server but not charged to the client.
nginx and Apache Move First, but the Patch Story Is Uneven
The fastest path to safety for many sites will be boring and familiar: update. nginx addressed the issue in version 1.29.8 by adding amax_headers directive, with a default of 1000. That is the right shape of fix because it recognizes that header count is a first-class resource boundary, not just a secondary detail behind total size.Apache’s fix is available in mod_http2 2.0.41, where Cookie headers are counted against
LimitRequestFields. The issue is tracked as CVE-2026-49975 in the Apache httpd ecosystem, and the fix was also reported as present in httpd trunk. At disclosure time, however, it had not yet landed as part of a 2.4.x release, which means real-world availability depends on how organizations consume Apache updates.That gap matters because Apache deployments often sit behind distribution packaging, enterprise support channels, container images, control panels, and hosting stacks. “Fixed upstream” is not the same thing as “fixed on the box serving traffic.” Administrators need to trace the actual module version and package path, not merely assume their platform has absorbed the change.
For nginx users who cannot upgrade immediately, the suggested temporary mitigation is to disable HTTP/2. For Apache users in the same bind, the recommended mitigation is to restrict protocols to HTTP/1.1. Lowering
LimitRequestFieldSize may reduce impact per stream, but it does not address the broader multiplication across streams and connections.IIS, Envoy, and Pingora Make This a Supply-Chain Problem
The inclusion of Microsoft IIS, Envoy, and Cloudflare Pingora is what turns this from an open-source web server story into an infrastructure story. These components sit in very different places. IIS anchors Windows Server web deployments. Envoy powers service meshes, ingress gateways, API edges, and cloud-native traffic management. Pingora is associated with Cloudflare’s high-performance proxying work.That diversity is the warning. HTTP/2 is not just something exposed by a web server package on a Linux host. It is part of the connective tissue of modern infrastructure, from reverse proxies and load balancers to application gateways and internal service-to-service communication.
At the time of disclosure, the patch picture for IIS, Envoy, and Pingora was less settled than for nginx and Apache. Calif later reportedly said Envoy released patches on June 3, with validation still ongoing. For IIS and Pingora, administrators had to rely on mitigation guidance where no confirmed fix was available.
In a Windows-heavy environment, the IIS angle deserves special attention. Many IIS servers are not managed by the same teams that manage Linux edge proxies, and HTTP/2 may be enabled as part of a broader TLS and performance posture rather than treated as a high-risk feature. If those servers are public-facing, they now need the same urgent inventory treatment as any nginx or Apache fleet.
Disabling HTTP/2 Is Crude, but Sometimes Crude Is Correct
Security teams dislike mitigations that sound like turning off progress. HTTP/2 is not a luxury in many stacks; it improves performance, reduces connection overhead, and is assumed by some traffic management designs. But when the immediate risk is memory exhaustion from unauthenticated remote clients, disabling HTTP/2 can be a rational short-term move.The trade-off is straightforward. Falling back to HTTP/1.1 may cost performance and connection efficiency, but it can remove the vulnerable HTTP/2 state machine from the exposed path. That is especially attractive for smaller organizations that cannot quickly validate exact server versions, module builds, or reverse-proxy behavior.
Larger environments should resist the temptation to treat “HTTP/2 disabled at the edge” as the whole answer. Internal gateways, Kubernetes ingress controllers, sidecars, API platforms, and service meshes may still speak HTTP/2 in places that are reachable by untrusted or semi-trusted clients. The attack surface is not always the public website; sometimes it is the shared internal platform that every team assumed someone else was hardening.
The better long-term answer is strict header-count enforcement, sane per-stream and per-connection memory limits, and fast patch adoption. But during the first days of a disclosure, the best answer is often the one that stops the bleeding while teams verify the details.
Rapid Reset Was the Warning Shot
This is not the first time HTTP/2 has been at the center of denial-of-service concern. The 2023 Rapid Reset vulnerability showed how HTTP/2 stream semantics could be abused at enormous scale. That episode pushed vendors and operators to revisit assumptions about multiplexing, cancellation, and request rates.HTTP/2 Bomb is different, but it rhymes. Rapid Reset was about creating and canceling streams at abusive rates. HTTP/2 Bomb is about inflating and retaining memory through compression and flow control. Both attacks exploit the same basic reality: HTTP/2 gives a single connection much more expressive power than HTTP/1.1 ever did.
That expressive power is useful when clients are honest. It lets browsers and proxies make efficient use of the network. Under adversarial control, however, it means one client can ask the server to juggle many pieces of protocol state at once.
The industry has a habit of treating each HTTP/2 denial-of-service finding as a discrete implementation issue. That is technically useful but strategically incomplete. The pattern is that richer protocols need richer resource accounting, and defaults that were reasonable for performance testing may not survive hostile economics.
Default Configurations Are the Real Blast Radius
The most important phrase in the disclosure is not “HPACK” or “flow control.” It is “default configurations.” Vulnerabilities that require exotic tuning or obscure modules have a narrower blast radius. Vulnerabilities that hit default HTTP/2 behavior in mainstream servers are much more dangerous because they meet administrators where they actually are.Defaults are policy. They encode vendor assumptions about the average deployment, the average client, and the average risk. When a default permits too many headers, too much retained state, or too generous a flow-control interaction, that choice propagates across hosting providers, appliances, containers, documentation examples, and cloud images.
This is particularly awkward for HTTP/2 because enabling it has often been sold as a performance checkbox. Turn it on, get better multiplexing, improve browser behavior, move on. Few administrators think of header object counts as part of the operational budget for that checkbox.
HTTP/2 Bomb forces a different framing. If a protocol feature changes how much memory a client can induce the server to allocate, then enabling that feature is also a capacity-planning and security decision. The default should not merely perform well; it should fail safely.
Windows Administrators Should Look Past the Linux-Centric Headlines
The early coverage naturally leans toward nginx and Apache because those projects have visible changelogs and clear version numbers. Windows administrators should not read that as permission to wait. IIS on Windows Server 2025 was named in the reported testing, with memory climbing to 64 GB in under a minute.That does not mean every IIS deployment is equally exposed. Configuration, front-end proxies, load balancers, request limits, and whether HTTP/2 is reachable from untrusted clients all matter. But the Windows estate has its own version of the same problem: features enabled for compatibility and performance can become attack surfaces when protocol accounting falls short.
For many organizations, IIS may also sit behind an application delivery controller or cloud load balancer that terminates HTTP/2 before forwarding traffic. That can reduce exposure for the IIS server itself, but it shifts scrutiny to the component doing termination. If the front end is Envoy-based, appliance-based, or otherwise HTTP/2-capable, the risk may simply have moved one hop outward.
The practical WindowsForum.com takeaway is that this is not “a Linux web server bug.” It is a web infrastructure bug class touching Windows Server, reverse proxies, open-source servers, and modern edge components. Windows shops need to inventory HTTP/2 termination points, not just IIS roles.
The AI Discovery Angle Is Interesting, but Not the Main Event
Some reporting emphasizes that Calif used OpenAI Codex in the discovery process. That is notable, and it will inevitably feed the larger debate about AI-assisted vulnerability research. But it should not distract from the operational reality: the exploit chain works because server implementations and configurations allowed a resource-accounting mismatch.AI did not invent HPACK. It did not invent flow control. It did not invent the old idea that compression and slow-reading clients can be abused. What matters is that these known ideas were combined effectively against modern defaults.
That is probably the more durable lesson about AI in security. The near-term impact may be less about machines discovering alien new bug classes and more about accelerating the recombination of existing techniques. A model that can help researchers explore protocol behavior can also help attackers search for edge cases in the giant state machines we have already deployed.
Defenders should respond by improving invariants, not by arguing about whether a finding is “really” AI-discovered. A server should have hard limits on the amount of memory any unauthenticated client can cause it to retain. That principle remains true whether the bug report came from a human, a fuzzing rig, or an AI-assisted workflow.
The Fix Is Header Count, but the Discipline Is Resource Accounting
nginx’smax_headers change and Apache’s Cookie-counting fix point toward the right engineering principle. Servers need to count the things that cost them money. If each header field creates an object, a table entry, a lookup, or a per-request allocation, then the number of header fields is a resource dimension.This sounds obvious after the disclosure. It was apparently less obvious in enough code paths to create a cross-implementation problem. That is how many denial-of-service issues work: they are not failures of cryptography or memory safety, but failures of budgeting.
The ideal defensive posture is layered. Header count limits should exist. Decoded header size limits should exist. Per-stream memory ceilings should exist. Per-connection stream limits, timeout behavior, and flow-control handling should be adversarially tested rather than tuned only for cooperative clients.
Administrators cannot rewrite HTTP/2 implementations this week. But they can pressure vendors and platform teams to expose meaningful knobs, set safer defaults, and document what each limit actually constrains. A setting that sounds protective but does not cover per-header bookkeeping is not a security boundary; it is a comfort blanket.
The Patch Window Is Now the Attack Window
Public disclosure changes the economics. Once proof-of-concept logic and performance numbers are in the open, opportunistic scanning and adaptation tend to follow. Attackers do not need to compromise a server to benefit from this class of bug; they only need to make it unavailable.That makes HTTP/2 Bomb especially relevant for public-facing services with strict uptime expectations. E-commerce sites, APIs, login portals, update services, software repositories, and customer dashboards all depend on availability. A memory-exhaustion attack that can be driven from limited bandwidth is attractive because it lowers the attacker’s cost.
Organizations should also assume that bot operators will test variants. If the first public technique is mitigated by a simple header count, attackers may explore nearby implementation gaps: different header patterns, different flow-control timing, different stream concurrency, or different proxy chains. The right response is not panic, but it is urgency.
This is where patch management meets architecture. If your edge server can be drained of memory by unauthenticated protocol behavior, autoscaling may only multiply cost. If your reverse proxy dies before requests reach the application, application-layer rate limits may never fire. If your observability is focused on bandwidth and CPU, you may miss the memory curve until the process is already in trouble.
The Server Room Version of the Story Is Shorter Than the Research Paper
Administrators do not need to memorize every frame-level detail to act. They need to identify where HTTP/2 is enabled, determine whether those components have fixes or header-count controls, and decide whether temporary disablement is safer than waiting.For nginx, the clean answer is to move to 1.29.8 or later and verify
max_headers behavior. For Apache, the clean answer is to use fixed mod_http2 code where available and confirm Cookie headers count against request field limits. For Envoy, IIS, and Pingora, the answer depends on vendor patch status and whether strict header-count enforcement can be placed in front of affected components.The most dangerous response is to assume that existing decoded-size limits solve the issue. The researchers explicitly describe a condition where numerous small header fields, not one oversized blob, create the pressure. If a mitigation does not count fields, streams, and retained state, it may not mitigate the attack that was actually disclosed.
The second-most dangerous response is to assume the problem is only at the public edge. HTTP/2 is common in internal platforms, and internal denial-of-service can be just as painful when it takes down shared ingress, identity, observability, or API infrastructure.
The Week HTTP/2 Stopped Looking Free
The immediate response should be tactical, but the strategic lesson is broader: HTTP/2 is not a free performance upgrade unless its resource model is enforced as aggressively as its feature set is advertised.- Organizations should inventory every public and internal point where HTTP/2 is terminated, including web servers, reverse proxies, load balancers, ingress controllers, and service-mesh gateways.
- nginx deployments should move to version 1.29.8 or later where possible and verify that header-count limits are active in the relevant contexts.
- Apache deployments should track fixed mod_http2 availability, especially where distribution packages or vendor images may lag upstream code.
- IIS, Envoy, and Pingora operators should watch vendor advisories closely and use HTTP/2 disablement or strict front-end header-count enforcement when patches are not confirmed.
- Existing decoded-header-size limits should not be treated as sufficient unless they also constrain the number of header fields and the memory retained per stream.
- Disabling HTTP/2 is a reasonable temporary mitigation for exposed services when patch status is uncertain and availability risk is high.
References
- Primary source: Linuxiac
Published: 2026-06-04T20:40:26.830340
New HTTP/2 Bomb DoS Attack Hits Nginx, Apache, IIS, Envoy, and Pingora
A new HTTP/2 Bomb DoS attack can exhaust memory on major web servers, causing denial-of-service in seconds.
linuxiac.com
- Related coverage: radware.com
- Related coverage: seguridadpy.info
Un ataque HTTP/2 Bomb tumba servidores web al agotar la memoria
Un nuevo ataque de denegación de servicio, bautizado como HTTP/2 Bomb, permite dejar inservibles servidores web en cuestión de segundos al disparar el consumo de RAM con peticiones HTTP/2. El probl…
seguridadpy.info
- Related coverage: blog.actipace.com
- Related coverage: ldecheau.fr
CVE-2026-49975 HTTP/2 Bomb : nginx, Apache, Envoy touchés — Correctifs et mitigations
CVE-2026-49975 alias HTTP/2 Bomb : une attaque DoS sans auth capable d'épuiser 32 Go de RAM en 10 secondes. Produits impactés, versions, correctifs nginx/Apache/Envoy et mitigations.
ldecheau.fr
- Related coverage: pub.hpc-technologies.co.jp
[CVE-2026-49975] リモートサービス拒否（DoS）の脆弱性 HTTP/2 Bomb について
HTTP/2 Bomb と呼ばれる脆弱性は、HTTP/2のヘッダー圧縮（HPACK）やCookieの処理仕様を悪用します。攻撃者は大量の「Cookieの断片（crumbs）」を送り、サーバー側に膨大なメモリを消費させます。
pub.hpc-technologies.co.jp
- Related coverage: getpagespeed.com
NGINX max_headers: Prevent Header-Flooding DoS | GetPageSpeed
Use the nginx max_headers directive to limit HTTP request headers and block header-flooding DoS attacks. Setup guide for RHEL-based systems.
www.getpagespeed.com
- Related coverage: uvcyber.com
