Project Contour CVE-2026-50149
MEDIUM
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 GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Lifecycle Timeline
1DescriptionGitHub Advisory
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires that an HTTPProxy resource in the target Kubernetes cluster is simultaneously configured with `spec.virtualhost.tls.enableFallbackCertificate: true` AND one or more entries under `spec.virtualhost.jwtProviders` - this is a non-default, operator-created misconfiguration. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The NVD-assigned CVSS 3.1 score of 6.5 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) is internally consistent: network-exploitable with no attacker-side privileges or user interaction required, but marked high complexity because the vulnerable condition (the specific dual-setting misconfiguration) must already exist on the target cluster. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who is aware that a target Kubernetes cluster runs Contour with a misconfigured HTTPProxy (fallback certificate plus JWT providers) initiates a TLS connection to the Contour ingress endpoint without including a TLS SNI extension - a capability trivially available in tools like `openssl s_client -noservername`. Contour's fallback certificate handler matches the connection, and because the JWT verification layer is bypassed for fallback-matched requests, the attacker's HTTP request is forwarded to the protected upstream API without a valid bearer token, gaining unauthorized access to the service. … |
| Remediation | Upgrade Contour to v1.33.5, which is the vendor-released patch for this issue. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today