CyberRota Analysis
AI-GeneratedKubernetes users utilizing Contour versions 1.23.0 to 1.33.4 are vulnerable due to a misconfiguration that allows requests lacking valid TLS SNI to bypass JWT verification, potentially exposing upstream services to unauthorized access. This issue arises when both `.spec.virtualhost.tls.enableFallbackCertificate` and `.spec.virtualhost.jwtProviders` are enabled simultaneously, which is not properly rejected by Contour. Organizations relying on these configurations should prioritize upgrading to Contour v1.33.5 or implementing the recommended workaround to mitigate the risk of unauthorized access.
Public Exploit Signal
A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.
Note: these links are listed for security research and verification purposes only.
Original NVD Description
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.