On 6/2/26 19:36, Alan Coopersmith wrote: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says: The fix commits above are public and disclose the vectors directly; any capable AI model can turn those diffs into a working exploit, which is exactly how we found that Microsoft IIS, Envoy, and Pingora are also vulnerable. We've notified their maintainers. Given how short the commit-to-exploit path now is, we're releasing this writeup to provide users with the mitigations below. Additional patches have since been released by envoy & h2o. Posts on twitter by @califio continue to discuss whether other packages are vulnerable or not.

https://github.com/envoyproxy/envoy/security/advisories/GHSA-22m2-hvr2-xqc8 says: HTTP/2 memory exhaustion via cookie header size bypass and HPACK amplification

phlax published GHSA-22m2-hvr2-xqc8 Jun 3, 2026

Package: github.com/envoyproxy/envoy Affected versions: <1.39 Patched versions: 1.35.11 1.36.7 1.37.3 1.38.1

Summary -------

A vulnerability in Envoy's HTTP/2 downstream request processing allows an unauthenticated remote client to trigger excessive memory consumption, potentially resulting in OOM termination of the Envoy process and denial of service.

The issue arises from the combination of two behaviors:

1. Cookie header bytes are not fully accounted for during request header size validation in Envoy. 2. HPACK header block limits in oghttp2/quiche are enforced on encoded bytes without a corresponding limit on total decoded header size.

Together, these behaviors allow a malicious client to cause large decoded header allocations while bypassing the intended request header size protections.

Affected Components -------------------

Envoy HTTP/2 downstream request processing Cookie header size accounting during header validation HPACK header block size enforcement in oghttp2/quiche

Details -------

During HTTP/2 request processing, cookie header fragments are buffered separately and merged only after request header size validation has completed. Because these buffered cookie bytes are not fully included in the effective header size check, oversized cookie data can bypass maxrequestheaderskb enforcement.

Separately, oghttp2/quiche enforces header block limits on encoded HPACK bytes rather than on the fully decoded header size. A malicious client can exploit this asymmetry by using dynamic table references to keep the encoded representation relatively small while causing the decoded cookie header value to become much larger in memory.

When these behaviors are combined, a client can force Envoy to retain large per-stream allocations. Under sustained concurrency, this can rapidly increase process memory usage and lead to OOM termination.

Flow-control stalling can further increase the effectiveness of the attack by prolonging stream lifetime and delaying reclamation of per-stream memory.

Impact ------

An unauthenticated remote attacker can cause denial of service by exhausting memory in the Envoy process.

In testing against envoyproxy/envoy-google-vrp-dev:latest (v1.36.0-dev), the Envoy edge process was OOM-killed under a 3 GiB memory limit within a few seconds using a limited number of HTTP/2 connections and streams.

Additional testing showed that the attack remained effective with significantly fewer connections and streams than initially required, indicating that exploitation can be efficient even under tighter attacker-side resource constraints.

A secondary operational effect observed during testing was that oversized decoded cookies forwarded upstream could exceed the upstream service's own header limits, potentially causing upstream HTTP/2 connection resets and transient request failures.

Attack Vector -------------

A malicious downstream HTTP/2 client sends specially crafted cookie headers that combine:

incomplete cookie-size accounting during request validation; and HPACK decoded-size amplification via small encoded representations.

The impact can be amplified further by using HTTP/2 flow-control behavior to extend stream lifetime and delay memory reclamation.

Patches -------

A complete fix requires addressing both contributing issues:

include buffered cookie bytes in request header size accounting before request acceptance; and enforce limits on decoded header size, not only on encoded HPACK block size.

Fixing only one side may reduce exploitability but does not fully address the underlying issue.

Workarounds -----------

No complete workaround is known short of applying a fix.

Possible temporary mitigations include:

disabling downstream HTTP/2 where operationally feasible; enforcing stricter request header and cookie limits before traffic reaches Envoy; and monitoring Envoy memory usage for abnormal growth under HTTP/2 traffic.

Detection ---------

Potential indicators of exploitation include:

rapid or sustained abnormal memory growth in the Envoy process; OOM termination, including exit status 137 in containerized environments; and unusual HTTP/2 traffic patterns involving repeated indexed cookie references.

Credits ------- Credit: Ryoga Yamashita.

Severity: High, 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID: CVE-2026-47774 https://github.com/h2o/h2o/security/advisories/GHSA-qcrr-wrhc-pgq9 says: HTTP/2 state amplification

kazuho published GHSA-qcrr-wrhc-pgq9 Jun 3, 2026

Package: h2o Affected versions: commits up to 8dc37cb Patched versions: 9265bdd and above

Impact ------

Recently, an attack against HTTP/2 servers was published that combines state amplification caused by HPACK decompression with Slowloris-style stream stalling: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb.

H2O reduces HPACK state amplification by representing HTTP header names and values internally as references where possible. However, in light of this attack, additional limits may be needed, depending on the configuration, to bound decoded header state and prevent amplified state from being retained by stalled HTTP/2 streams.

Patches ------- Mitigations were added in #3597 and landed on master as 9265bdd: https://github.com/h2o/h2o/pull/3597 https://github.com/h2o/h2o/commit/9265bdd9a996ed992681055e3996baf3e09d2063

References ---------- https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

Severity: High, 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID: No known CVE -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Impact Pingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users.

This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.

Patches We strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation.

Workarounds Do not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method.

References See CVE-2026-2836 and the Cloudflare blog post for more details.

Credits Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

Impact Pingora versions prior to 0.8.0 improperly allowed HTTP/1.0 request bodies to be close-delimited and incorrectly handled multiple Transfer-Encoding values. This allows an attacker to desync Pingora's request framing from backend servers and smuggle requests to the backend.

This vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as its ingress proxy layers rejected ambiguous framing such as invalid Content-Length values and internally forwarded non-ambiguous message length framing headers.

Patches Pingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited (commits 7f7166d62fa916b9f11b2eb8f9e3c4999e8b9023, 40c3c1e9a43a86b38adeab8da7a2f6eba68b83ad, and 87e2e2fb37edf9be33e3b1d04726293ae6bf2052).

Workarounds As a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact “chunked” string match.

References See CVE-2026-2835 and the Cloudflare blog post for more details.

Credits Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

Impact Pingora versions prior to 0.8.0 would immediately forward bytes following a request with an Upgrade header to the backend, without waiting for a 101 Switching Protocols response. This allows an attacker to smuggle requests to the backend and bypass proxy-level security controls.

This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.

Patches Pingora users should upgrade to Pingora v0.8.0 or higher, which fixes this issue by only switching connection modes after receiving a 101 Switching Protocols response from the backend (hash 824bdeefc61e121cc8861de1b35e8e8f39026ecd). Without a 101 response, subsequent bytes continue to be parsed as HTTP requests.

Workarounds As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.

References See CVE-2026-2833 and the Cloudflare blog post for more details.

Credits Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.