CVE-2026-53719: Envoy Gateway DOS Vulnerability

CVE-2026-53719 Overview

CVE-2026-53719 is a nil pointer dereference vulnerability [CWE-476] in Envoy Gateway, an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. The flaw exists in the translateSecurityPolicyForRoute function within internal/gatewayapi/securitypolicy.go. A namespace-scoped tenant can create a SecurityPolicy targeting a TCPRoute while omitting spec.authorization, causing the controller to dereference a nil authorization value. The persistent object triggers a panic on every reconcile loop, stalling controller-wide xDS and infrastructure intermediate-representation publishing. Versions prior to 1.7.4 and 1.8.1 are affected.

Critical Impact
An authenticated tenant with namespace-scoped access can halt xDS configuration publishing across the entire gateway control plane by submitting a single malformed SecurityPolicy object, blocking configuration updates until an administrator manually deletes the offending resource.

Affected Products

Envoy Gateway versions prior to 1.7.4
Envoy Gateway versions prior to 1.8.1
Kubernetes environments running vulnerable Envoy Gateway controller instances

Discovery Timeline

2026-09-14 - CVE-2026-53719 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-53719

Vulnerability Analysis

The vulnerability resides in the translateSecurityPolicyForRoute function in internal/gatewayapi/securitypolicy.go. When the controller processes a SecurityPolicy custom resource that targets a TCPRoute and omits the spec.authorization field, the translation logic dereferences a nil pointer. The resulting panic is recovered by defer handlers in message/watchutil.go, keeping the controller process alive.

However, the recovery unwinds the runner/runner.go handle callback, halting xDS translation and intermediate-representation publishing across the controller. Because the offending SecurityPolicy object persists in the cluster, every subsequent reconcile triggers the same panic. The data plane continues serving the last known good configuration, but no new routes, backends, or policy changes reach Envoy instances until an administrator manually deletes the malformed object.

Root Cause

The root cause is missing nil validation in the security policy translation pipeline. The code assumes spec.authorization is populated when a SecurityPolicy targets a TCPRoute, but the API schema permits omission of this field. Without a nil guard, dereferencing the authorization value produces a Go runtime panic classified under [CWE-476].

Attack Vector

Exploitation requires authenticated access to a Kubernetes namespace where the tenant holds permission to create SecurityPolicy resources. The attacker submits a SecurityPolicy manifest referencing a TCPRoute target while leaving the authorization block empty. Because the reconcile loop repeatedly encounters the object, the impact is persistent denial of configuration updates rather than a transient panic.

// Source: https://github.com/envoyproxy/gateway/commit/5a78db82b7cf4fc5bebbeda2c50952892038a464
// Patch context in internal/gatewayapi/route.go - adds validation for backend namespace references
				return emptyDS, nil, err
			}
		}
	} 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
		}
	}

	// Skip processing backends with 0 weight

Source: Envoy Gateway Commit 5a78db8

Detection Methods for CVE-2026-53719

Indicators of Compromise

Repeated panic stack traces in Envoy Gateway controller logs referencing translateSecurityPolicyForRoute or securitypolicy.go
Recovered panics logged by message/watchutil.go accompanied by stalled xDS publish activity
Presence of SecurityPolicy objects targeting a TCPRoute with an empty or missing spec.authorization field
Data plane configuration divergence where new HTTPRoute or TCPRoute resources fail to propagate to Envoy instances

Detection Strategies

Audit Kubernetes API server logs for SecurityPolicy CREATE and UPDATE events referencing TCPRoute targets
Compare the desired configuration state against the running Envoy xDS snapshot to identify publishing stalls
Monitor Envoy Gateway controller pod restart counts and panic recovery metrics for anomalies

Monitoring Recommendations

Configure alerting on Envoy Gateway controller log entries containing runtime error: invalid memory address or nil pointer dereference
Track xDS update latency and publish success rate as service-level indicators for the control plane
Instrument Kubernetes admission controller policies to log all SecurityPolicy submissions for post-incident review

How to Mitigate CVE-2026-53719

Immediate Actions Required

Upgrade Envoy Gateway to version 1.7.4 or 1.8.1 immediately in all affected clusters
Identify and delete any existing SecurityPolicy objects that target a TCPRoute without a populated spec.authorization field
Restrict SecurityPolicy create and update permissions to trusted operators using Kubernetes RBAC

Patch Information

The issue is fixed in Envoy Gateway v1.7.4 and v1.8.1. Full technical details are available in the Envoy Gateway Security Advisory GHSA-m2v6-2jmh-4c68. Patches were applied through Pull Request #9171, Pull Request #9172, and Pull Request #9173.

Workarounds

Deploy a Kubernetes ValidatingAdmissionWebhook or OPA Gatekeeper policy that rejects SecurityPolicy resources targeting TCPRoute with missing spec.authorization
Limit SecurityPolicy write permissions to a small set of trusted namespaces or service accounts until upgrade is complete
Monitor controller logs continuously so administrators can delete offending objects quickly if the panic condition occurs

bash

# Example admission policy rejecting SecurityPolicy targeting TCPRoute without authorization
kubectl apply -f - <<EOF
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: securitypolicy-tcproute-guard
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["gateway.envoyproxy.io"]
      apiVersions: ["v1alpha1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["securitypolicies"]
  validations:
    - expression: "!(object.spec.targetRefs.exists(t, t.kind == 'TCPRoute') && !has(object.spec.authorization))"
      message: "SecurityPolicy targeting TCPRoute must include spec.authorization"
EOF