CVE-2026-73550 in Envoy
Summary
by MITRE • 09/21/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
Envoy serves as a critical infrastructure component for cloud-native environments, functioning as an edge and service proxy that manages traffic routing, load balancing, and observability. The vulnerability identified in versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1 stems from a specific logic flaw within the HTTP/2 protocol implementation regarding header processing. When an incoming request contains both the :authority pseudo-header field and a standard Host header, Envoy is designed to prioritize the :authority value and discard the duplicate Host header to comply with RFC standards that prohibit redundant authority information in HTTP/2 requests. However, the internal handling of this discarded data introduces a resource management error where the proxy copies every decoded HPACK-decoded Host header value into memory before deciding to discard it, rather than avoiding the copy operation entirely or properly accounting for its size during the discarding phase.
The technical core of this flaw lies in how Envoy manages request header limits and memory allocation under HTTP/2 multiplexing conditions. The proxy maintains strict limits on the total size of headers allowed per stream to prevent abuse, enforced through a mechanism that tracks byte counts via saveHeader operations. Because the discarded Host header bytes bypass these accounting mechanisms, they are not charged against the configured request header limits. This creates a discrepancy between the logical limit enforcement and actual memory consumption. An unauthenticated attacker can exploit this by leveraging HPACK indexing to send numerous references to a single large Host value across multiple concurrent streams within a bounded number of connections. Since each stream triggers the copy-and-discard cycle without incrementing the header size counter, the proxy accumulates significant amounts of allocated but logically ignored memory rapidly.
This behavior results in an out-of-memory condition that can lead to the Envoy process being killed by the operating system’s Out-Of-Memory killer or causing a denial of service for legitimate traffic routed through the affected instance. The attack vector relies on HTTP/2 HPACK compression features and the specific duplicate Host discard logic, allowing for extreme header-copy amplification with minimal network bandwidth usage from the attacker's perspective. This aligns with CWE Category 787: Out-of-bounds Write or Allocation issues related to improper resource management, specifically falling under CWE-400: Uncontrolled Resource Consumption which leads to Denial of Service. From a threat intelligence perspective, this exploitation technique maps to MITRE ATT&CK techniques involving resource exhaustion and potentially abuse of proxy services for denial of service attacks against backend infrastructure.
Mitigation requires immediate upgrading to patched versions including 1.36.10, 1.37.6, 1.38.4, or 1.39.1 where the header accounting logic has been corrected to ensure discarded headers do not bypass resource limits. In environments where patching is delayed, operators should consider implementing rate limiting at a network perimeter device that counts all incoming bytes regardless of HTTP/2 pseudo-header presence, thereby enforcing stricter controls on connection-level traffic volume. Additionally, configuring lower maximum concurrent streams per connection can reduce the blast radius of such amplification attacks by limiting the number of parallel requests an attacker can initiate within a single TCP stream to exploit this specific memory leak pattern.