CVE-2026-53716: Envoy Gateway DOS Vulnerability

CVE-2026-53716 Overview

CVE-2026-53716 is a memory exhaustion vulnerability in Envoy Gateway, an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. The flaw resides in getFileFromGZ within internal/wasm/httpfetcher.go, which decompresses gzip-compressed Wasm payloads without an output-size limit. A tenant-controlled EnvoyExtensionPolicy.spec.wasm[].code.http.url can point to a small compressed archive that expands into multi-gigabyte allocations. The out-of-memory termination restarts the shared controller and re-reconciles the persistent custom resource, producing a durable cross-tenant control-plane outage. Envoy Gateway versions prior to 1.7.4 and 1.8.1 are affected.

Critical Impact
A low-privileged tenant can trigger a persistent, cross-tenant denial-of-service in the shared Envoy Gateway control plane by supplying a crafted gzip Wasm URL.

Affected Products

Envoy Gateway versions prior to 1.7.4
Envoy Gateway versions prior to 1.8.1
Kubernetes deployments using EnvoyExtensionPolicy with Wasm extensions

Discovery Timeline

2026-09-14 - CVE-2026-53716 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-53716

Vulnerability Analysis

The vulnerability is a resource exhaustion flaw classified as [CWE-789] Memory Allocation with Excessive Size Value. Envoy Gateway fetches Wasm extension payloads referenced by tenant-controlled EnvoyExtensionPolicy custom resources. When the payload is gzip-compressed, the getFileFromGZ function in internal/wasm/httpfetcher.go calls io.ReadAll on a gzip.Reader without imposing any bound on decompressed output.

The existing 256 MiB cap only constrains the compressed input, not the expanded stream. There is no operator-side Wasm URL allowlist, and the optional sha256 integrity check runs only after the payload has already been fully decompressed into memory. As a result, a crafted archive with a high compression ratio forces a multi-gigabyte allocation in the shared controller process.

Root Cause

The root cause is missing bounds enforcement on decompressed data combined with an insufficient trust boundary between tenants and the shared controller. Because the controller reconciles persistent custom resources, an out-of-memory kill triggers a restart, re-reads the malicious EnvoyExtensionPolicy, and re-attempts the fetch. This creates a self-sustaining crash loop across all tenants sharing the control plane.

Attack Vector

An authenticated tenant with permission to create or modify an EnvoyExtensionPolicy sets spec.wasm[].code.http.url to a reachable HTTP endpoint serving a gzip-compressed Wasm file crafted as a compression bomb. The controller fetches the archive, decompresses it without limit, and exhausts node memory. The persistent custom resource ensures the outage survives controller restarts.

// Patch behavior added in v1.7.4 / v1.8.1 constrains decompression
// and enforces backend/reference validation for cross-namespace usage.
} else {
    // Custom backend resources still require ReferenceGrant for cross-namespace references.
    if err = t.validateBackendNamespace(backendRef, route, resources, routeType); err != nil {
        return emptyDS, nil, err
    }
}

Source: Envoy Gateway commit 5a78db8

Detection Methods for CVE-2026-53716

Indicators of Compromise

Repeated out-of-memory (OOMKilled) terminations of the envoy-gateway controller pod in Kubernetes event logs.
EnvoyExtensionPolicy custom resources referencing external http.url values that point outside of trusted registries.
Outbound HTTP GET requests from the controller pod to unfamiliar endpoints serving application/gzip or .wasm.gz content.
Sudden multi-gigabyte memory growth in the controller process immediately preceding a crash.

Detection Strategies

Audit all EnvoyExtensionPolicy resources across namespaces and flag any with tenant-controlled Wasm URLs not on an operator allowlist.
Correlate controller crash-loop events with recent create or update operations on EnvoyExtensionPolicy objects via Kubernetes audit logs.
Alert on abnormal decompression ratios for outbound fetches originating from the Envoy Gateway controller.

Monitoring Recommendations

Set memory limits and requests on the envoy-gateway controller pod and alert on approaching the limit.
Ship Kubernetes API server audit logs and controller stdout to a centralized SIEM for correlation of EnvoyExtensionPolicy writes and controller restarts.
Monitor egress traffic from the control-plane namespace and baseline expected Wasm registry destinations.

How to Mitigate CVE-2026-53716

Immediate Actions Required

Upgrade Envoy Gateway to version 1.7.4 or 1.8.1, matching your current release branch.
Inventory and review all existing EnvoyExtensionPolicy resources, removing or restricting any using untrusted http.url sources.
Restrict RBAC permissions so that only trusted operators can create or modify EnvoyExtensionPolicy custom resources.

Patch Information

The issue is fixed in Envoy Gateway v1.7.4 and v1.8.1. Additional details are available in GHSA-cxpq-8v7q-cg56 and pull requests #9171, #9172, and #9173.

Workarounds

Block egress from the Envoy Gateway controller namespace to arbitrary internet destinations, permitting only vetted Wasm registries.
Use Kubernetes admission controllers (for example, OPA Gatekeeper or Kyverno) to reject EnvoyExtensionPolicy resources whose Wasm URLs are not on an allowlist.
Isolate multi-tenant workloads onto separate Envoy Gateway control-plane instances to contain blast radius until patching is complete.

bash

# Example Kyverno policy fragment to restrict Wasm URLs to an allowlist
# Reject EnvoyExtensionPolicy resources referencing untrusted Wasm hosts
kubectl get envoyextensionpolicy -A -o json | \
  jq '.items[] | {ns: .metadata.namespace, name: .metadata.name,
                  urls: [.spec.wasm[]?.code.http.url]}'

# Upgrade to a patched release
helm upgrade eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.8.1 -n envoy-gateway-system