GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy Gateway: tar header size is trusted before validation, so one OCI Wasm layer crash-loops the controller

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

Impact

extractWasmPluginBinary allocates memory from the untrusted tar header h.Size before validating the entry name or the declared size, and the surrounding LimitReader only bounds bytes actually read from the stream. A PAX or GNU header declaring a multi-terabyte entry therefore triggers an allocation attempt per tar entry and an unrecoverable Go runtime out-of-memory abort. No registry allowlist exists, so a tenant permitted to create an EnvoyExtensionPolicy can point spec.wasm[].code.image.url at any registry the controller can reach. Because the custom resource persists, reconciliation restarts the crash and the shared controller loops: a single non-volumetric request produces a cluster-wide control-plane denial of service affecting every namespace. This is a separate code path from the gzip case in CVE-2026-53716 and is fixed by the same release.

Who can reach it

Any authenticated tenant with RBAC to create or edit an EnvoyExtensionPolicy, plus a crafted OCI or Docker image in a registry the controller can pull from.

What to do

Upgrade Envoy Gateway to 1.7.4 or 1.8.1 and restart the controller deployment. Before patching, limit EnvoyExtensionPolicy creation to trusted operators and constrain controller egress to known registries. Recovering a crash-looping controller requires deleting the offending custom resource.

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.