EUVD-2026-62414
GHSA-g3xr-5w5j-w4q4
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
AV:N and PR:N because attacker needs only network access with no credentials; AC:H because the misconfiguration prerequisite must exist; C:H for full JWT bypass exposing protected upstream data; I:L for potential unauthorized writes; A:N as availability is unaffected.
Primary rating from Vendor (https://github.com/projectcontour/contour).
CVSS VectorVendor: https://github.com/projectcontour/contour
Lifecycle Timeline
1DescriptionCVE.org
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
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://projectcontour.io/docs/main/config/jwt-verification/
AnalysisAI
JWT authentication bypass in Project Contour (Kubernetes ingress controller) allows unauthenticated remote clients to reach protected upstream services without a valid JWT token when an HTTPProxy resource incorrectly combines spec.virtualhost.tls.enableFallbackCertificate: true with spec.virtualhost.jwtProviders. Contour fails to detect and reject this incompatible configuration, so any TLS client that omits an SNI extension or presents an SNI not matching any configured HTTPProxy FQDN is silently matched by the fallback certificate handler, which operates outside the JWT verification pipeline. No public exploit has been identified and this CVE is not in the CISA KEV catalog; a vendor-released patch (v1.33.5) is available.
Technical ContextAI
Contour is a Kubernetes Ingress controller backed by the Envoy proxy, identified by CPE pkg:go/github.com_projectcontour_contour. Its HTTPProxy CRD supports TLS termination with a fallback certificate feature (spec.virtualhost.tls.enableFallbackCertificate), designed to serve a default TLS certificate to clients that do not send the TLS Server Name Indication (SNI) extension or send an SNI that does not match any known FQDN. Separately, spec.virtualhost.jwtProviders enables JWT bearer token validation on the virtual host. CWE-295 (Improper Certificate Validation) captures the root cause: Contour's configuration validation does not account for the semantic conflict between these two features. Because the fallback certificate path is resolved before the JWT verification middleware is consulted, requests entering via the fallback handler never reach the authentication layer, producing an authentication bypass rather than a certificate validation failure per se. The CWE classification reflects that the fallback certificate is, in effect, being trusted (served) in a context where it should be incompatible.
RemediationAI
Upgrade Contour to v1.33.5, which is the vendor-released patch for this issue. Beginning in v1.33.5, Contour proactively rejects any HTTPProxy that combines spec.virtualhost.tls.enableFallbackCertificate: true with spec.virtualhost.jwtProviders, marking the resource with a status condition bearing the error reason TLSIncompatibleFeatures, so operators will see an explicit validation failure rather than silent misconfiguration. If an immediate upgrade is not possible, the supported workaround is to remove one of the two conflicting settings from each affected HTTPProxy: either disable spec.virtualhost.tls.enableFallbackCertificate (which will cause clients without SNI to receive no certificate and fail to connect) or remove spec.virtualhost.jwtProviders (which disables JWT enforcement on that host - this should only be chosen if the upstream service has its own authentication). Use the provided kubectl/jq command from the advisory to enumerate all affected HTTPProxy resources before applying any change. Advisory: https://github.com/projectcontour/contour/security/advisories/GHSA-g3xr-5w5j-w4q4.
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today