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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-19T15:17:08.710Z",
  "pubdate": "2026-08-19T15:17:08.710Z",
  "executiveSummary": "A security vulnerability affects Contour, a Kubernetes ingress controller utilizing the Envoy proxy, specifically in versions 1.23.0 through 1.33.4. The vulnerability arises from an improper configuration validation handling when an HTTPProxy resource simultaneously defines .spec.virtualhost.tls.enableFallbackCertificate: true and .spec.virtualhost.jwtProviders.\nThis flawed combination leads to a security control bypass. Specifically, client requests that omit TLS Server Name Indication (SNI) or present an unrecognized SNI—meaning it fails to match any configured HTTPProxy Fully Qualified Domain Name (FQDN)—successfully bypass mandatory JSON Web Token (JWT) verification checks.\nConsequently, unauthenticated or improperly tokenized traffic is proxied directly to internal upstream services, completely subverting API security boundaries. Attackers capable of establishing TLS connections without valid or recognized SNI extensions can exploit this behavior to achieve unauthorized access to backend applications protected by JWT validation.\nRisk implications are significant as perimeter security controls enforced at the ingress layer are circumvented due to configuration acceptance flaws. The issue requires specific configuration patterns involving both fallback certificates and JWT providers simultaneously, limiting exploitation strictly to environments utilizing this exact feature combination.",
  "technicalDetails": "The root cause of the vulnerability lies in the validation logic of Contour versions 1.23.0 through 1.33.4. The ingress controller fails to reject HTTPProxy resources that configure an incompatible combination of fallback certificates and JWT providers under the virtualhost specifications.\nThe vulnerable components are the Contour configuration validation engine and the resulting Envoy proxy routing and filter chain configuration generated for the HTTPProxy resource. During normal operation, JWT providers enforce token validation across incoming requests matching the virtualhost definitions.\nHowever, when .spec.virtualhost.tls.enableFallbackCertificate is set to true alongside .spec.virtualhost.jwtProviders, Envoy routes requests lacking a recognized SNI or omitting SNI entirely via the fallback mechanism. Due to the lack of pre-flight validation rejection in Contour, the generated Envoy configuration misaligns the filter chains, causing the JWT authentication filter to be bypassed entirely for these fallback routing paths.\nThe step-by-step attack flow proceeds as follows: First, an operator deploys an HTTPProxy resource containing both .spec.virtualhost.tls.enableFallbackCertificate: true and .spec.virtualhost.jwtProviders. Second, Contour accepts this invalid configuration without generating a validation error or status condition rejection. Third, an external attacker establishes a TLS connection to the ingress controller either without specifying an SNI extension or by providing an arbitrary, unmatched SNI value. Fourth, the Envoy proxy terminates the TLS connection using the configured fallback certificate. Fifth, because the request matches the fallback handling instead of the strict virtualhost routing rules enforcing token verification, the request bypasses the JWT filter. Finally, the unauthenticated request is successfully proxied to the upstream backend service, granting unauthorized access.\nNetwork exposure is external, directly targeting the ingress controller endpoints. No authentication or user privileges are required by the client initiating the request, as the exploitation vector relies purely on the manipulation or omission of the TLS SNI extension during the initial handshake phase."
}