Envoy Gateway's Wasm HTTP fetcher expands gzip data without restricting the decompressed size when a tenant provides a writable EnvoyExtensionPolicy.spec.wasm[].code.http.url. The getFileFromGZ routine reads the entire payload via io.ReadAll on a gzip.Reader, allowing a small compressed stream to allocate several gigabytes of memory. Because the compressed‑input cap of 256 MiB does not constrain the expanded size, a tenant can trigger an out‑of‑memory termination of the shared controller. Since there is no operator Wasm URL allowlist and the optional SHA‑256 verification occurs only after decompression, any tenant can supply a malicious URL. The controller restarts automatically, re‑reconciles the custom resource, and can create a persistent cross‑tenant outage. The flaw is a classic memory‑allocation weakness (CWE‑789) that can cause denial of service to all workloads routed through the affected Envoy Proxy.

The vulnerability affects all releases of Envoy Gateway older than v1.7.4 and v1.8.1, whether deployed as a standalone or in Kubernetes mode. Operators can trigger the flaw by configuring a tenant‑controlled EnvoyExtensionPolicy.spec.wasm[].code.http.url that points to a gzip‑compressed Wasm payload, since no allowlist exists and the optional SHA‑256 verification is performed only after decompression.

With a CVSS score of 6.5 the vulnerability poses a moderate severity threat. The EPSS score is < 1% and it is not listed in the CISA KEV catalog, but the attack path is relatively straightforward for a tenant that can define the Wasm URL. A malicious actor can trigger the unchecked decompression to exhaust memory, disrupt shared controller services, and cause a denial of service that affects other tenants. The impact is confined to the control plane of the gateway, yet it can be leveraged to deny service to all workloads routed through the affected Envoy Proxy.