Contour: fallback certificate with JWT providers lets SNI-less requests skip JWT verification

Impact

Contour accepts an HTTPProxy that sets both enableFallbackCertificate and jwtProviders instead of rejecting the combination. Requests that arrive with no TLS SNI, or an SNI matching no HTTPProxy FQDN, land on the fallback certificate path where the configured JWT provider is never consulted, and are proxied upstream without a valid token. Where Contour fronts inference endpoints, notebooks or internal APIs and the backend trusts the ingress to have done authentication, an unauthenticated caller reaches those backends directly. The exposure is entirely a function of configuration: clusters that never combine the two settings are not affected.

Who can reach it

Anyone who can open a TLS connection to the Contour/Envoy listener — the internet for a public ingress, the tenant network for an internal one. No authentication and no credentials needed; the attacker only has to omit SNI or present an unrecognised one. Requires an HTTPProxy that already carries both settings, which is why the record scores AC:H.

What to do

Upgrade to Contour v1.33.5, which marks such HTTPProxy resources invalid with a TLSIncompatibleFeatures status condition — expect those routes to stop serving once you upgrade, so audit them first. As an immediate workaround with no upgrade, edit the affected HTTPProxy resources to drop either enableFallbackCertificate or jwtProviders. Rolling the Contour deployment restarts the control plane and pushes new Envoy config; workloads and GPU nodes are untouched.

References