CVE-2026-53717 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, internal/wasm/imagefetcher.go follows tenant-controlled EnvoyExtensionPolicy spec.wasm[].code.image.url values to Docker or OCI Wasm layers, and extractWasmPluginBinary uses the untrusted tar-header h.Size value to allocate memory before validating the entry name or declared size. A small PAX or GNU tar header can therefore claim a multi-terabyte entry even though the surrounding LimitReader restricts only the bytes read from the stream, and no registry allowlist prevents a permitted tenant from selecting an attacker-controlled registry that the controller can reach. The allocation is attempted for every tar entry and can cause an unrecoverable Go runtime out-of-memory failure; because the custom resource persists, reconciliation repeatedly crash-loops the shared controller and causes a single-request, non-volumetric, cluster-wide control-plane denial of service. 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
Envoy Gateway serves as an open-source solution for managing Envoy Proxy deployments within standalone or Kubernetes environments, acting as a critical application gateway component. A significant security vulnerability exists within the internal wasm image fetcher logic prior to versions 1.7.4 and 1.8.1. This flaw stems from how the system processes tenant-controlled configurations specified in the EnvoyExtensionPolicy resource. Specifically, when handling WebAssembly plugins defined by users, the controller retrieves code images based on URLs provided in the spec.wasm[].code.image.url field. These references can point to Docker or OCI Wasm layers hosted on external registries that are accessible from the cluster network.
The core technical flaw lies in the memory allocation strategy employed during the extraction of WebAssembly plugin binaries. The function extractWasmPluginBinary relies on the Size value found within untrusted tar headers to determine how much memory to allocate before performing any validation of the entry name or verifying the actual declared size against limits. This approach is fundamentally insecure because it trusts metadata provided by external sources without sufficient verification. A malicious actor can craft a small PAX or GNU tar header that claims an extremely large file size, such as several terabytes, despite the surrounding LimitReader only restricting the number of bytes actually read from the stream during extraction.
This discrepancy between allocated memory and actual data volume leads to severe operational consequences. The system attempts to allocate massive amounts of heap memory for every tar entry processed based on these inflated header values. Since Go runtime does not handle such excessive allocation requests gracefully, it triggers an unrecoverable out-of-memory failure. This crash is particularly dangerous because the custom resource configuration persists in the cluster state. Consequently, the controller enters a continuous reconciliation loop where it repeatedly attempts to process the same malicious payload, resulting in repeated crashes and restarts of the shared control-plane component.
The impact of this vulnerability constitutes a non-volumetric, single-request denial of service that affects the entire cluster rather than just an individual tenant or workload. Because the controller manages multiple resources simultaneously, its crash disrupts the processing capabilities for all other pending operations within the Envoy Gateway infrastructure. This effectively halts gateway management functions and can lead to broader service disruptions depending on the architecture's reliance on this control plane component. The vulnerability is classified under CWE-789 as a memory allocation with incorrect size value, which allows an attacker to exhaust system resources through malformed input data structures.
From a threat modeling perspective using MITRE ATT&CK techniques, this scenario aligns with T1496 Resource Hijacking or more specifically resource exhaustion leading to service disruption. The attack vector involves leveraging trusted internal components by providing malicious external inputs that bypass validation checks before critical safety mechanisms like size limits are applied. This highlights the risk of trusting metadata from unverified sources in systems handling user-defined configurations.
To mitigate this vulnerability, organizations must upgrade Envoy Gateway to version 1.7.4 or later where these issues have been addressed. The fix likely involves validating tar header sizes against strict bounds before initiating memory allocation and ensuring that registry allowlists are properly configured to prevent tenants from pointing to attacker-controlled registries. Additionally implementing stricter validation of WebAssembly plugin sources and monitoring for unusual resource consumption patterns can provide defense-in-depth measures while patching is applied.