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

Introduction

An unpatched flaw in the OpenShift Router lets unauthenticated attackers completely bypass mutual TLS authentication by injecting forged X-SSL-Client-* headers through the plain HTTP frontend. Thousands of enterprises run OpenShift in production. In any of those deployments, a Route configured with insecureEdgeTerminationPolicy: Allow whose backend trusts 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 reverse proxy, configured through a Go template file (haproxy-config.template). The template defines three frontends, and each handles inbound traffic differently:

The HTTPS frontends (fe_sni and fe_no_sni) inject the following headers with 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 values come from the TLS handshake itself, so they are trustworthy when the HTTPS frontends set them. 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 (plain HTTP on port 80) performs only these 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

It has no http-request del-header X-SSL-Client-* directives at all. An attacker can put arbitrary values in all 11 X-SSL-Client-* headers of a plain HTTP request, and the router forwards those headers 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. Because the HTTP frontend leaves these headers in place, the result is an asymmetric trust model in which backends cannot tell headers from an authenticated TLS handshake apart from headers forged in 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 that 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 reach the application with no sanitization.

Attack Flow

An unauthenticated attacker on the network can exploit this vulnerability as follows:

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

2. Send a plain HTTP request to port 80 of the router, with 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 (which indicates successful verification).

3. The fe_http frontend forwards the request to the backend with the forged headers intact.

4. The backend trusts the headers as if the HTTPS frontend had set them after mTLS validation. It accepts the request as authenticated and grants the attacker the privileges of the impersonated identity.

The result is a complete mTLS authentication bypass. It is classified under CWE-287 (Improper Authentication) because the backend cannot tell headers legitimately set after TLS validation from headers an attacker forged through the HTTP frontend.

Analogy to HTTPoxy

The pattern 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 how the template sanitizes headers. It handles them selectively, one header at a time, instead of covering every header that crosses a trust boundary.

CVSS Score Context

The NVD assigned this vulnerability a CVSS base score of 7.4. 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, which compromises the confidentiality and integrity of backend services

Affected Systems and Versions

The vulnerability affects the OpenShift Router component (openshift/router) across OpenShift Container Platform deployments. Exploitation requires these conditions:

• 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, the Bugzilla entry (still in NEW status) lists no specific version ranges. The RHSA advisories we reviewed (RHSA-2026:17469 for OpenShift 4.20.23 and RHSA-2026:20042 for OpenShift 4.19) do not include a fix for this CVE, which indicates these versions remain affected.

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

Mitigation Strategies

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 every affected Route. With the policy set to None (the default) or Redirect, the fe_http frontend redirects HTTP requests to HTTPS, so forged X-SSL-Client-* headers never reach the backend. You can apply the change per Route, and the router does not need a restart.

Network-Level Restrictions

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

Backend Architecture Changes

Application backends should not trust X-SSL-Client-* headers unless they can independently verify that the request arrived over a properly terminated TLS connection. Relying only on proxy-injected headers for authentication, with no 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) that carry X-SSL-Client-* headers and target 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 has 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 serious 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). Its Red Hat CVE Database can be searched and filtered.

As of the publication date, the Bugzilla entry for CVE-2026-46579 is still in NEW status, with no "Fixed In Version" specified. Organizations should watch 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, and the most recent CISA KEV additions (as of 2026-05-27) do not include it.

Several characteristics still make this vulnerability attractive to threat actors:

• The attack requires only the ability to send HTTP requests with crafted headers, which any standard HTTP client tool can do
• The attacker needs no credentials or prior access to the OpenShift environment
• OpenShift is widely deployed in enterprise environments (6,633 verified companies), and an mTLS bypass can provide access to sensitive backend services
• No fix version has been published, so the window of exposure may be prolonged

Two requirements limit how many deployments could be affected: a Route must have insecureEdgeTerminationPolicy: Allow, and its backend must trust X-SSL-Client-* headers for authentication.

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. That figure shows how quickly adversaries can operationalize a new vulnerability.

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