Contour is a Kubernetes ingress controller using Envoy proxy. In versions 1.23.0 through 1.33.4, when an `HTTPProxy` is configured with incompatible combination of both `.spec.virtualhost.tls.enableFallbackCertificate: true` and `.spec.virtualhost.jwtProviders`, Contour does not reject the configuration. Consequently, requests from clients that do not send TLS SNI or send an unrecognized SNI (one that does not match any `HTTPProxy` FQDN) bypass configured JWT verification and are proxied to upstream services without a valid token. This issue is fixed in Contour v1.33.5. Contour now rejects and marks invalid any `HTTPProxy` resources that combine `.spec.virtualhost.tls.enableFallbackCertificate: true` with `.spec.virtualhost.jwtProviders`. Affected resources will receive a status condition with the error reason `TLSIncompatibleFeatures`. As a workaround, do not enable `.spec.virtualhost.tls.enableFallbackCertificate` on `HTTPProxy` resources that also define `.spec.virtualhost.jwtProviders`. Remove one of the two settings to avoid the invalid configuration.

Contour is a Kubernetes ingress controller using Envoy proxy. From v1.19.0 to before v1.33.4, v1.32.5, and v1.31.6, Contour's Cookie Rewriting feature is vulnerable to Lua code injection. An attacker with RBAC permissions to create or modify HTTPProxy resources can craft a malicious value in spec.routes[].cookieRewritePolicies[].pathRewrite.value or spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value that results in arbitrary code execution in the Envoy proxy. The cookie rewriting feature is internally implemented using Envoy's HTTP Lua filter. User-controlled values are interpolated into Lua source code using Go text/template without sufficient sanitization. The injected code only executes when processing traffic on the attacker's own route, which they already control. However, since Envoy runs as shared infrastructure, the injected code can also read Envoy's xDS client credentials from the filesystem or cause denial of service for other tenants sharing the Envoy instance. This vulnerability is fixed in v1.33.4, v1.32.5, and v1.31.6.