Description

Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, getFileFromGZ in internal/wasm/httpfetcher.go calls io.ReadAll on a gzip.Reader without limiting decompressed output when a tenant-controlled EnvoyExtensionPolicy.spec.wasm[].code.http.url points to a reachable compressed Wasm payload. The 256 MiB compressed-input cap does not constrain the expanded size, no operator Wasm URL allowlist exists, and the optional sha256 check occurs only after decompression, so a comparatively small gzip stream can force a multi-gigabyte allocation in the shared controller. The resulting out-of-memory termination restarts the controller, re-reconciles the persistent custom resource, and can create a persistent cross-tenant control-plane outage. This issue is fixed in versions 1.7.4 and 1.8.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T21:17:12.983Z",
  "pubdate": "2026-09-14T21:17:12.983Z",
  "executiveSummary": "Envoy Gateway is susceptible to an uncontrolled resource consumption vulnerability caused by the lack of decompression limits during the retrieval of Wasm payloads.\nThe vulnerability resides in the getFileFromGZ function within internal/wasm/httpfetcher.go, which processes tenant-controlled EnvoyExtensionPolicy resources.\nBy providing a maliciously crafted, highly compressed gzip stream, an attacker can force the Envoy Gateway controller to perform excessive memory allocation, leading to out-of-memory (OOM) termination of the process.\nThis vulnerability is particularly severe because the controller automatically re-reconciles persistent custom resources upon restart, creating a cycle of OOM failures that manifests as a persistent cross-tenant denial-of-service (DoS) condition on the control plane.\nThe attack is viable because the existing 256 MiB compressed-input cap does not prevent expansion to multi-gigabyte sizes, and the lack of a URL allowlist allows unauthorized payload sources.\nAffected versions include those prior to 1.7.4 and 1.8.1. Mitigation requires immediate upgrades to patched versions, alongside the implementation of strict network-level controls and administrative allowlists for Wasm payload sources.",
  "technicalDetails": "The root cause of this vulnerability is an 'Uncontrolled Resource Consumption' flaw in the getFileFromGZ function located in internal/wasm/httpfetcher.go. The function utilizes io.ReadAll on a gzip.Reader to decompress Wasm payloads fetched via HTTP from URLs specified in EnvoyExtensionPolicy.spec.wasm[].code.http.url.\nWhile the implementation enforces a 256 MiB limit on the compressed input stream, it fails to verify or restrict the size of the decompressed output buffer. Because gzip is capable of achieving high compression ratios, an attacker can craft a relatively small compressed payload that expands into several gigabytes of data when processed.\nThe exploitation flow initiates when a tenant defines an EnvoyExtensionPolicy that points to a malicious URL. The Envoy Gateway controller attempts to fetch and decompress the payload. During the decompression phase, the application attempts to allocate memory proportional to the decompressed size. Because the SHA256 integrity check is performed only after the entirety of the payload has been fully decompressed and stored in memory, the system is forced to commit large amounts of RAM to the process before it can validate the payload.\nThe exhaustion of system memory triggers an out-of-memory (OOM) termination of the Envoy Gateway controller. Due to the nature of Kubernetes-based operations, the controller process is automatically restarted by the orchestrator. Upon restart, the controller immediately re-reconciles the persistent, malicious custom resource, triggering the same decompression logic and causing a loop of repeated crashes.\nThis creates a persistent, cross-tenant control-plane outage, effectively disabling the gateway's ability to manage proxy configurations for all tenants. The vulnerability is amplified by the absence of a URL allowlist, which permits the controller to fetch payloads from arbitrary network locations, and the lack of pre-decompression integrity validation or streaming limits.\nThe vulnerability impacts Envoy Gateway versions prior to 1.7.4 and 1.8.1. No authentication or elevated privileges are required beyond the ability to submit or modify an EnvoyExtensionPolicy within the environment."
}