Published June 3, 2026. A newly disclosed denial-of-service technique called HTTP/2 Bomb deserves attention from anyone running a public website, reverse proxy, load balancer, API gateway, or business web app. The issue was published by Calif on June 2 and circulated through the oss-sec security mailing list the same day. The short version: a low-bandwidth attacker may be able to force vulnerable HTTP/2 servers to allocate and hold huge amounts of memory, making the site slow, unreachable, or unstable.
This is not a password-stealing bug and it is not a website-defacement bug. It is an availability problem. That still matters. If your booking page, customer portal, payment page, WordPress site, API, remote app, or hosted business system goes down during business hours, customers experience it as an outage whether or not data was stolen.
Quick Summary
- Name: HTTP/2 Bomb
- Type: remote denial of service through memory exhaustion
- Reported affected servers: nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora when HTTP/2 is enabled in vulnerable/default configurations
- Apache tracking: CVE-2026-49975 for the Apache/mod_http2 fix path
- Public disclosure date: June 2, 2026
- Main risk: a small amount of network traffic can expand into a large amount of server memory and be held long enough to cause an outage
- Immediate action: patch nginx or Apache where fixes are available, and use compensating controls or disable HTTP/2 where patches are not available
Calif reported that a home computer on a 100 Mbps connection could make a vulnerable server inaccessible within seconds. In their testing, Apache httpd and Envoy could be pushed to roughly 32 GB of held memory in about 20 seconds. Those numbers should not be treated as guaranteed results on every real-world server, because hosting layout, worker limits, front-end protection, CDN placement, memory limits, and HTTP/2 configuration all matter. But they are serious enough that this should not be ignored.
The Good And Bad Points
Good news
- nginx has a fix path. Calif says nginx added a
max_headersdirective and shipped it in version 1.29.8, with a default limit of 1000 headers. - Apache has a fix path. Calif and the oss-sec thread say Apache fixed the issue in
mod_http2 v2.0.41, with the fix also in httpd trunk at the time of disclosure. - This is not a data-theft vulnerability by itself. The reported impact is service availability, not direct credential theft or remote code execution.
- Front-end controls can help. A CDN, reverse proxy, load balancer, or web application firewall that enforces header-count limits and protects against stalled streams may reduce exposure.
Bad news
- HTTP/2 is common. Many websites enable HTTP/2 because it improves performance for normal users.
- The attack does not need huge bandwidth. The reported technique is dangerous because the attacker sends small compressed inputs that cause much larger server-side memory allocations.
- Some platforms may not have a patch yet. At the time of the Calif disclosure, Microsoft IIS, Envoy, and Cloudflare Pingora were listed as having no patch available, with disable-or-front-end-control guidance instead.
- Decoded header-size limits alone may not be enough. The research specifically calls out the difference between maximum decoded header size and maximum header count. Servers need both kinds of limits.
- Public details exist now. The disclosure says fix commits are public and that proof-of-concept material exists. That shortens the window for defenders to act.
How HTTP/2 Bomb Works, In Plain English
HTTP/2 was designed to make websites faster. It can handle multiple requests over one connection, and it compresses headers so browsers do not have to repeatedly send the same information in full. That compression system is called HPACK. For normal traffic, this is efficient. The problem appears when an attacker uses the efficiency against the server.
Calif describes the attack as a chain of two older ideas: a compression bomb and a Slowloris-style hold. The compression side uses HPACK indexed references so very little data on the wire can cause repeated server-side header allocations. The hold side abuses HTTP/2 flow-control behavior so the server cannot quickly finish the response and free the memory. In practical terms, the attacker is trying to make the server allocate memory and then keep that memory stuck in place.
The important part for business owners is this: the server may not immediately crash in a clean way. A worse outcome is that the machine gets pushed into heavy memory pressure or swap, where every legitimate visitor experiences slow pages, failed requests, checkout errors, broken API calls, or intermittent downtime.
We are intentionally not including attack commands or proof-of-concept instructions here. The defensive lesson is enough: HTTP/2 termination points need sane limits on header count, decoded header size, stalled stream lifetime, and per-worker memory.
Who May Be Exposed
You should care about this if you operate or depend on any of these:
- nginx serving websites directly or acting as a reverse proxy
- Apache httpd with HTTP/2 enabled through mod_http2
- Microsoft IIS with HTTP/2 enabled
- Envoy as an edge proxy, API gateway, or service-mesh component
- Cloudflare Pingora-based infrastructure or services terminating HTTP/2
- managed hosting platforms where you do not directly control the front-end web server
- business applications, APIs, portals, booking systems, or ecommerce sites where uptime matters
Many small businesses do not know whether they run nginx, Apache, IIS, Envoy, or a managed proxy in front of their website. That is normal. The practical check is to ask your hosting provider, IT provider, or developer: Where is HTTP/2 terminated, what software handles it, and does that layer enforce header-count and stalled-stream protections?
What Website Owners Should Check Today
For a small business, the goal is not to become an HTTP/2 protocol expert. The goal is to find out whether your public web stack is patched or protected.
- Confirm who hosts the site. Is it shared hosting, a VPS, a dedicated server, a cloud VM, a managed WordPress host, Microsoft IIS hosting, or a reverse-proxy/CDN setup?
- Confirm whether HTTP/2 is enabled. HTTP/2 may be enabled at the web server, CDN, reverse proxy, load balancer, or API gateway.
- Identify the HTTP/2 termination point. The vulnerable layer is the system that accepts HTTP/2 traffic from visitors, not necessarily the backend application itself.
- Check version and patch status. nginx users should look for 1.29.8 or later based on the Calif guidance. Apache users should look for the mod_http2 v2.0.41 fix path or later vendor backport guidance.
- Ask about IIS, Envoy, and Pingora mitigations. If no patch is available in your stack, the answer should be a compensating control, not silence.
- Review monitoring. Make sure someone would notice sudden memory pressure, swap usage, worker restarts, high latency, or HTTP 5xx errors.
Mitigation Steps
Patch first where a tested patch exists. If a patch is not available for your exact environment, use temporary controls until the vendor provides one.
For nginx
- Upgrade to nginx
1.29.8or later when available through your package source or vendor. - Confirm the new header-count protection is active. The nginx commit adds a
max_headersdirective with a default value of 1000. - If you cannot upgrade quickly and your site can tolerate it, consider temporarily disabling HTTP/2 until a tested fix is installed.
For Apache httpd
- Use a build or vendor package that includes the
mod_http2 v2.0.41fix or a later equivalent backport. - If you cannot patch, disabling HTTP/2 and serving HTTP/1.1 temporarily is the more conservative availability choice.
- Lowering request-field size may reduce some impact, but the disclosure says it is only a partial mitigation.
For Microsoft IIS, Envoy, and Pingora
- Check vendor advisories for your exact version and hosting platform.
- If no patch is available, disable HTTP/2 where feasible or place a protective front end in front of the server.
- The protective front end should enforce a hard cap on header count per request, including split cookie fields.
- It should also limit stalled stream lifetime so memory cannot be pinned indefinitely by tiny keepalive-style activity.
General server hardening
- Set practical per-worker memory limits so one abused worker dies and respawns before the whole server gets dragged into swap.
- Alert on sudden memory growth, swap activity, worker restarts, HTTP 5xx spikes, and abnormal HTTP/2 connection behavior.
- Keep a rollback plan before changing web-server protocol settings, especially if your site uses a CDN, proxy, or load balancer.
- For customer-facing business sites, test after changes: homepage, contact form, checkout, appointment booking, login, uploads, and API endpoints.
What This Means For Local Businesses
If your website is a simple brochure site, an HTTP/2 DoS may be annoying but not catastrophic. If your website takes payments, schedules appointments, collects leads, supports customers, hosts a portal, or connects to internal systems, downtime is a business event. The right response is not panic. The right response is a quick inventory and a clear owner.
For businesses around Port Saint Lucie, Jensen Beach, Fort Pierce, and Vero Beach, The IT Guys can help identify whether your website, hosting plan, reverse proxy, or firewall setup is exposed and whether your provider has patched or mitigated this class of HTTP/2 attack.
Related Reading
- Kali365 Microsoft 365 Phishing Kit Bypasses MFA Protection
- Quick Tech Tip: Stop Sharing Passwords by Text and Use a Shared Vault Instead
- Quick Tech Tip: Check SPF, DKIM, And DMARC Before Email Spoofing Hurts Your Business
FAQ
Is HTTP/2 Bomb a data breach?
No. Based on the public disclosure, this is a denial-of-service issue. It can affect availability, not directly expose passwords or customer records. Availability still matters because a business site or portal that is down cannot serve customers.
Should I disable HTTP/2 immediately?
Not automatically. HTTP/2 is useful and widely used. If your server or proxy has a tested fix, patching is better than disabling. If you are on an affected platform with no patch or no protective front end, temporarily disabling HTTP/2 may be reasonable until your provider gives clear mitigation guidance.
Does using Cloudflare or another CDN protect me?
It may help, but do not assume. A CDN or reverse proxy changes where HTTP/2 is terminated. Ask whether that front-end layer enforces header-count limits and stalled-stream protections. Also confirm whether your origin server is reachable directly, because attackers may bypass the CDN if the origin IP is exposed.
Is WordPress affected?
WordPress itself is not the main issue here. The vulnerable layer is the web server or proxy handling HTTP/2 before WordPress receives a request. A WordPress site can still be affected if it sits behind vulnerable nginx, Apache, IIS, Envoy, or another exposed HTTP/2 termination point.
What should I ask my hosting provider?
Ask: “Do you terminate HTTP/2 for my site, and have you patched or mitigated the June 2026 HTTP/2 Bomb denial-of-service issue? Do you enforce maximum header count, decoded header size, stalled-stream lifetime, and per-worker memory limits?” That question is specific enough to get a useful answer.