CVE-2026-42965 + CVE-2026-46579: OpenShift-Router-Doppel — FQDN-EndpointSlice-SSRF zu Cloud-Metadata + mTLS-Spoofing über ungestrippte `X-SSL-Client-*`-Header

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

Zwei Red-Hat-Disclosures innerhalb von zwei Tagen für die OpenShift-Router-Komponente (HAProxy-basierter Ingress-Controller in OCP 4.x). CVE-2026-42965 (30.05., CVSS 7.7): Cloud-Metadata-SSRF über FQDN-EndpointSlice. Ein Benutzer mit EndpointSlice-Write-Permission kann einen Service anlegen, dessen EndpointSlice auf einen FQDN zeigt, der zu 169.254.169.254 (oder AWS/Azure/GCP/OCI-Metadata-IPs) auflöst. Bypass der bisherigen IP-Validierungs-Schicht. CVE-2026-46579 (29.05., CVSS 7.4): mTLS-Client-Spoofing über HTTP. Bei Routen mit insecureEdgeTerminationPolicy: Allow entfernt das HTTP-Frontend die X-SSL-Client-*-Header nicht. Backends, die diese Header für mTLS-Client-Identifikation nutzen, werden über Plain-HTTP gefälscht authentifizierbar.

Wie schwer?

Beide HIGH. CVE-2026-42965 öffnet den klassischen SSRF-zu-Cloud-Credentials-Pfad. CVE-2026-46579 macht mTLS-basierte Backend-Authentication wirkungslos. Beide sind Bypass vorhandener Schutzschichten.

Welche OpenShift-Versionen sind betroffen?

Beide Lücken betreffen die OpenShift-Router-Komponente in OCP 4.x; Patch-Stände werden über die Cluster-Operator-Pflege ausgerollt. Für exakte betroffene Versionen siehe Red-Hat-Errata-Seiten (RHSA-Nummern erscheinen innerhalb weniger Tage nach Disclosure).

Bin ich als Moselwal-Kunde betroffen?

Direkt betroffen sind Mandanten mit eigener OpenShift-Plattform, auf der eine der Moselwal-Plattformen (TYPO3, Sylius, Symfony-Custom) als Workload läuft. Das ist im DACH-Mittelstand eine kleinere, aber stabile Gruppe. CVE-2026-42965 trifft Sie konkret, wenn Ihre Cluster (a) auf einer Public-Cloud-Plattform mit erreichbarem Metadata-Endpoint laufen und (b) Benutzern oder Service-Accounts EndpointSlice-Write-Permission geben. CVE-2026-46579 trifft Sie, wenn (a) eine Route mit insecureEdgeTerminationPolicy: Allow existiert und (b) das Backend hinter dieser Route mTLS-Client-Authentication über die X-SSL-Client-*-Header-Familie umsetzt.

Sofort-Mitigation?

Für CVE-2026-42965: EndpointSlice-Write-Permission inventarisieren, NetworkPolicy oder Cluster-Egress-Firewall-Regel setzen, die Router-Egress zu 169.254.169.254/32 und entsprechenden Cloud-Metadata-IPs blockiert (Stopgap), auf den Router-Patch heben. Für CVE-2026-46579: alle Routen mit insecureEdgeTerminationPolicy: Allow identifizieren, soweit möglich auf Redirect umstellen, im Backend Plain-HTTP-Requests mit X-SSL-Client-*-Headern explizit ablehnen, bis der Patch greift.

Kritikalität?

Hero-Badge high. Aktive Ausnutzung Stand 30.05. nicht öffentlich dokumentiert. Cloud-Metadata-SSRF ist in der Pentest-Welt eine der am besten standardisierten Exploit-Klassen.

Was ist passiert

Innerhalb von zwei Tagen hat Red Hat zwei Sicherheitsmeldungen für die OpenShift-Router-Komponente disclosed — den HAProxy-basierten Ingress-Controller, der in jedem OpenShift-Cluster den eingehenden HTTP- und HTTPS-Verkehr für Routen entgegennimmt und an die Backend-Services weiterleitet.

CVE-2026-46579 (29.05.2026, CVSS 7.4 High) betrifft die HTTP-Frontend-Header-Behandlung. Wenn eine OpenShift-Route ihre insecureEdgeTerminationPolicy auf Allow setzt (die Konfiguration „auch Plain-HTTP wird durchgereicht, kein erzwungener Redirect auf HTTPS“), entfernt das HTTP-Frontend die X-SSL-Client-*-Header-Familie nicht aus eingehenden Requests. Diese Header werden in der OpenShift-Router-Konfiguration normalerweise vom TLS-Termination-Layer gesetzt, um dem Backend Information über das verifizierte Client-Zertifikat mitzugeben — X-SSL-Client-DN, X-SSL-Client-CN, X-SSL-Client-SHA1. Backends, die diese Header lesen und ihnen vertrauen, behandeln einen Plain-HTTP-Request mit gefälschten X-SSL-Client-*-Headern als authentifiziert.

