CVE-2026-42965 + CVE-2026-46579: OpenShift Router double — FQDN EndpointSlice SSRF to cloud metadata + mTLS spoofing via unstripped `X-SSL-Client-*` headers

TL;DR — the 90-second summary

What was published?

Two Red Hat disclosures within two days for the OpenShift Router component (HAProxy-based ingress controller in OCP 4.x). CVE-2026-42965 (30 May, CVSS 7.7): cloud metadata SSRF via FQDN EndpointSlice. A user with EndpointSlice write permission can create a Service whose EndpointSlice points to an FQDN that resolves to 169.254.169.254 (or AWS/Azure/GCP/OCI metadata IPs). Bypasses the existing IP validation layer. CVE-2026-46579 (29 May, CVSS 7.4): mTLS client spoofing via HTTP. On routes with insecureEdgeTerminationPolicy: Allow the HTTP frontend does not strip the X-SSL-Client-* headers. Backends that use those headers for mTLS client identification become spoofable via plain HTTP.

How bad?

Both HIGH. CVE-2026-42965 opens the classic SSRF-to-cloud-credentials path. CVE-2026-46579 makes mTLS-based backend authentication ineffective. Both are bypasses of existing protection layers.

Which OpenShift versions are affected?

Both flaws affect the OpenShift Router component in OCP 4.x; patches roll out via the cluster operator path. For exact affected versions see Red Hat errata pages.

Am I affected?

Directly affected: customers with their own OpenShift platform on which a platform I maintain (TYPO3, Sylius, Symfony Custom) runs as a workload. CVE-2026-42965 hits you concretely if your cluster (a) runs on a public cloud platform with a reachable metadata endpoint and (b) grants any user or service account EndpointSlice write permission. CVE-2026-46579 hits you if (a) a route with insecureEdgeTerminationPolicy: Allow exists and (b) the backend behind that route uses X-SSL-Client-* headers for mTLS client authentication.

Immediate mitigation?

For CVE-2026-42965: inventory EndpointSlice write permissions, set a NetworkPolicy or cluster egress firewall rule blocking router egress to 169.254.169.254/32 and the corresponding cloud metadata IPs (stopgap), lift to the router patch level. For CVE-2026-46579: identify all routes with insecureEdgeTerminationPolicy: Allow, switch to Redirect where possible, in the backend explicitly reject plain-HTTP requests carrying X-SSL-Client-* headers until the patch lands.

Severity?

Hero badge high. Active exploitation as of 30 May is not publicly documented. Cloud-metadata SSRF is one of the best-standardised exploitation classes in the pentest world.

What happened

Within two days, Red Hat published two security advisories for the OpenShift Router component — the HAProxy-based ingress controller that accepts incoming HTTP and HTTPS traffic for routes in every OpenShift cluster and forwards it to the backend services.

CVE-2026-46579 (29 May 2026, CVSS 7.4 HIGH) concerns HTTP frontend header handling. When an OpenShift route sets its insecureEdgeTerminationPolicy to Allow (configuration „plain HTTP is also accepted, no forced redirect to HTTPS“), the HTTP frontend does not strip the X-SSL-Client-* header family from incoming requests. These headers are normally set in the OpenShift Router configuration by the TLS termination layer to inform the backend about the verified client certificate — X-SSL-Client-DN, X-SSL-Client-CN, X-SSL-Client-SHA1. Backends that read these headers and trust them treat a plain-HTTP request with forged X-SSL-Client-* headers as authenticated.

CVE-2026-42965 (30 May 2026, CVSS 7.7 HIGH) concerns the router’s EndpointSlice resolution logic. OpenShift allows Services whose EndpointSlices contain not IP addresses but Fully Qualified Domain Names. Previously the router had a validation layer that checked the resolved IPs against a blocklist (loopback, link-local, cloud metadata). That validation does not apply to FQDN resolution — the router resolves the FQDN at request-routing time and proxies without further IP checking. An attacker with EndpointSlice write permission can create a Service whose EndpointSlice points to an attacker-controlled DNS entry resolving to 169.254.169.254 or an equivalent cloud metadata IP. Classic SSRF-to-cloud-credentials path.

Both patches land via the OpenShift cluster operator path and are rolled out with the next Z-stream updates of the respective 4.x minor versions.

Technical analysis

Structurally both CVEs are bypasses of existing protection layers — not new bug classes, but gaps in existing defence-in-depth positions.

CVE-2026-42965 shows the classic pattern that validation layers must sit exactly where the trust boundary actually runs. The IP address validation in the router was a sensible first line against SSRF. But: the validation ran on static IP values from the EndpointSlice. As soon as the EndpointSlice carries an FQDN resolved only at request time, the validation sits in the wrong place in the pipeline. The correct path is to re-apply the validation after DNS resolution — and that is exactly what the patch adds. Structurally comparable to DNS rebinding bugs.

