A denial-of-service vulnerability was found in Envoy's HTTP/2 implementation. The attack chains two techniques: an HPACK compression bomb that exploits header compression to amplify a single byte on the wire into a full header allocation on the server (repeated thousands of times per request), and a Slowloris-style hold using a zero-byte HTTP/2 flow-control window that prevents the server from ever freeing the allocated memory.

A remote attacker can exploit this in Envoy's default HTTP/2 configuration to consume and hold large amounts of server memory (up to 32GB in approximately 20 seconds), rendering the server inaccessible.

This vulnerability exists in each server's default HTTP/2 configuration and requires no authentication to exploit.

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

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.37.0 until 1.37.5 and 1.38.3, the HTTP OAuth2 filter (envoy.filters.http.oauth2) can leave an in-flight async token exchange attached to a downstream stream that has already been torn down. A late AsyncClient completion can still invoke OAuth2Filter methods that use StreamDecoderFilterCallbacks after that object’s lifetime has ended, causing undefined behavior, worker crashes (availability loss), and use-after-free / invalid-vptr failures under AddressSanitizer. This is a memory-safety / lifetime issue in the data plane, not a trivial config bug. Remote code execution is not claimed here; the primary demonstrated impact is DoS via crash and UB; any further impact would be deployment- and allocator-dependent. This vulnerability is fixed in 1.37.5 and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.35.11, 1.36.7, 1.37.3, and 1.38.1, in cases where UDP DNS filter is configured with local resolution containing a name with the length of 255 octets or remote resolution for a name of 255 octets long can complete successfully, a query with such name will result in abnormal process termination. The abnormal process termination is triggered by an invalid runtime precondition that the query name is strictly less than 255 octets, contradicting DNS specification rfc1035#section-2.3.4 that the name can be 255 or less octets. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, a vulnerability exists in Envoy's TCP StatsD sink (TcpStatsdSink), where the thread-local flusher buffer can be overflowed by exceptionally long statistic names (e.g., >16KiB). During formatting, TcpStatsdSink reserves a single contiguous memory slice of 16KiB (FLUSHSLICESIZEBYTES). If formatting a single metric exceeds the remaining capacity, the flusher initiates a buffer rotation but incorrectly continues to allocate another fixed 16KiB slice. If an attacker can trigger a statistic name longer than 16KiB—for example, by sending an HTTP or gRPC request with an extremely long request path (:path) that is recorded by the grpcstats filter configured with statsforallmethods: true—the flusher will attempt to copy the metric name using memcpy operations beyond the allocated heap buffer boundaries. This leads to a heap write overflow, which can cause immediate denial-of-service (process crash) or potential remote code execution (RCE). This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.36.0 until 1.36.9, 1.37.5, and 1.38.3, a Use-After-Free (UAF) vulnerability leading to a sudden segmentation fault exists in Envoy's extauthz HTTP filter when processing per-route authorization overrides concurrently with rapid downstream client disconnects. During standard request lifecycles, Envoy instantiates the extauthz filter with a foundational authorization client object (client). If a matched route dictates a dynamic per-route HTTP or gRPC authorization service override, the filter generates a localized client. In the vulnerable implementation, this transient client aggressively overwrote the default client unique pointer by executing client = std::move(perrouteclient). When a client rapidly establishes and subsequently tears down a stream (such as rapidly refreshing a protected WebSocket endpoint), the downstream triggers the ConnectionManagerImpl::doDeferredStreamDestroy() -> ActiveStream::onResetStream() lifecycle. Envoy immediately sequences Filter::onDestroy() in an attempt to securely abort dispatched asynchronous authorization check transactions via client->cancel(). By destructing the default client abruptly during initiateCall, a memory lifecycle misalignment occurs within the async client manager. The stream teardown fails to reliably track and cancel the dynamically bound asynchronous authorization tasks, orchestrating a sequence where a late asynchronous callback from the network evaluates against a heavily destroyed ActiveStream validation span, generating a UAF process crash. This vulnerability is fixed in 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.26.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the envoy.filters.http.grpcstats filter crashes (null pointer dereference / segfault) when a Connect protocol request (Content-Type: application/connect+proto or application/connect+json) hits a directresponse route. A single unauthenticated HTTP request crashes the Envoy process. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, Envoy crashes if an extproc server sends a single gRPC message containing multiple, specially crafted ProcessingResponse messages. This can occur when the first response in the batch causes the gRPC stream object to be destroyed, leading to a use-after-free error when Envoy attempts to process subsequent responses in the same gRPC message. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.18.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the router filter contains a null pointer dereference vulnerability when handling HTTP 303 (See Other) internal redirects for body-less non-GET/HEAD requests. When a POST, PUT, DELETE, or PATCH request without a body is sent to a route configured with internal redirect policy that includes 303 in redirectresponsecodes, and the upstream responds with HTTP 303, the redirect handling code attempts to drain a request body buffer that was never allocated. This results in a segmentation fault that crashes the entire Envoy process. When route configured with internalredirectpolicy including 303 in redirectresponsecodes and upstream must return HTTP 303 response, an unauthenticated attacker can exploit this to cause complete denial of service, terminating all active connections. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, PROXY Protocol v2 header generator emits TLVs beyond the maximum length of 65535 bytes, causing a mismatch between bytes written and the length field in the header. This can result in smuggled bytes on the upstream request. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.37.0 until 1.37.5 and 1.38.3, when the %REQUESTEDSERVERNAME(X:Y)% is used in log format and host related options is specified, like HOSTFIRST, SNIFIRST, it's possible to crash Envoy when the specified host header is missing in the request headers. This vulnerability is fixed in 1.37.5 and 1.38.3.

