GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy Gateway: unbounded gzip decompression of a tenant-supplied Wasm URL OOM-kills the shared controller

CVSS 6.5CVE-2026-53716Container, Kubernetes & orchestrationcurated

Impact

getFileFromGZ calls io.ReadAll on a gzip.Reader with no limit on the decompressed size. The 256 MiB cap applies only to the compressed input and the optional sha256 check runs after decompression, so a small gzip stream expands into a multi-gigabyte allocation inside the shared Envoy Gateway controller. There is no operator allowlist for Wasm URLs, so any tenant permitted to create an EnvoyExtensionPolicy can point spec.wasm[].code.http.url at a payload it controls. The controller is killed by the OOM killer, restarts, re-reconciles the still-present custom resource and crash-loops, which is a cross-tenant control-plane outage rather than a single-namespace problem: no new routes, no new backends, no config changes for anyone until an administrator finds and deletes the object. On a GPU cluster that means inference endpoints cannot be published or moved while nodes are being drained or replaced.

Who can reach it

Any authenticated tenant with RBAC to create or edit an EnvoyExtensionPolicy in its own namespace, plus a compressed Wasm payload at a URL the controller can reach.

What to do

Upgrade Envoy Gateway to 1.7.4 or 1.8.1 and restart the controller deployment; the data plane keeps serving the last good config during the rollout. Until then, restrict who may create EnvoyExtensionPolicy objects and use egress policy to limit which hosts the controller can fetch Wasm from. Clearing an in-flight incident requires deleting the offending custom resource, otherwise the restarted controller crash-loops again.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.