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, 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T20:16:45.270Z",
  "pubdate": "2026-09-14T20:16:45.270Z",
  "executiveSummary": "Envoy Gateway is vulnerable to an uncontrolled resource consumption flaw stemming from improper validation of OCI/Docker Wasm image metadata.\nThe vulnerability resides in the internal/wasm/imagefetcher.go file, where the extractWasmPluginBinary function performs memory allocation based on untrusted tar-header size values prior to validating the associated file entry.\nAn authenticated tenant with the ability to define EnvoyExtensionPolicy can specify malicious OCI image URLs, forcing the controller to allocate excessive memory.\nThis leads to an unrecoverable Go runtime out-of-memory (OOM) failure, resulting in a persistent crash-loop of the shared controller process.\nThe impact is a cluster-wide denial-of-service (DoS) condition affecting the control plane, as the custom resource remains in the cluster and triggers repeated failed reconciliations.\nThe vulnerability affects Envoy Gateway versions prior to 1.7.4 and 1.8.1.\nExploitation requires the ability to create or modify EnvoyExtensionPolicy custom resources within the Kubernetes environment, making this an elevation of risk for multi-tenant clusters where policy configuration is delegated to untrusted users.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of tar archive processing within the extractWasmPluginBinary function located in internal/wasm/imagefetcher.go. The logic relies on the h.Size value provided within PAX or GNU tar headers to perform memory pre-allocation for incoming Wasm plugin binaries.\nBecause the allocation occurs before the integrity or validity of the tar entry name or actual data stream is verified, an attacker can craft a malicious OCI/Wasm layer containing a specifically formed tar header. By declaring an extremely large size in the header, the attacker forces the Envoy Gateway controller to attempt a multi-terabyte memory allocation.\nWhile a LimitReader is employed to bound the number of bytes read from the network stream, the Go runtime attempts to satisfy the memory request dictated by the malicious header immediately. This immediate allocation attempt bypasses the protection offered by the LimitReader, as the request for memory occurs before the stream is fully read or validated against the actual payload size.\nThe attack flow follows these steps: 1) The attacker creates an EnvoyExtensionPolicy custom resource containing a spec.wasm[].code.image.url pointing to an attacker-controlled OCI registry. 2) The Envoy Gateway controller reconciles the resource and initiates a download of the specified image. 3) The extractWasmPluginBinary function parses the tar archive headers of the fetched image. 4) The controller encounters the malicious tar header and attempts to allocate the claimed (and vastly inflated) buffer size. 5) The Go runtime triggers an OOM panic due to the memory pressure. 6) The controller process crashes. 7) Since the malicious EnvoyExtensionPolicy resource persists in the Kubernetes etcd store, the controller attempts to reconcile it again upon restart, leading to a persistent crash-loop that effectively blinds the control plane.\nThis vulnerability is particularly severe in multi-tenant environments because there is no registry allowlist mechanism to restrict the sources from which Wasm plugins can be fetched, allowing tenants to point the gateway to arbitrary, attacker-controlled infrastructure.\nThe issue is resolved in Envoy Gateway versions 1.7.4 and 1.8.1, which presumably implement strict validation of tar-header metadata and enforce memory allocation limits consistent with actual data processing needs."
}