CVE-2026-50149: 
Contour vulnerability analysis and mitigation

CVE-2026-50149 is an improper JWT verification vulnerability in Project Contour, a Kubernetes ingress controller, that allows unauthenticated attackers to bypass JWT authentication by exploiting an incompatible configuration of fallback TLS certificates and JWT providers. When an HTTPProxy resource is configured with both .spec.virtualhost.tls.enableFallbackCertificate: true and .spec.virtualhost.jwtProviders, Contour fails to reject the invalid combination, allowing requests without a valid JWT token to reach upstream services. Affected versions span from v1.23.0 through v1.33.4 (Go module github.com/projectcontour/contour). The vulnerability was first published on May 28, 2026, and the advisory was updated on July 2, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Contour Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation) — specifically, Contour's failure to validate the compatibility of two HTTPProxy configuration fields. When enableFallbackCertificate is enabled, Contour serves a fallback TLS certificate to clients that omit the TLS Server Name Indication (SNI) extension or present an SNI that does not match any configured HTTPProxy FQDN. In this scenario, Contour's JWT verification logic is not applied to these fallback-routed requests, meaning they are forwarded to upstream services without token validation. The attack requires no privileges and no user interaction, but does require the target cluster to have at least one HTTPProxy with this specific misconfiguration — raising the attack complexity to High (GitHub Advisory, Contour Advisory).

Successful exploitation allows an unauthenticated remote attacker to access upstream services that are intended to be protected by JWT-based authentication, resulting in high confidentiality impact (unauthorized data access) and low integrity impact (potential for unauthorized actions on backend services). Availability is not directly affected. The scope of impact is limited to services exposed via misconfigured HTTPProxy resources, but in multi-tenant Kubernetes environments, this could expose sensitive APIs or data to unauthorized parties (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2026-50149. The EPSS score is 0.023% (7th percentile), indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the target environment to have a specifically misconfigured HTTPProxy resource, which limits the attack surface to clusters where both enableFallbackCertificate and jwtProviders are simultaneously configured (GitHub Advisory).

1. Reconnaissance: Identify a Kubernetes cluster running Contour v1.23.0–v1.33.4 as its ingress controller, accessible from the network.
2. Identify misconfigured HTTPProxy: Determine whether any HTTPProxy resources are configured with both enableFallbackCertificate: true and jwtProviders (this may be inferred from public-facing service behavior or, if cluster access is available, via kubectl get httpproxies -A -o json | jq -r '.items[]| select(.spec.virtualhost | .tls.enableFallbackCertificate and .jwtProviders)| "Invalid HTTPProxy found: \(.metadata.namespace)/\(.metadata.name)"').
3. Craft a non-SNI TLS request: Send a TLS connection to the Contour ingress endpoint without including the SNI extension, or with an SNI value that does not match any configured HTTPProxy FQDN. This causes Contour to route the request via the fallback certificate path.
4. Bypass JWT verification: Issue an HTTP request over the fallback TLS connection without a valid JWT token (e.g., omitting the Authorization header entirely). Contour will proxy the request to the upstream service without performing JWT validation.
5. Access protected upstream service: Receive the response from the upstream service, effectively bypassing the intended authentication control (GitHub Advisory, Contour Advisory).

• Network: TLS connections to the Contour ingress that omit the SNI extension or use an SNI value not matching any configured HTTPProxy FQDN, particularly those followed by HTTP requests to JWT-protected endpoints without an Authorization header.
• Logs: Contour/Envoy access logs showing requests routed via the fallback certificate (no SNI or unrecognized SNI) to upstream services that are expected to require JWT authentication, with no token present in the request headers.
• Kubernetes: Presence of HTTPProxy resources with both .spec.virtualhost.tls.enableFallbackCertificate: true and .spec.virtualhost.jwtProviders defined — detectable via: kubectl get httpproxies -A -o json | jq -r '.items[]| select(.spec.virtualhost | .tls.enableFallbackCertificate and .jwtProviders)| "Invalid HTTPProxy found: \(.metadata.namespace)/\(.metadata.name)"' (GitHub Advisory).

Upgrade Contour to v1.33.5, which rejects and marks invalid any HTTPProxy resources combining .spec.virtualhost.tls.enableFallbackCertificate: true with .spec.virtualhost.jwtProviders, assigning a status condition with the error reason TLSIncompatibleFeatures. As an immediate workaround without upgrading, remove either .spec.virtualhost.tls.enableFallbackCertificate or .spec.virtualhost.jwtProviders from any affected HTTPProxy resources. Administrators can identify affected resources using the kubectl and jq command provided in the advisory (GitHub Advisory, Contour Advisory).