CVE-2026-50149: Contour Auth Bypass Vulnerability

CVE-2026-50149 Overview

CVE-2026-50149 is a JSON Web Token (JWT) verification bypass in Contour, a Kubernetes ingress controller built on the Envoy proxy. The flaw affects Contour versions 1.23.0 through 1.33.4. When an HTTPProxy resource combines .spec.virtualhost.tls.enableFallbackCertificate: true with .spec.virtualhost.jwtProviders, Contour accepts the incompatible configuration instead of rejecting it. Clients that omit TLS Server Name Indication (SNI) or send an unrecognized SNI reach upstream services through the fallback certificate path without JWT validation. The issue maps to [CWE-295: Improper Certificate Validation] and is fixed in Contour v1.33.5.

Critical Impact
Attackers can bypass JWT authentication on protected routes by sending TLS requests without matching SNI, reaching upstream services without a valid token.

Affected Products

Project Contour versions 1.23.0 through 1.33.4
Kubernetes clusters using Contour as ingress controller
Envoy-based service meshes deployed via Contour HTTPProxy resources

Discovery Timeline

2026-08-19 - CVE-2026-50149 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-50149

Vulnerability Analysis

Contour reconciles HTTPProxy custom resources into Envoy configuration for L7 routing, TLS termination, and JWT verification. The controller supports a fallback certificate that serves TLS to clients that fail to present a recognized SNI value. It also supports per-virtualhost JWT providers, which enforce token validation on incoming requests. These two features operate on different request-processing paths inside Envoy. The fallback certificate path did not inherit the JWT verification filter chain applied to SNI-matched virtualhosts. Contour failed to reject this combination during resource validation, allowing operators to deploy configurations that appear protected but silently omit JWT checks for non-SNI traffic.

Root Cause

The root cause is missing configuration validation in the HTTPProxy admission logic. Contour did not treat the coexistence of enableFallbackCertificate: true and jwtProviders as mutually exclusive. As a result, the generated Envoy listener served the fallback certificate without attaching the JWT authentication filter, breaking the security contract that JWT providers were intended to enforce.

Attack Vector

An attacker sends an HTTPS request to the Contour-managed ingress endpoint without setting SNI or using an SNI value that does not match any configured HTTPProxy FQDN. Envoy serves the fallback certificate and routes the request to the upstream service without invoking JWT verification. The attacker reaches endpoints that operators believed were gated by token authentication. No credentials, user interaction, or privileged position are required, though the attacker must know or guess the upstream route structure exposed through the fallback path.

The technical mechanism is described in the GitHub Security Advisory GHSA-g3xr-5w5j-w4q4. No public exploit code is available at the time of publication.

Detection Methods for CVE-2026-50149

Indicators of Compromise

Successful HTTP requests to JWT-protected upstream services that lack an Authorization: Bearer header in Envoy access logs.
TLS handshakes served with the fallback certificate for hostnames that also appear in HTTPProxy resources with jwtProviders configured.
Upstream application logs showing authenticated endpoints returning 2xx responses to requests with no token or with an unverified token.

Detection Strategies

Audit all HTTPProxy resources in the cluster and flag any that define both .spec.virtualhost.tls.enableFallbackCertificate: true and .spec.virtualhost.jwtProviders.
Correlate Envoy access logs against upstream authentication logs to identify requests that reached protected services without a corresponding JWT validation event.
Compare TLS SNI values in ingress logs against the configured FQDN set and alert on high volumes of missing or non-matching SNI reaching JWT-protected virtualhosts.

Monitoring Recommendations

Ingest Contour and Envoy access logs into a centralized analytics platform and normalize request metadata for SNI, JWT filter outcome, and upstream cluster.
Track the Contour controller status conditions and alert when resources report the TLSIncompatibleFeatures reason after upgrade.
Baseline the ratio of authenticated versus unauthenticated requests per route and alert on deviations that indicate authentication bypass.

How to Mitigate CVE-2026-50149

Immediate Actions Required

Upgrade Contour to version 1.33.5 or later across all clusters.
Enumerate every HTTPProxy resource and remove either enableFallbackCertificate or jwtProviders where both are set.
Review upstream application logs for the affected time window and identify requests that bypassed JWT verification.

Patch Information

Contour v1.33.5 fixes the flaw by rejecting HTTPProxy resources that combine .spec.virtualhost.tls.enableFallbackCertificate: true with .spec.virtualhost.jwtProviders. Rejected resources are marked invalid and receive a status condition with the reason TLSIncompatibleFeatures. Details are documented in the Project Contour Security Advisory.

Workarounds

Do not enable .spec.virtualhost.tls.enableFallbackCertificate on any HTTPProxy that also defines .spec.virtualhost.jwtProviders.
Remove enableFallbackCertificate: true from affected resources and rely on per-virtualhost TLS certificates so that unmatched SNI connections are rejected at TLS termination.
Enforce JWT validation at the upstream service layer as defense in depth so that a bypass at the ingress does not grant access to protected APIs.

bash

# Configuration example: identify affected HTTPProxy resources
kubectl get httpproxy -A -o json | \
  jq '.items[] | select(
    .spec.virtualhost.tls.enableFallbackCertificate == true and
    (.spec.virtualhost.jwtProviders | length > 0)
  ) | {namespace: .metadata.namespace, name: .metadata.name}'