CVE-2026-46579

Vulnerability

A flaw exists in the OpenShift Router's HAProxy configuration template, where the HTTP frontend (fe_http) does not remove X-SSL-Client-* headers (including DN, DER, NotAfter, NotBefore, SHA1, Subject) from incoming requests. When a Route has insecureEdgeTerminationPolicy set to Allow, these headers are forwarded unmodified to backend services. The HTTPS frontends (fe_sni, fe_no_sni) correctly set these headers based on the actual TLS handshake, but the HTTP frontend lacks stripping logic. This affects all OpenShift versions using the default router configuration with HAProxy [1][2].

Exploitation

An unauthenticated attacker with network access to an OpenShift Route configured with insecureEdgeTerminationPolicy: Allow can send a plain HTTP request containing crafted X-SSL-Client-* headers (e.g., X-SSL-Client-DN, X-SSL-Client-SHA1). The router forwards these headers to the backend application unmodified, as it does not validate or strip them on the HTTP frontend. No user interaction or elevated privileges are required beyond the ability to send HTTP requests to the exposed route [2].

Impact

Successful exploitation allows the attacker to impersonate any client certificate identity by forging the X-SSL-Client-* headers to match a legitimate client certificate. Backend applications that rely on these headers for mutual TLS authentication will accept the forged identity, effectively bypassing client certificate validation. This can lead to unauthorized access to protected resources, privilege escalation, or data disclosure depending on the backend's trust model [1][2].

Mitigation

Red Hat released a fix in OpenShift Container Platform 4.17.10, 4.16.17, and 4.15.28 on 2026-05-29. Administrators should update to the latest patched release. As a workaround, until the patch is applied, routes with insecureEdgeTerminationPolicy: Allow should be migrated to use edge or re-encrypt termination, or the backend application must independently authenticate clients (e.g., via session tokens) rather than relying solely on X-SSL-Client-* headers [1][2].