Our friend Carlos Ros has woken us up warned us via the Sinologic Telegram channel about a vulnerability that has been flying under the radar. It’s called HTTP/2 Bomb, it has been assigned CVE-2026-49975, and the surprising part is that anyone can take down a web server in seconds, even from a home PC, as we’ll see below.
What it is and why it’s so effective
There’s no brand-new, brilliant flaw here, but something more cunning: chaining together old HTTP/2 problems that have been known for years until they turn into a demolishing attack.
The first part is a compression bomb: HTTP/2 compresses headers (the technique is called HPACK), and an attacker can send a tiny message that the server decompresses until it becomes a giant structure that devours memory. The second part is a Slowloris-style retention: the attacker advertises a zero-byte flow-control window, the server sits there waiting to respond, and that reserved memory is never freed. Put the two together and you have a server that runs out of memory at full speed while attending to nobody. That’s a denial of service (DoS) — the textbook kind, but on steroids.
The elegant (and dangerous) detail is that the amplification doesn’t come from a huge header, but from the internal accounting the server reserves around almost-empty headers. That’s why the classic “maximum decode size” limits don’t always stop it: there’s barely anything to decode.
Who it affects (and why you should care today)
It’s estimated this could affect more than 880,000 sites running HTTP/2 with default configurations on servers as common as NGINX, Apache HTTP Server, Microsoft IIS, Envoy or Cloudflare Pingora. If you have anything published on the internet, there’s a good chance you’re using one of these under the hood.
How to know if you’re vulnerable
Ask yourself three quick questions: Do you have services exposed to the internet that speak HTTP/2? Are they running default configurations? Is your software out of date relative to the versions that already fix this?
If the answer to all three is “yes” or “I don’t know,” assume you’re in the at-risk group until proven otherwise. If you’ve recently been seeing sudden memory spikes and abrupt service instability consistent with memory exhaustion, there’s a good chance someone is already testing it against you. There are no published indicators of compromise (IOCs), so monitoring the RAM usage of your HTTP/2 services is, for now, your best radar.
How to check on Linux whether your server is vulnerable
There’s no magic command here that tells you “yes” or “no,” because CVE-2026-49975 isn’t a single-packet flaw, but a chain that depends on which web server you use and its version. What you can do in five minutes is gather the three things that matter: which server you have, which version is running and whether HTTP/2 is enabled. With that you’ll already know whether you need to take action.
1. Identify which web server and version you have. Run whichever applies:
# NGINX nginx -v # Apache (depending on distribution) apache2 -v # Debian / Ubuntu httpd -v # RHEL / CentOS / Rocky / Alma / SUSE
Note the exact number. The compression-bomb (HPACK) fix landed in Apache in 2.4.64, and the full CVE-2026-49975 chain was closed in late May, so any Apache below that line is suspect. NGINX published its fix in April: if you’ve gone months without updating, assume you’re behind.
2. Check whether you’re actually serving over HTTP/2. If you don’t have HTTP/2 active, this specific attack doesn’t apply to you. From the server itself or from outside:
# Protocol negotiated against your site
curl -I --http2 -s https://your-domain.com -o /dev/null -w "%{http_version}\n"
# http2 directives in the NGINX configuration
grep -R "http2" /etc/nginx/ 2>/dev/null
# http2 module in Apache
apachectl -M 2>/dev/null | grep http2 # Debian/Ubuntu: a2query -m http2If curl returns 2, you’re talking HTTP/2 to the world. If it returns 1.1 and no http2 directive appears, this vector doesn’t affect you today (although it’s worth patching anyway for good hygiene).
3. Compare your version against your distribution’s patched one. Almost nobody compiles by hand: you use your distro’s packages, and there what matters isn’t just the version number “shown above,” but whether the maintainer has backported the patch. Check the package changelog:
# Debian / Ubuntu apt-cache policy nginx # or apache2 apt changelog nginx 2>/dev/null | grep -i -m5 "CVE-2026-49975\|CVE-2025-53020\|http2" # RHEL / Rocky / Alma rpm -q nginx httpd rpm -q --changelog httpd 2>/dev/null | grep -i -m5 "CVE-2026-49975\|http2"
If the changelog shows the CVE as fixed, you’re covered even if the version number throws you off. If nothing appears and your version is older than the ones listed above, it’s time to update. The practical rule: when in doubt, update and restart the service, which is quick and doesn’t leave you exposed while waiting to be “sure” you already were.
Even so, at Sinologic we’ve built a tool to make checking easier: https://www.sinologic.net/proyectos/HTTP2BombCheck/
What to do: patch or mitigate
The state of the patches, as of the advisory date, is uneven: NGINX fixed it in April. Apache released corrections in late May (it’s the one that assigned CVE-2026-49975). Microsoft IIS, Envoy and Cloudflare Pingora still didn’t have a patch available at that moment, so there you need to be especially attentive to the vendor’s updates.
The sensible action plan is the usual one, no drama: locate your exposed HTTP/2 services, check the version, apply the vendor’s patch as soon as it’s available (in NGINX and Apache there’s no excuse already), and meanwhile monitor memory to detect abuse. If you run something critical facing the internet, this falls into the “today” bucket, not the “I’ll look at it later” one.
It’s hard not to notice the pattern: this exploit was found using OpenAI’s Codex, just as Copy Fail uncovered an AI not long ago. The AI-powered offensive is no longer the future, it’s the present, and it drastically shortens the time between “this was theoretically possible” and “this is happening in production.” All the more reason not to leave the patches for tomorrow.
Are you seeing it on your servers? Have you noticed odd memory spikes lately? Tell us in the comments or in the Sinologic Telegram channel, which is exactly what these articles are for. And thanks again to Carlos Ros for the tip-off.
Further information: SOCPrime
Join the Sinologic community
Create your free account and join the conversations about VoIP, Asterisk, Kamailio and IP telephony.
Every opinion counts
Your comment could solve someone else's question.