CVE-2026-53717
MediumCVSS 6.5Summary
Envoy Gateway before versions 1.7.4 and 1.8.1 has a vulnerability in the internal imagefetcher that fetches Wasm images based on tenant-controlled URLs. During extraction, an untrusted tar header size can cause a massive memory allocation, leading to an unrecoverable Go runtime out-of-memory failure and reconciliation crash-loops.
Risk Assessment
A single request can cause memory exhaustion and crash the shared controller, resulting in a cluster-wide denial of service without volumetric traffic.
Recommendation
Upgrade Envoy Gateway to version 1.7.4 or 1.8.1. Additionally, restrict access to OCI registries and consider validating tar entry sizes.
Other vulnerabilities in Envoy Gateway
See all- CVE-2026-53719Medium
Envoy Gateway prior to versions 1.7.4 and 1.8.1 has a nil dereference vulnerability in translateSecurityPolicyForRoute when a namespace-scoped tenant creates a SecurityPolicy targeting a TCPRoute and omits spec.authorization. The persistent object triggers a panic on every reconcile, stalling controller-wide xDS and infrastructure publishing until an administrator deletes the object.
- CVE-2026-53718Medium
Envoy Gateway prior to versions 1.7.4 and 1.8.1 allows an HTTPRoute to use an extension-managed custom backendRef to reference a backend resource in another namespace without a matching ReferenceGrant. The custom-backend branch omits validateBackendNamespace, violating the Gateway API cross-namespace authorization model.
- CVE-2026-53716Medium
Envoy Gateway prior to versions 1.7.4 and 1.8.1 has an unbounded decompression vulnerability in getFileFromGZ when a tenant-controlled URL points to a compressed Wasm payload. A small gzip stream can force a multi-gigabyte allocation in the shared controller, causing out-of-memory termination and potential persistent control-plane outage.
- CVE-2026-53715Medium
Envoy Gateway prior to versions 1.7.4 and 1.8.1 has a race condition in HTTPServer.ServeHTTP where unsynchronized reads of the mappingPath2Cache map can overlap with writes, causing the controller process to terminate and leading to a timing-dependent, cross-tenant control-plane denial of service.
- CVE-2026-53714High
Envoy Gateway in GatewayNamespaceMode has an unauthenticated xDS gRPC server — only a JWT StreamInterceptor is installed, with no UnaryInterceptor, and the streaming interceptor only validates DeltaDiscoveryRequest messages. Any pod that can reach port 18000 can retrieve TLS private keys, xDS resources, backend endpoints, and routing configuration. The issue is fixed in versions 1.7.4 and 1.8.1.
- CVE-2026-53713Critical
Envoy Gateway prior to 1.7.4 and 1.8.1 does not collapse redundant separators in to_absolute_normalized_path in internal/gatewayapi/luavalidator/security.lua before is_critical_path evaluates Lua submitted through EnvoyExtensionPolicy during default Strict validation. Linux resolves a double-slash absolute path as the corresponding single-slash path, but the validator does not match the redundant-separator form, allowing submitted Lua to read arbitrary files from the gateway controller pod. Exposed files can include Kubernetes service-account tokens, TLS certificates, and process environment data, and the disclosed credentials can provide access to sensitive Kubernetes API Server or Gateway xDS server information. This issue is fixed in versions 1.7.4 and 1.8.1.
- CVE-2026-22771High
A vulnerability in Envoy Gateway before versions 1.5.7 and 1.6.2 allows credential leakage via Lua scripts in EnvoyExtensionPolicy. Leaked credentials can be used to communicate with the control plane and access all secrets used by the proxy, including TLS private keys and communication credentials.
Original NVD description (English source)
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.