OpenShift Router CVE-2026-46579: mTLS Authentication Bypass via Header Spoofing on HTTP Frontend

Introduction

An unpatched flaw in the OpenShift Router allows unauthenticated attackers to completely bypass mutual TLS authentication by injecting forged X-SSL-Client-* headers through the plain HTTP frontend. For the thousands of enterprises running OpenShift in production, any Route configured with insecureEdgeTerminationPolicy: Allow where backends trust these headers for client certificate validation is directly exposed to identity spoofing.

Technical Information

Architecture of the OpenShift Router's HAProxy Frontends

The OpenShift Router uses HAProxy as its underlying reverse proxy, configured through a Go template file (haproxy-config.template). This template defines three frontends that handle inbound traffic differently:

The HTTPS frontends (fe_sni and fe_no_sni) inject the following headers using HAProxy's built-in SSL fetch methods, which are only available after TLS termination and client certificate validation:

http-request set-header X-SSL %[ssl_fc]
http-request set-header X-SSL-Client-Verify %[ssl_c_verify]
http-request set-header X-SSL-Client-Serial %{+Q}[ssl_c_serial,hex]
http-request set-header X-SSL-Client-Version %{+Q}[ssl_c_version]
http-request set-header X-SSL-Client-SHA1 %{+Q}[ssl_c_sha1,hex]
http-request set-header X-SSL-Client-DN %{+Q}[ssl_c_s_dn]
http-request set-header X-SSL-Client-CN %{+Q}[ssl_c_s_dn(cn)]
http-request set-header X-SSL-Issuer %{+Q}[ssl_c_i_dn]
http-request set-header X-SSL-Client-NotBefore %{+Q}[ssl_c_notbefore]
http-request set-header X-SSL-Client-NotAfter %{+Q}[ssl_c_notafter]
http-request set-header X-SSL-Client-DER %{+Q}[ssl_c_der,base64]

These headers are populated from actual TLS handshake data and are therefore trustworthy when set by the HTTPS frontends. Backend applications that rely on these headers for mTLS authentication decisions trust them implicitly.

The Root Cause: Missing Header Sanitization in fe_http

The fe_http frontend (handling plain HTTP on port 80) performs only the following header operations:

• Strips the Proxy header to prevent HTTPoxy attacks: http-request del-header Proxy
• Lowercases the Host header: http-request set-header Host %[req.hdr(Host),lower]
• Adds or removes user configured custom headers based on route annotations

Critically, it does not include any http-request del-header X-SSL-Client-* directives. This means an attacker can inject arbitrary values for all 11 X-SSL-Client-* headers in a plain HTTP request, and those headers will be forwarded to the backend unmodified.

This is a textbook trust boundary violation. The three frontends share the same backend pool, but only the HTTPS frontends legitimately set X-SSL-Client-* headers. The HTTP frontend's failure to strip these headers creates an asymmetric trust model where backends cannot distinguish between headers originating from an authenticated TLS handshake and headers forged by an unauthenticated HTTP request.

The Role of insecureEdgeTerminationPolicy

The insecureEdgeTerminationPolicy setting on OpenShift Routes determines how HTTP requests are handled:

• None (default): HTTP requests are redirected to HTTPS via a secure_redirect ACL in fe_http. Headers never reach the backend.
• Redirect: HTTP requests are redirected to HTTPS. Headers never reach the backend.
• Allow: HTTP requests are forwarded directly to the backend. Forged headers reach the backend unimpeded.

The vulnerability is exploitable specifically when insecureEdgeTerminationPolicy is set to Allow. In this configuration, the fe_http frontend routes requests via use_backend %[base,map_reg(/var/lib/haproxy/conf/os_http_be.map)], which maps hostnames to HTTP backends. The forged headers pass through to the application without any sanitization.

Attack Flow

An unauthenticated attacker on the network can exploit this vulnerability through the following steps:

1. Identify a target: Locate an OpenShift Route configured with insecureEdgeTerminationPolicy: Allow where the backend relies on X-SSL-Client-* headers for mTLS authentication.

2. Craft the request: Send a plain HTTP request to port 80 of the router, including crafted X-SSL-Client-* headers that impersonate a legitimate client certificate identity. For example, set X-SSL-Client-DN to a trusted distinguished name and X-SSL-Client-Verify to 0 (indicating successful verification).

3. Header passthrough: The fe_http frontend forwards the request with the forged headers to the backend without stripping them.

4. Authentication bypass: The backend, trusting the headers as if they were set by the HTTPS frontend after mTLS validation, accepts the request as authenticated and grants the attacker the privileges of the impersonated identity.

This constitutes a complete mTLS authentication bypass, classified under CWE-287 (Improper Authentication), because the backend cannot distinguish between headers legitimately set after TLS validation and headers forged by an attacker through the HTTP frontend.

Analogy to HTTPoxy

The pattern here is directly analogous to the well known HTTPoxy vulnerability (CVE-2016-5385). The OpenShift Router's fe_http frontend already strips the Proxy header to prevent that class of attack, but it misses the X-SSL-Client-* family entirely. This suggests a systemic gap in the template's header sanitization approach: sanitization is applied selectively per header rather than comprehensively across all trust boundary headers.

