CVE-2026-50149
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.
Does this matter?
Lower severity and a low EPSS score (0.15%). Track it; it rarely justifies an emergency change on its own.
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.
- CVSS 3.1
- 6.5 MEDIUMCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
- EPSS
- 0.15% probability · 4th percentile
- CISA KEV
- Not listed
- Weakness
- CWE-295
- Source
- security-advisories@github.com
Source: NVD record, EPSS from FIRST.org, KEV from CISA. Refreshed daily.