Most recent entries from all

BIT-contour-2026-50149 — Contour has Improper JWT Verification for Non-SNI Requests on Virtual Hosts with Fallback Certificate Enabled

2026-10-02T18:44:33.566259+00:00

Affected: Bitnami: contour

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.

CLEANSTART-2026-CU86688 — Contour is a Kubernetes ingress controller using Envoy proxy

2026-10-02T18:44:33.566316+00:00

Affected: CleanStart: external-dns

Security vulnerability affects the external-dns package. Contour is a Kubernetes ingress controller using Envoy proxy.

EUVD-2026-358406

2026-10-02T18:44:33.566340+00:00

EUVD-2026-358406

fkie_cve-2026-50149

2026-10-02T18:44:33.566354+00:00

GHSA-g3xr-5w5j-w4q4 — Contour has Improper JWT Verification for Non-SNI Requests on Virtual Hosts with Fallback Certificate Enabled

2026-10-02T18:44:33.566381+00:00

Affected: Go: github.com/projectcontour/contour

### Impact

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.

To list all `HTTPProxies` with this invalid configuration, run

```bash kubectl get httpproxies -A -o json | jq -r ' .items[] | select(.spec.virtualhost | .tls.enableFallbackCertificate and .jwtProviders) | "Invalid HTTPProxy found: \(.metadata.namespace)/\(.metadata.name)" ' ```

### Patches

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`.

### Workarounds

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.

### References

- Contour fallback certificate documentation: https://projectcontour.io/docs/main/config/tls-termination/#fallback-certificate - Contour JWT verification documentation: https://projectcontou…