If you have been paying any attention, you have probably seen several serious vulnerabilities affecting HTTP/2 implementations over the years. One of the most famous involved a decompression bomb. Some servers would happily decompress client payloads without checking how large the result would become. If you crafted a compressed payload, for example in gzip format, that expanded to a petabyte, the server would actually try to allocate a petabyte of memory and promptly crash.
Those kinds of naive bugs were fixed long ago. But HTTP/2 is a complex protocol, and even when an implementation follows the specification correctly and does not suffer from memory corruption, use-after-free bugs (the usual vulnerabilities people associate with CVEs), there are still problems.
At the beginning of June 2026, a new vulnerability, CVE-2026-49975, was disclosed with a CISA ADP score of 7.5. That is serious. Any user on the Internet could connect to an unprotected HTTP server and force it to allocate excessive amounts of memory just to manage request handlers. The figure below shows how the attack worked.
The real problem is that a huge amount of Internet infrastructure depends on HTTP/2, and in many environments disabling it is not an option. Apples in-app messaging depends on HTTP/2. gRPC relies on HTTP/2. I have not been able to confirm or rule out whether gRPC itself is vulnerable to this attack (there are multiple implementations), but in practice most deployments do not expose gRPC directly to the Internet. They place it behind reverse proxies such as Nginx or Apache. Those servers were vulnerable, which meant that during the zero-day window, anyone who knew about the attack could take down gRPC services simply by overwhelming the front-end servers with malicious traffic. And we are not talking about large payloads here - this was not a classic DoS attack throwing terabytes of data on a server.
In some deployments, firewall rules could mitigate the issue by restricting access so that only trusted services could connect. In many real-world scenarios, though, end-user applications communicate with servers over gRPC. In those cases, there is no practical protection. If clients need to reach the service, attackers can reach it too.
I bring this up not because I hate HTTP/2. I actually like it. HTTP/2 solved many problems that HTTP/1 never addressed. What it illustrates is the cost of complexity when that complexity is unnecessary.
This is a problem we are going to encounter more and more as AI starts doing the hacking instead of hackers. The Internet is going to become much more hostile than it is today. If we continue stacking increasingly complicated components on top of each other, we are building an unstable and dangerous ecosystem where failures become harder to predict and harder to contain.
Take gRPC as an example. Remote procedure calls do not require HTTP/2. They require a transport channel and a way to encode and decode payloads. That can be done perfectly well over TCP with TLS and a simple protocol on top. That is exactly the approach I used when I designed DarkSpeak eight years ago (an instant messenger intended to operate securely over darknet environments) - to avoid exactly these kinds of problems.
I think we need to become much more disciplined when designing software. Complexity should be removed wherever possible. Systems should be made as simple as they can be. Every additional layer and every additional dependency creates new ways for things to fail. As those failures become increasingly exploitable, simplicity stops being an aesthetic preference and becomes a core security requirement.