A weakness has been identified in Envoy up to 1.33.0. Affected is the function params.add of the file source/extensions/filters/http/headermutation/headermutation.cc of the component Query Parameter Handler. This manipulation causes injection. Remote exploitation of the attack is possible. Patch name: f8f4f1e02fdc64ecd4acf2d903208dd7285ad3a4. It is suggested to install a patch to address this issue.

Summary Envoy's extproc HTTP filter is at risk of crashing if a local reply is sent to the external server due to the filter's life time issue. A known situation is the fail of a websocket handshake will trigger a local reply leading to the crash of Envoy.

PoC If both websocket and extproc are enabled, a failed handshake will trigger a local reply, thus extproc will crash.

Mitigation 1. Disable websocket traffic 2. Change the websocket response from backend to always return 101 Switch protocol based on RFC. 3. Apply the patch and the extproc filter will not send the local reply that is generated by Envoy to the extproc server for processing. 4. Apply the patch that the router will cancel the upstream requests when sending a local reply.

Impact Denial of service

Reporter Vasilios Syrakis Fernando Cainelli

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

https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says: We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against most major web servers, including:

- nginx - Apache httpd - Microsoft IIS - Envoy - Cloudflare Pingora

The vulnerable behavior exists in each server's default HTTP/2 configuration. The blog tells the story of how it was found and provides technical details and PoCs.

It also says: Credits

Quang Luong for discovering the exploit. He'll be presenting his techniques at the upcoming Real World AI Security conference at Stanford in June.

Jun Rong and Duc Phan for confirming the attack on other web servers. and: Disclosure

We disclosed the issue to nginx in April. They responded by importing the maxheaders directive from freenginx, shipping it in 1.29.8 the next day: https://github.com/nginx/nginx/commit/365694160a85229a7cb006738de9260d49ff5fa2 At this point, we consider the attack public.

We disclosed to Apache on May 27, and Stefan Eissing fixed it on the same day by making cookie headers count against LimitRequestFields: https://github.com/apache/httpd/commit/47d3100b252dc6668a9e46ae885242be9eeca9cd The issue was assigned CVE-2026-49975.

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.

Mitigations

nginx: Upgrade to 1.29.8+, which adds the maxheaders directive with a default of 1000. If you can't upgrade, disable HTTP/2 with http2 off;.

Apache httpd: The fix is in modhttp2 v2.0.41, available from the standalone modhttp2 releases and in httpd trunk but not yet in a 2.4.x release. If you can't upgrade, set Protocols http/1.1 to disable HTTP/2. Lowering LimitRequestFieldSize shrinks the per-stream blast radius (it caps the merged cookie, and so the crumb count), but it's only a partial mitigation, since an attacker can still multiply the effect across streams and connections. Lowering LimitRequestFields does nothing here: the duplicate cookie crumbs never count against it.

Microsoft IIS, Envoy, Cloudflare Pingora: No patch available at the time of writing. Disable HTTP/2 if you can, or front the server with something that enforces a hard cap on header count per request.

Generally: "Maximum decoded header size" and "maximum header count" are two different limits, and a server needs both. Any HTTP/2 termination point should cap the number of header fields per request, including cookie crumbs, independent of their total size, and should bound the lifetime of a stalled stream regardless of WINDOWUPDATE activity. And if you can't do any of that today: cap per-worker memory (cgroups, ulimit -v, container limits) tight enough that a bombed worker gets OOM-killed and respawned before it drags the box into swap. A worker process rarely needs gigabytes; letting the kernel kill one early is a better failure mode than letting the attacker hold the whole machine at 95%.

Takeaways

RFC 7541 has an entire section on this threat. §7.3 Memory Consumption opens with "an attacker can try to cause an endpoint to exhaust its memory," then explains that HPACK bounds the dynamic table via SETTINGSHEADERTABLESIZE and considers the matter handled. But when five independent implementations all read that section and still ship the same class of bug, the defect is in the spec.

The deeper miss is that the spec frames memory risk purely as an amplification ratio, and ratio is only half the equation. A 70:1 amplifier is harmless if the memory is freed when the request completes. It becomes an attack because HTTP/2 lets the client hold the connection open almost for free, pinning every allocated byte for as long as they like.

The other thing worth noting is how this exploit was found. Both halves have been public for a decade. What Codex did was read the codebases, recognize that the two compose, and build the combined attack. That combination is obvious once you see it, and yet as far as we can tell no human had put it together against these servers.

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadablefeatures.rejectearlyconnectdata runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s) Sending data for a CONNECT request before receiving 2xx response.

Patches Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allowmissingorfailed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver and request) which causes a crash when the async HTTP response arrives.

PoC allowmissingorfailed or allowmissing is enabled The client send 2 Authorization headers the remote JWKS fetching failed There will be crash

Impact DoS and Crash

Mitigation Disable the allowmissingorfailed or allowmissing