⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

🏥 Krankenhaus🏨 Fachklinik🏃 Rehaklinik🏡 Pflegeheim🔬 Labor🏢 Ambulantes Zentrum

Bereich

IT-InfrastrukturCloud-DiensteLIS / RIS / PACS
Beschreibung

In Kubeflow Pipelines vor Version 2.17.0 besteht eine nicht authentifizierte Server-Side Request Forgery (SSRF)-Schwachstelle im Frontend-Proxy-Endpunkt /_proxy/. Die Funktion _routePathWithReferer() leitet beliebige, vom Angreifer kontrollierte HTTP/HTTPS-Ziele ohne Host-Allowlist oder Filterung interner Adressbereiche (Loopback, RFC1918, Cluster-lokal) weiter, sodass ein nicht authentifizierter Angreifer interne Dienste im Kubernetes-Cluster oder im lokalen Netzwerk ansprechen und potenziell sensible Daten auslesen kann. Kubeflow Pipelines wird im Gesundheitswesen zunehmend für KI- und ML-gestützte Analyseworkflows eingesetzt, etwa zur Bildauswertung in der Radiologie oder zur Labordiagnostik, und ist dabei oft in dasselbe Netzwerksegment wie kritische Systeme (PACS, KIS, LIS) integriert. Der kritische CVSS-Score von 10.0 und der fehlende Authentifizierungsschutz machen eine sofortige Aktualisierung auf Version 2.17.0 sowie ergänzende Netzwerksegmentierung zwingend erforderlich.

Handlungsempfehlung

1 Kubeflow Pipelines auf Version 2.17.0 oder höher aktualisieren, da erst ab dieser Version die SSRF-Schwachstelle im /_proxy/-Endpunkt durch eine Host-Allowlist und Filterung interner Adressen behoben ist.

2. Bis zum Patch-Einspielen den /_proxy/-Endpunkt auf Netzwerkebene (Firewall, Ingress-Controller) sperren oder den Zugriff auf authentifizierte Nutzer beschränken.

3. Prüfen, ob Kubeflow Pipelines in der eigenen Umgebung mit aktiviertem ENABLE_AUTH-Flag betrieben wird; falls nicht, Authentifizierungsmiddleware unverzüglich aktivieren.

4. Netzwerkegress der Kubeflow-Pods auf zugelassene externe Ziele einschränken (NetworkPolicy), um SSRF-Angriffe auf interne Cluster-Dienste und RFC1918-Adressen zu erschweren.

5. Logs des Kubeflow-Frontend-Services auf ungewöhnliche Anfragen an interne IP-Bereiche oder Cluster-lokale Adressen untersuchen, um mögliche Ausnutzung zu erkennen.

🔒

Weitere konkrete Handlungsschritte für Ihre IT-Abteilung
sind ISMShield AI Kunden vorbehalten.

Jetzt freischalten →
Regulatorische Einordnung

NIS2-Relevanz: •••    B3S: •••    ISG: ••ˆ    Meldepflicht DE: ja

🔒

Regulatorische Einordnung (NIS2, B3S, ISG, nDSG)
nur für ISMShield AI Kunden.

Details freischalten →