An OpenAI fuzzing bot chained two boring HTTP/2 behaviors together and produced a remote denial-of-service that works against NGINX, Apache, IIS, Envoy, and Cloudflare Pingora in their default configurations. Five vendors, one bug class, one shared assumption. The humans who write web servers for a living missed it for years. The fuzzer needed a weekend. That is the cybersecurity story of the week, and it is not really about HTTP/2.

While the HTTP/2 Bomb headline was landing, Bruce Schneier reposted a column from 2010 making the same point he has been making since 2000: cryptography does not solve denial-of-service, defacement, credential theft, or worms. Sixteen years later, the entire serving layer of the public internet just got handed a free DoS, and the response from most ops teams will be to update a TLS library nobody asked them to touch.

The bug everyone shipped at the same time

The technical mechanics are not exotic. HTTP/2 multiplexes many logical streams over one TCP connection, and the protocol has been a parade of resource-exhaustion footguns since it shipped. Rapid Reset in 2023. CONTINUATION Flood in 2024. MadeYouReset earlier this year. HTTP/2 Bomb is the next entry in that catalogue, and the common thread is that every server vendor implemented the spec, every vendor implemented it the same way, and nobody asked what an adversarial client could do with a default frame budget.

Calif’s writeup, helpfully amplified by The Hacker News, notes the chaining was discovered by OpenAI Codex. That detail is the actual news. A machine read the RFC, read the implementations, generated test cases that humans had not written, and found a fault path that affects basically every public-facing HTTP server you can name. If your AppSec team is still pricing out a fuzzing initiative for Q4, you are now behind a Discord bot.

Availability is the cybersecurity discipline nobody wants to own

Schneier’s old column reads like a postmortem written before the incident. Cryptography secures the bits in transit. It does not stop someone from telling your front door to fall down. We have spent fifteen years rebuilding the entire web on TLS 1.3, modern cipher suites, certificate transparency, and pinning. None of that protects an NGINX worker from a malformed stream.

The ugly truth is that DoS rarely gets a budget line. It is hard to demo to the board. It does not produce a breach disclosure. The vendors selling EDR, SIEM, and identity tooling have no story for it, so it falls between the network team, the application team, and the CDN, and most often lands with whoever is on call when the dashboards go red.

This is also why brute-force and credential-stuffing controls keep getting bolted on after an incident rather than designed in. They live in the same “availability and abuse” bucket as DoS. They get the same attention. Which is to say, not much, until something embarrassing happens.

What to actually do this week

Patches will land. NGINX, Apache, and Envoy maintainers move fast on this class of bug, and Cloudflare Pingora updates ship without you doing anything. IIS will follow on the next Patch Tuesday. Patching is the floor, not the ceiling. The work that actually reduces blast radius is configuration and posture, and it is not optional.

• Inventory the HTTP/2 surface. Every public listener, every internal mTLS gateway, every CDN origin shield. If you cannot list them in an afternoon, you cannot defend them.
• Constrain HTTP/2 defaults. Cap max concurrent streams per connection. Cap max headers and header list size. Cap CONTINUATION frame counts. Reject clients that open and close streams faster than a real browser does. The values are server-specific; the discipline is universal.
• Move rate-limiting to the edge. Per-connection, per-IP, and per-ASN limits should be enforced before traffic reaches your origin. Pair this with brute-force counters on auth endpoints, because the same connection-floods that knock over an idle server also mask credential-stuffing waves.
• Put a real firewall in front of management planes. No reason your origin servers should accept HTTP/2 from arbitrary internet IPs if they live behind a CDN. Lock the origin to known fronting ranges. This is security hardening 101 that most teams skip because the CDN “is” the firewall.
• Wire DoS into incident response. Define the threshold that triggers a page, the runbook for shedding load, and the comms plan. Most orgs only rehearse data-breach IR. Rehearse availability incidents too, because threat detection without threat protection is just a really expensive smoke alarm.
• Treat AI-driven fuzzing as table stakes for your own code. If Codex can chain RFC behaviors against the world’s most-reviewed web servers, it can chain them against your homegrown API gateway. Defense in depth now includes assuming somebody else’s bot is reading your source.

Notice what is not on that list: a new vendor purchase. Every item is configuration, telemetry, or process. The HTTP/2 Bomb response does not need a procurement cycle. It needs an afternoon and a maintenance window.

When the fuzzer wears somebody else’s badge

The supply-chain crowd had its own week. Microsoft’s Red Hat npm Miasma writeup details a worm that compromised ninety versions of @redhat-cloud-services packages, stole CI/CD credentials, and republished trusted modules to spread itself. Google rolled out Android fake-call detection. The White House published a pared-back AI executive order. The threat landscape kept moving while everyone read the same five blog posts.

What ties Miasma to HTTP/2 Bomb is the speed differential. An attacker, or in this case an automated research tool, can find and weaponize a class of defect faster than a coordinated patch cycle can close it. The defender response cannot be “wait for the vendor advisory and apply it.” That posture loses against worms, it loses against AI-assisted fuzzing, and it has always lost against motivated abuse traffic.

The teams that will absorb the next HTTP/2-shaped problem without an outage are the ones who already wrote down their default frame limits, already segmented their origins behind a known fronting set, and already practiced a DoS scenario in a tabletop. The teams that get paged at 2am are the ones whose entire availability strategy is “the CDN handles it.”

Schneier’s column is sixteen years old. The lesson is older than that. Crypto secures what you send. It does not secure whether you can send anything at all. If the AI tools have started filling in the gaps that human researchers missed, the floor on web-server abuse just moved up. Plan accordingly.

Sources

• New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare
• The Intersection of Encryption and AI
• Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign
• White House unveils pared-back AI executive order