CVSS Score Context

The NVD assigned a CVSS base score of 7.4 to this vulnerability. The score reflects:

• Attack Vector: Network (the attacker only needs network access to the OpenShift Router)
• Attack Complexity: Low (no special conditions beyond a misconfigured Route are required)
• Privileges Required: None (the attacker is unauthenticated)
• User Interaction: None (no user action is needed)
• Impact: The attacker can impersonate any client certificate identity, compromising confidentiality and integrity of backend services

Affected Systems and Versions

The vulnerability affects the OpenShift Router component (openshift/router) across OpenShift Container Platform deployments. The specific conditions required for exploitation are:

• The OpenShift Router must be using the HAProxy based ingress controller (the default configuration)
• At least one Route must have insecureEdgeTerminationPolicy set to Allow
• The backend application behind that Route must rely on X-SSL-Client-* headers for mTLS authentication decisions

As of the CVE publication date, no specific version ranges have been enumerated in the Bugzilla entry (which remains in NEW status). The reviewed RHSA advisories (RHSA-2026:17469 for OpenShift 4.20.23 and RHSA-2026:20042 for OpenShift 4.19) do not include a fix for this CVE, indicating these versions remain affected.

Organizations should audit their Route configurations across all OpenShift versions for the insecureEdgeTerminationPolicy: Allow setting.

Mitigation Strategies

Since no official patch has been published as of 2026-05-29, the following workarounds are available:

Change insecureEdgeTerminationPolicy

The most effective immediate mitigation is to change insecureEdgeTerminationPolicy from Allow to None or Redirect on all affected Routes. Setting the policy to None (the default) or Redirect causes the fe_http frontend to redirect HTTP requests to HTTPS, preventing forged X-SSL-Client-* headers from ever reaching the backend. This can be applied per Route without requiring a router restart.

Network Level Restrictions

Restrict access to the OpenShift Router's HTTP port (80) at the network level, ensuring only trusted sources can reach the fe_http frontend. This reduces but does not eliminate the attack surface.

Backend Architecture Changes

Application backends should not trust X-SSL-Client-* headers unless they have independent verification that the request arrived over a properly terminated TLS connection. Relying solely on proxy injected headers for authentication without additional validation is inherently fragile, as this vulnerability demonstrates.

Monitoring for Exploitation Attempts

Organizations should monitor OpenShift Router access logs for HTTP requests (port 80) containing X-SSL-Client-* headers directed at Routes with insecureEdgeTerminationPolicy: Allow. Legitimate clients would not include these headers in plain HTTP requests, so their presence is a strong indicator of exploitation attempts.

Vendor Security History

Red Hat maintains a dedicated Product Security team and publishes security advisories through the Red Hat Errata system. The company uses a four tier severity rating system (Low, Moderate, Important, Critical) and has rated CVE-2026-46579 as Important.

Red Hat has previously addressed significant OpenShift security vulnerabilities, including CVE-2018-1002105 (a privilege escalation flaw in Kubernetes affecting OpenShift) and CVE-2025-10725 (a privilege escalation in OpenShift AI Service). The company provides a comprehensive CVE database with search and filter capabilities through the Red Hat CVE Database.

As of the publication date, the Bugzilla entry for CVE-2026-46579 remains in NEW status with no "Fixed In Version" specified. Organizations should monitor the Red Hat Security Updates page for the forthcoming patch advisory.

Threat Intelligence

As of 2026-05-29, there is no evidence that CVE-2026-46579 is being actively exploited in the wild. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog. The most recent CISA KEV additions (as of 2026-05-27) do not include this CVE.

However, several characteristics make this vulnerability attractive to threat actors:

• Low exploitation complexity: The attack requires only the ability to send HTTP requests with crafted headers, achievable with any standard HTTP client tool
• No authentication required: The attacker needs no credentials or prior access to the OpenShift environment
• High value target: OpenShift is widely deployed in enterprise environments (6,633 verified companies), and mTLS bypass can provide access to sensitive backend services
• Extended exposure window: With no fix version published, the window of vulnerability may be prolonged

Exploitation is constrained by the requirement that a Route must have insecureEdgeTerminationPolicy: Allow and the backend must trust X-SSL-Client-* headers for authentication, which limits the number of potentially affected deployments.

For context, VulnCheck's State of Exploitation 2026 report noted that 28.96% of KEVs identified in 2025 were exploited on or before the day their CVE was published, underscoring the speed at which adversaries can operationalize new vulnerabilities.

References

• NVD: CVE-2026-46579
• Red Hat CVE Entry: CVE-2026-46579
• Bugzilla: 2483181 (CVE-2026-46579)
• OpenShift Router HAProxy Configuration Template (GitHub)
• RHSA-2026:17469 Security Advisory
• RHSA-2026:20042 Security Advisory
• CWE-287: Improper Authentication
• CISA Known Exploited Vulnerabilities Catalog
• Red Hat Security Updates
• Red Hat CVE Database
• OpenShift Container Platform 4.15: Configuring Routes
• OpenShift Container Platform 4.11: Configuring Routes
• VulnCheck State of Exploitation 2026