CVE-2026-42965 (30.05.2026, CVSS 7.7 High) betrifft die EndpointSlice-Auflösungs-Logik des Routers. OpenShift erlaubt Services, deren EndpointSlices nicht IP-Adressen, sondern Fully Qualified Domain Names enthalten. Bisher hatte der Router eine Validierungs-Schicht, die die aufgelösten IPs gegen eine Blocklist (Loopback, Link-Local, Cloud-Metadata) prüfte. Diese Validierung greift auf der FQDN-Auflösung nicht — der Router löst den FQDN beim Request-Routing auf und proxy't ohne weitere IP-Prüfung. Ein Angreifer mit EndpointSlice-Write-Permission kann einen Service anlegen, dessen EndpointSlice auf einen vom Angreifer kontrollierten DNS-Eintrag zeigt, der zu 169.254.169.254 oder einer äquivalenten Cloud-Metadata-IP auflöst. Klassischer SSRF-zu-Cloud-Credentials-Pfad.

Beide Patches landen über den OpenShift-Cluster-Operator-Pfad und werden mit den nächsten Z-Stream-Updates der jeweiligen 4.x-Minor-Versionen ausgerollt.

Technische Einordnung

Strukturell sind beide CVEs Bypass vorhandener Schutzschichten — keine neuen Bug-Klassen, sondern Lücken in bestehenden Defense-in-Depth-Lagen.

CVE-2026-42965 zeigt das klassische Pattern, dass Validierungs-Schichten an genau der Stelle greifen müssen, wo die Trust-Boundary tatsächlich verläuft. Die IP-Address-Validierung im Router war eine sinnvolle erste Linie gegen SSRF. Aber: die Validierung lief auf statischen IP-Werten aus dem EndpointSlice. Sobald der EndpointSlice einen FQDN trägt, der erst zur Request-Zeit aufgelöst wird, sitzt die Validierung an der falschen Stelle in der Pipeline. Der korrekte Pfad ist, die Validierung nach der DNS-Auflösung erneut anzuwenden — und genau das fügt der Patch ein. Strukturell vergleichbar mit DNS-Rebinding-Bugs.

CVE-2026-46579 zeigt eine andere Klasse: Header-Trust-Boundary-Verschiebung durch eine Konfigurationsoption. insecureEdgeTerminationPolicy: Allow ist eine Konfiguration, die explizit „auch HTTP wird angenommen“ sagt. Was Administratoren beim Setzen dieser Option oft nicht reflektieren: die Trust-Annahmen, die der Router auf der HTTPS-Seite implementiert (X-SSL-Client-*-Header werden vom Router gesetzt, nicht vom Client), gelten implizit auch auf der HTTP-Seite weiter. Sie tun es bisher nicht — und genau das ist der Bug.

Die Verbindung zwischen den beiden CVEs ist die Router-Komponente selbst — derselbe HAProxy-basierte Stack, derselbe Patch-Pfad. Operativ bedeutet das: ein Update-Zyklus schließt beide. Der Doppel-Drop in zwei Tagen zeigt, dass der OpenShift-Router-Code im Mai 2026 in einer aktiven Audit-Welle steht.

Bedeutung für den Mittelstand

OpenShift ist im DACH-Mittelstand ein selektiver Stack — nicht das Standard-Container-Setup, aber bei Mandanten mit höheren Compliance-Anforderungen (BaFin, DORA, KRITIS), eigenen On-Premises-Rechenzentren oder einer expliziten Red-Hat-Subscription-Strategie eine bewährte Plattform. Moselwal betreibt einige solche Setups — typischerweise als Plattform-Layer für TYPO3- oder Symfony-Anwendungen, die aus Compliance-Gründen nicht auf Standard-Hyperscaler-Kubernetes laufen sollen. Für diese Mandanten ist die heutige Doppel-Lage operativ.

Erste Klasse, am breitesten relevant: OpenShift-on-Cloud (ROSA auf AWS, ARO auf Azure, oder Red Hat OpenShift Service on GCP). Hier ist der Cloud-Metadata-Endpoint 169.254.169.254 aus den Router-Pods erreichbar, und CVE-2026-42965 ist direkt ausnutzbar. Die operative Frage für Sie als Betreiber lautet: gibt es in irgendeinem Namespace einen Benutzer oder Service-Account mit EndpointSlice-Write-Permission, der nicht zur Cluster-Admin-Crew gehört?

