CVE-2026-53716 in Envoy Gateway
Summary
by MITRE • 09/14/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/14/2026
The Envoy Gateway project serves as an open-source solution for managing the Envoy Proxy application gateway, supporting both standalone deployments and Kubernetes-based environments. Within this architecture, the system processes WebAssembly (Wasm) extensions defined in tenant-controlled configuration policies to extend proxy functionality. A critical security vulnerability exists within the internal component responsible for fetching these Wasm modules via HTTP. Specifically, the function getFileFromGZ located in the file httpfetcher.go contains a logic flaw that fails to adequately constrain resource consumption during the decompression of gzip-compressed payloads. This design oversight allows an attacker who controls or influences the EnvoyExtensionPolicy.spec.wasm[].code.http.url field to trigger excessive memory allocation on the shared controller process, leading to service disruption for all tenants sharing that control plane instance.
The technical root cause lies in how the system handles compressed input streams. While the implementation enforces a cap of 256 MiB on the size of the incoming compressed data stream, it does not apply any corresponding limit to the decompressed output buffer. When io.ReadAll is invoked on a gzip.Reader without such constraints, an attacker can craft a maliciously small but highly compressible gzip payload that expands into several gigabytes of uncompressed data upon processing. This phenomenon exploits the inherent properties of compression algorithms where specific patterns result in massive expansion ratios. Because the optional SHA256 integrity check occurs only after decompression is complete, it cannot prevent this initial resource exhaustion phase. Consequently, a relatively small network request can force the controller to allocate multi-gigabyte blocks of memory, quickly exhausting available system resources and causing an out-of-memory termination event that crashes the Envoy Gateway controller process.
The operational impact of this vulnerability extends far beyond a simple service restart for the affected instance. The crash triggers a recovery mechanism where the persistent custom resource is re-reconciled by the control plane. This cycle can create a persistent cross-tenant outage, as the repeated attempts to load and validate the malicious payload continue to consume resources until manual intervention or automatic backoff mechanisms eventually halt the loop. Since Envoy Gateway often manages traffic for multiple tenants in multi-cluster environments, this denial-of-service condition effectively degrades availability for all users relying on that specific gateway instance. The lack of an operator-configurable Wasm URL allowlist further exacerbates the risk by allowing any reachable HTTP endpoint to be targeted as a source for these malicious payloads, removing a potential layer of defense against untrusted extension sources.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting as excessive memory allocation during decompression operations. It also relates to CWE-787 Out-of-bounds Write if the underlying allocator behavior leads to heap corruption in extreme cases, though primarily it is a resource exhaustion issue. In terms of adversary tactics, this aligns with MITRE ATT&CK technique T1496 Resource Hijacking, where an attacker consumes system resources to degrade performance or cause denial of service for legitimate users. The vulnerability highlights the importance of validating and limiting decompressed sizes in any system that processes user-supplied compressed data, particularly when such processing occurs within shared infrastructure components like control planes.
To mitigate this risk, organizations running Envoy Gateway must upgrade immediately to version 1.7.4 or later, which includes patches for versions prior to these releases. The fix implements proper limits on the decompressed output size, ensuring that even if a highly compressible payload is submitted, the memory allocation remains within safe bounds defined by system policies rather than expanding indefinitely based on compression ratios. Additionally, operators should implement strict allowlists for Wasm module URLs at the configuration level to restrict which external sources can be referenced in EnvoyExtensionPolicy specifications. This defense-in-depth approach ensures that even if a vulnerability exists in future versions, the attack surface is significantly reduced by limiting exposure to untrusted or unpredictable remote resources. Regular auditing of extension policies and monitoring for unusual memory usage patterns on controller nodes are also recommended practices to detect potential exploitation attempts early.