Description

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1, Envoy copies every decoded HTTP/2 Host header value before discarding it when :authority is already present. The discarded value bypasses saveHeader, so its bytes and count are not charged against request header limits. An unauthenticated client can use HPACK indexing to submit many references to a large Host value across a bounded number of streams, forcing extreme header-copy allocation and causing the proxy to be out-of-memory killed. The relevant scope boundary is that the demonstrated amplification uses HTTP/2 HPACK and the duplicate Host discard behavior. This issue is fixed in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T20:17:28.733Z",
  "pubdate": "2026-09-21T20:17:28.733Z",
  "executiveSummary": "Envoy contains a memory exhaustion vulnerability triggered by improper HTTP/2 header handling. The issue stems from the proxy's behavior regarding redundant 'Host' headers when an ':authority' header is already present.\nPrior to versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1, Envoy copies redundant 'Host' header values into memory without applying standard header size limits or 'saveHeader' accounting.\nAn unauthenticated attacker can exploit this by utilizing HPACK indexing to reference large 'Host' values across multiple HTTP/2 streams. Because these copies bypass internal resource tracking, an attacker can induce excessive memory consumption, leading to an Out-Of-Memory (OOM) condition and subsequent denial of service.\nThis vulnerability poses a significant risk to the availability of cloud-native infrastructure, as it allows remote, unauthenticated actors to crash proxy instances with relatively low resource expenditure. Mitigation requires an immediate upgrade to the patched versions.",
  "technicalDetails": "The root cause of this vulnerability lies in the logic governing HTTP/2 header processing within the Envoy proxy. When Envoy decodes an incoming HTTP/2 request that contains both an ':authority' header and a 'Host' header, it identifies the 'Host' header as redundant. However, instead of immediately discarding or ignoring the incoming 'Host' header bytes, the implementation performs a memory copy operation before the final discard.\nCrucially, the code responsible for discarding these redundant 'Host' headers fails to invoke the 'saveHeader' function. The 'saveHeader' routine is typically responsible for enforcing request header limits and updating internal byte/count counters to ensure resource quotas are respected. By bypassing this routine, the memory allocated for these headers is effectively 'invisible' to Envoy’s resource management mechanisms.\nThe exploitation method leverages the HPACK compression protocol used by HTTP/2. An attacker can craft a malicious request stream that utilizes HPACK dynamic table entries to repeatedly reference a large, pre-defined 'Host' header value. By distributing these references across a bounded number of streams, the attacker can force the proxy to allocate significant amounts of memory for each redundant 'Host' header processed.\nThe attack flow proceeds as follows: 1) The attacker initiates an HTTP/2 connection to the Envoy proxy. 2) The attacker utilizes HPACK to index a large string value intended to be interpreted as a 'Host' header. 3) The attacker submits multiple requests within the stream that include the redundant 'Host' header. 4) The proxy decodes the HPACK index, allocates memory to copy the 'Host' value, and then performs a discard operation that bypasses the 'saveHeader' quota accounting. 5) By repeating this process at high volume, the cumulative memory consumption of these 'invisible' allocations exceeds the system's available memory, triggering an OOM-kill event.\nThe vulnerability affects all Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. It requires no authentication and is remotely exploitable over the network, making it a critical availability risk for any deployment exposing HTTP/2 endpoints."
}