Zweite Klasse, schmaler: OpenShift-on-Premises (Bare-Metal- oder VMware-OpenShift). Hier ist der Cloud-Metadata-Endpoint normalerweise nicht erreichbar. CVE-2026-42965 ist weniger akut, kann aber für andere SSRF-Ziele (interne Admin-APIs, Kubernetes-API-Server-Endpoint) genutzt werden. CVE-2026-46579 trifft beide Klassen gleichermaßen.

Compliance-seitig sitzen beide CVEs auf den Standard-Achsen. DSGVO Art. 32 ist betroffen, sobald eine Route Personenbezugsdaten überträgt. NIS-2 Art. 21 fordert für die betroffenen Sektoren Lieferketten-Disziplin. DORA Art. 9 (für betroffene Finanzdienstleister) verlangt explizit „angemessene Sicherheits-Maßnahmen für IKT-Systeme“ — und in einer DORA-Auditfähigkeit-Spur ist eine unbehandelte Cloud-Metadata-SSRF-Lücke ein Befund mit Eskalations-Druck.

Bedeutung für die technische Entwicklung

Architektonisch zwingen die beiden CVEs zu drei Disziplinen, die in der Kubernetes-/OpenShift-Welt als „bekannt“ gelten und in der Praxis oft als „erledigt“ verbucht werden.

Erstens, Egress-Filtering ist nicht optional. Jeder Container-Cluster auf einer Public-Cloud-Plattform sollte eine Cluster-weite NetworkPolicy oder eine vergleichbare Egress-Restriktion haben, die den Cloud-Metadata-Endpoint aus allen Workload-Pods und Router-Pods blockiert. Wer das nicht hat, ist gegen die ganze Klasse „SSRF-zu-IMDS“ — von der CVE-2026-42965 nur ein Vertreter ist — schutzlos.

Zweitens, Header-Trust-Boundaries gehören explizit dokumentiert. Welche Header werden vom Router gesetzt? Welche dürfen vom Client kommen? Die Antwort hängt von der konkreten Router-Konfiguration ab — und sie ändert sich bei insecureEdgeTerminationPolicy: Allow. Symfony-/Sylius-/PHP-Backends, die X-SSL-Client-*-Header für Auth-Logik lesen, sollten einen expliziten Check haben, ob der Request über HTTPS oder HTTP kam — und im HTTP-Fall die Header verwerfen.

Drittens, RBAC-Inventur als laufender Prozess. EndpointSlice-Write-Permission klingt nach einer harmlosen Operator-Permission, ist aber — wie CVE-2026-42965 zeigt — eine SSRF-Eintritts-Permission, sobald der Cluster auf einer Cloud-Plattform mit erreichbarem Metadata-Endpoint läuft. Open-Policy-Agent oder Kyverno als Policy-Layer können das automatisieren, aber sie ersetzen den einmal-jährlichen Audit nicht.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, Inventur heute: pro OpenShift-Cluster (a) prüfen, ob die Cluster auf einer Cloud-Plattform mit erreichbarem Metadata-Endpoint laufen, (b) per oc get rolebindings,clusterrolebindings -A -o yaml alle Bindings auflisten, die EndpointSlice-Permission tragen, (c) per oc get routes -A -o json | jq '.items[] | select(.spec.tls.insecureEdgeTerminationPolicy=="Allow")' alle Routen mit dem riskanten TLS-Policy-Stand identifizieren. Zweitens, Stopgap für CVE-2026-42965: NetworkPolicy oder Cluster-Egress-Firewall-Regel setzen, die Router-Egress zu 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) blockiert. Drittens, Stopgap für CVE-2026-46579: Routen mit insecureEdgeTerminationPolicy: Allow auf Redirect umstellen oder ganz auf TLS-only; im Backend Code die X-SSL-Client-*-Header explizit nur akzeptieren, wenn Request-Scheme HTTPS ist. Viertens, Z-Stream-Update auf den Router-Patch: Cluster-Update-Channel prüfen, Z-Stream-Update einplanen. Fünftens, Audit-Log-Sweep: in den OpenShift-Audit-Logs der letzten 30 Tage prüfen, ob EndpointSlice-Create-Calls mit FQDN-Inhalt aufgetaucht sind, die nicht von der Plattform-Crew stammen.

Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal richtet OpenShift-Plattformen, in denen Egress-Filtering, RBAC-Audit und Route-TLS-Politik als laufender Prozess geführt werden.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• OpenCVE — CVE-2026-42965: OpenShift Router Cloud Metadata SSRF via FQDN-typed EndpointSlice (30.05.2026)
• OpenCVE — CVE-2026-46579: OpenShift Router mTLS Client Certificate Spoofing via Unstripped X-SSL-Client Headers (29.05.2026)
• Red Hat Customer Portal — CVE-2026-42965 Detail-Seite (Stand 30.05.2026)
• Red Hat Customer Portal — CVE-2026-46579 Detail-Seite (Stand 30.05.2026)