CVE-2026-73550: 
Envoy vulnerability analysis and mitigation

CVE-2026-73550 is a memory exhaustion (denial-of-service) vulnerability in Envoy Proxy's HTTP/2 codec, dubbed "HTTP/2 Discarded Host Header 200 GB Header-Copy OOM." It affects all Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. The vulnerability was disclosed on August 26, 2026 via GitHub Security Advisory GHSA-qgf6-qvhw-4hvh and published to NVD on September 21, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is classified as CWE-401 (Missing Release of Memory after Effective Lifetime). In Envoy's HTTP/2 codec (codec_impl.cc), the OnHeaderForStream callback always calls value.setCopy() to copy every decoded header value before dispatching it. When an HTTP/2 request includes both a :authority pseudo-header and a legacy host header, ServerConnectionImpl::onHeader() discards the host value — but this discard occurs before ConnectionImpl::saveHeader() is called, meaning the copied bytes are never charged against the stream's header byte/count limits. An attacker exploits this gap using HPACK dynamic table indexing: by encoding one large host value (e.g., 4,000 bytes) and then referencing it via HPACK index hundreds of thousands of times across multiple streams, the attacker forces Envoy to repeatedly allocate copies of the value with no limit enforcement, producing roughly 200 GB of allocation from just 50 connections (GitHub Advisory, Patch Commit).

Successful exploitation causes the Envoy proxy process to exhaust its available memory and be OOM-killed by the operating system. This results in complete availability loss for all traffic routed through the affected Envoy instance — including edge proxy, service-mesh data-plane, and cloud infrastructure deployments. The attack has no confidentiality or integrity impact, but because Envoy is commonly deployed as a critical traffic gateway, a sustained attack can repeatedly crash and restart the process, rendering backend services unreachable. No authentication, control-plane access, or special configuration is required (GitHub Advisory).

A complete, runnable Python proof-of-concept exploit is publicly available in the GitHub Security Advisory. The PoC uses 50 TLS connections (within the Google VRP 100-connection limit) to trigger ~200 GB of header-copy allocation and OOM-kill the Envoy process. The exploit is fully automated, requires no authentication, and is network-accessible. The EPSS score is approximately 0.0088 (0.88%), and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. NVD SSVC classifies the exploit as "poc" with automatable exploitation (GitHub Advisory).

1. Reconnaissance: Identify internet-facing Envoy proxy instances with HTTP/2 (h2) support enabled on their downstream listener port (e.g., port 10000 in the Google VRP environment). Confirm the target is running a vulnerable version (prior to 1.36.10, 1.37.6, 1.38.4, or 1.39.1).
2. Establish TLS connections: Open 50 TLS connections to the target Envoy port using ALPN negotiation for h2 (HTTP/2). Use ssl.create_default_context() with ctx.set_alpn_protocols(['h2']) and disable certificate verification.
3. HTTP/2 handshake: On each connection, send the HTTP/2 client connection preface (PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n) followed by a SETTINGS frame, receive the server SETTINGS, and send a SETTINGS ACK.
4. Craft malicious HPACK header block: Build an HTTP/2 header block containing standard pseudo-headers (:method GET, :scheme https, :authority localhost, :path /content) plus one large host header value of 4,000 bytes (e.g., 'a' * 4000) added to the HPACK dynamic table at index 62, followed by 999,999 HPACK indexed references (\xbe repeated) to that same large value.
5. Fragment and send: Split the ~1 MiB header block into 16,384-byte chunks. Send the first chunk as a HEADERS frame (with END_STREAM flag, stream ID 1), intermediate chunks as CONTINUATION frames, and the final chunk as a CONTINUATION frame with END_HEADERS set.
6. Repeat across all connections: Use non-blocking I/O (select.select()) to send the full payload across all 50 connections concurrently.
7. Trigger OOM: Envoy decompresses the HPACK block, calling value.setCopy() for each of the 1,000,000 host header references per stream × 50 streams, allocating approximately 200 GB of memory. The process is OOM-killed by the OS kernel.
8. Verify: Confirm the OOM kill via container/process inspection (e.g., docker inspect showing OOMKilled=true, or supervisor logs showing exit status 137) (GitHub Advisory).

• Network: Sudden spike in concurrent TLS/HTTP/2 connections to the Envoy listener port from a single or small set of source IPs; large volumes of HTTP/2 CONTINUATION frames following a single HEADERS frame on the same stream.
• Process: Envoy process terminating with exit code 137 (SIGKILL from OOM killer); supervisor logs showing repeated envoy-edge respawn events in rapid succession.
• Logs: Envoy access logs showing incomplete or reset streams with no corresponding upstream request; system kernel logs (dmesg) containing Out of memory: Kill process referencing the Envoy PID.
• Metrics: Sharp spike in Envoy's http2.header_list_size_too_large or http2.header_overflow counters (on patched versions that detect the condition); rapid increase in memory usage metrics for the Envoy process approaching configured memory limits (GitHub Advisory).

Upgrade Envoy to one of the patched versions: 1.36.10, 1.37.6, 1.38.4, or 1.39.1. The fix tracks discarded host header sizes in new per-stream counters (discarded_host_header_size_ and discarded_host_header_count_) and includes them in header limit enforcement via a new checkHeaderLimits() function, controlled by the runtime guard envoy.reloadable_features.http2_track_size_of_dropped_host_header (enabled by default). If immediate patching is not possible, deploy network-level rate limiting or connection limits upstream of Envoy to restrict the number of concurrent HTTP/2 connections per client, or use an upstream load balancer to enforce request header size limits (GitHub Advisory, Patch Commit).

The vulnerability was originally submitted to the Google Vulnerability Reward Program (VRP) and coordinated through envoy-security@googlegroups.com, with the advisory published by Envoy maintainer phlax and credited to researcher 0range1337. The issue was also picked up by downstream distributors including Istio (releasing a patched version 1.30.4), Amazon Linux (ALAS2ECS-2026-137 and ALAS2023-2026-2149), and openSUSE security announcements. Tenable published a Nessus detection plugin (ID 345786/345777). Social media coverage was noted on Mastodon via TheHackerWire (GitHub Advisory).