CVE-2026-46579 shows a different class: header trust boundary shift through a configuration option. insecureEdgeTerminationPolicy: Allow explicitly says „HTTP is also accepted“. What administrators setting this option often do not reflect on: the trust assumptions the router implements on the HTTPS side (X-SSL-Client-* headers are set by the router, not by the client) implicitly continue to hold on the HTTP side. They do not — and that is the bug.

The link between the two CVEs is the router component itself — same HAProxy-based stack, same patch path. Operationally that means one update cycle closes both. The double drop within two days suggests the OpenShift Router code is in an active audit wave in May 2026.

What this means for the Mittelstand

OpenShift is a selective stack in the German Mittelstand — not the default container setup, but a proven platform among customers with higher compliance requirements (BaFin, DORA, KRITIS), their own on-premises data centres or an explicit Red Hat subscription strategy. I operate a number of such setups — typically as a platform layer for TYPO3 or Symfony applications that for compliance reasons should not run on standard hyperscaler Kubernetes. For those customers the double finding is operational.

First class, most broadly relevant: OpenShift on cloud (ROSA on AWS, ARO on Azure, or Red Hat OpenShift Service on GCP). Here the cloud metadata endpoint 169.254.169.254 is reachable from the router pods, and CVE-2026-42965 is directly exploitable. The operational question for you as the operator is: does any user or service account in any namespace have EndpointSlice write permission that is not part of the cluster admin crew?

Second class, narrower: OpenShift on premises (bare-metal or VMware OpenShift). Here the cloud metadata endpoint is normally not reachable. CVE-2026-42965 is less acute but can still be used for other SSRF targets. CVE-2026-46579 affects both classes equally.

On the compliance side both CVEs sit on standard axes. GDPR Art. 32 is touched once a route carries personal data. NIS-2 Art. 21 demands supply-chain discipline. DORA Art. 9 (for affected financial services entities) explicitly requires „appropriate security measures for ICT systems“ — in a DORA audit trail an unhandled cloud-metadata SSRF flaw is a finding with escalation pressure.

What this means for technical development

Architecturally both CVEs force three disciplines that count as „known“ in the Kubernetes/OpenShift world and in practice are often booked as „settled“.

First, egress filtering is not optional. Every container cluster on a public cloud platform should have a cluster-wide NetworkPolicy or equivalent egress restriction that blocks the cloud metadata endpoint from all workload pods and router pods. Anyone without this is defenceless against the whole class of „SSRF to IMDS“ — of which CVE-2026-42965 is only one representative.

Second, header trust boundaries belong explicitly documented. Which headers are set by the router? Which may come from the client? The answer depends on the concrete router configuration — and it changes under insecureEdgeTerminationPolicy: Allow. Symfony/Sylius/PHP backends that read X-SSL-Client-* headers for auth logic should have an explicit check whether the request came over HTTPS or HTTP — and in the HTTP case discard the headers.

Third, RBAC inventory as a continuous process. EndpointSlice write permission sounds like a harmless operator permission, but — as CVE-2026-42965 shows — it is an SSRF entry permission once the cluster runs on a cloud platform with a reachable metadata endpoint. Open Policy Agent or Kyverno as a policy layer can automate this, but they do not replace the once-yearly audit.

Concrete recommendation

In this order. First, inventory today: per OpenShift cluster (a) check whether the cluster runs on a cloud platform with a reachable metadata endpoint, (b) via oc get rolebindings,clusterrolebindings -A -o yaml list all bindings that carry EndpointSlice permission, (c) via oc get routes -A -o json | jq '.items[] | select(.spec.tls.insecureEdgeTerminationPolicy=="Allow")' identify all routes with the risky TLS policy state. Second, stopgap for CVE-2026-42965: set a NetworkPolicy or cluster egress firewall rule that blocks router egress to 169.254.169.254/32, fd00:ec2::254/128 (IPv6 IMDS AWS), 169.254.169.254 (Azure IMDS), metadata.google.internal (GCP), 169.254.169.254 (OCI). Third, stopgap for CVE-2026-46579: switch routes with insecureEdgeTerminationPolicy: Allow to Redirect or fully TLS-only; in the backend code only accept X-SSL-Client-* headers when the request scheme is HTTPS. Fourth, Z-stream update to the router patch: check cluster update channel, plan the Z-stream update. Fifth, audit log sweep: in the OpenShift audit logs of the last 30 days check whether EndpointSlice create calls with FQDN content showed up that did not come from the platform crew.

If these steps do not run from your own capacity, talk to me: I deliver OpenShift platforms in which egress filtering, RBAC audit and route TLS policy run as a continuous process.

This post reflects my technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• OpenCVE — CVE-2026-42965: OpenShift Router Cloud Metadata SSRF via FQDN-typed EndpointSlice (30 May 2026)
• OpenCVE — CVE-2026-46579: OpenShift Router mTLS Client Certificate Spoofing via Unstripped X-SSL-Client Headers (29 May 2026)
• Red Hat Customer Portal — CVE-2026-42965 (as of 30 May 2026)
• Red Hat Customer Portal — CVE-2026-46579 (as of 30 May 2026)