14 years ago, I helped break HTTP header compression, then was asked to review the fix, which became part of HTTP/2. Life has come full circle: today we're releasing an attack I missed.
I partially agree with OP's arguments in comments with @Yan Avlasov about OP's opinions on other approaches to responsible disclosure in regards to publically available exploits in the age of AI-assisted vulnerability discovery. However, I find it counter to their own point that they disclosed this to nginx in April, Apache on May 27th and the other three vendors mentioned (Microsoft, Cloudflare and Envoy) seemingly got no advance notice at all, per the blog post. This seems like favouritism towards nginx at a glance, although I'm sure it has a more complex background that I'd love to hear from OP. Disclosure discussion aside, great find and good blog post.
We originally reported the bug to nginx and then more or less forgot about it. We've published quite a bit of research recently, so this issue simply fell off our radar.
We rediscovered it while cleaning up our backlog. During that process, we realized that the same technique might affect other servers as well. We started by testing Apache httpd, since it's the second most widely deployed web server after nginx. From there, we expanded to other servers and notified the affected vendors.
Much of the cross-vendor testing and analysis was automated with AI assistance.
Thanks for fixing the issue so quickly — this is a win for Envoy users. We believe the traditional disclosure model is increasingly outdated in the era of AI-assisted vulnerability discovery, and we explain our rationale for disclosure in the post.
And irresponsible disclosure is a huge loss for Envoy ecosystem and possibly wider industry. Did you disclose this to all H/2 implementations? This should have really been coordinated via VINCE to make sure all H/2 vendors are aware. And if the 90 day disclosure policy is outdated, what is the new policy that you believe is appropriate? You have filed advisory on May 27th and published blog on June 2nd. Is your new embargo policy 4 days?
We disclose details once we believe that anyone monitoring public commits could reproduce the issue using AI-assisted analysis. In our view, withholding information after the relevant commits are public does more harm than good. We recognize that reasonable people may disagree, and we respect that perspective.
Checked if https://ramaproxy.org/ is vulnarable to it, but no, seems we are fine :) On all parts of it. Thank you for the published research btw!
Hi, is there any info on haproxy?
Haproxy answer:
https://www.haproxy.com/blog/haproxy-cve-2026-49975-http2-bomb
I partially agree with OP's arguments in comments with @Yan Avlasov about OP's opinions on other approaches to responsible disclosure in regards to publically available exploits in the age of AI-assisted vulnerability discovery. However, I find it counter to their own point that they disclosed this to nginx in April, Apache on May 27th and the other three vendors mentioned (Microsoft, Cloudflare and Envoy) seemingly got no advance notice at all, per the blog post. This seems like favouritism towards nginx at a glance, although I'm sure it has a more complex background that I'd love to hear from OP. Disclosure discussion aside, great find and good blog post.
Thanks for asking.
We originally reported the bug to nginx and then more or less forgot about it. We've published quite a bit of research recently, so this issue simply fell off our radar.
We rediscovered it while cleaning up our backlog. During that process, we realized that the same technique might affect other servers as well. We started by testing Apache httpd, since it's the second most widely deployed web server after nginx. From there, we expanded to other servers and notified the affected vendors.
Much of the cross-vendor testing and analysis was automated with AI assistance.
Does CDN service provider like Cloudflare / AKAMAI stop the HTTP/2 bomb as they are terminated at edge point?
We can't tell. We can't test these systems.
OP ignored responsible disclosure policy and released a 0-day for Envoy ecosystem. Envoy community was in process of releasing a patch for this problem: https://github.com/envoyproxy/envoy/security/advisories/GHSA-22m2-hvr2-xqc8
Thanks for fixing the issue so quickly — this is a win for Envoy users. We believe the traditional disclosure model is increasingly outdated in the era of AI-assisted vulnerability discovery, and we explain our rationale for disclosure in the post.
And irresponsible disclosure is a huge loss for Envoy ecosystem and possibly wider industry. Did you disclose this to all H/2 implementations? This should have really been coordinated via VINCE to make sure all H/2 vendors are aware. And if the 90 day disclosure policy is outdated, what is the new policy that you believe is appropriate? You have filed advisory on May 27th and published blog on June 2nd. Is your new embargo policy 4 days?
We disclose details once we believe that anyone monitoring public commits could reproduce the issue using AI-assisted analysis. In our view, withholding information after the relevant commits are public does more harm than good. We recognize that reasonable people may disagree, and we respect that perspective.
7-day and 0-day timelines are only appropriate for _known active exploitation_ and _known bad vendors_
responsible disclosure?