Kubeflow-Sicherheitslücke: Angreifer stehlen Zugriffstokens

Eine kritische Schwachstelle in Kubeflow erlaubt Token-Diebstahl und Kontrollübernahme. Angreifer können auf sensible KI-Daten zugreifen.

Eine kritische Schwachstelle in Kubeflow gefährdet KI-Workflows und sensible Modelle.

Sicherheitsforscher haben eine schwerwiegende Lücke in der beliebten Open-Source-Plattform Kubeflow aufgedeckt. Die als CVE-2026-47237 registrierte Schwachstelle erlaubt Angreifern mit eingeschränkten Zugriffsrechten, die Authentifizierungstokens anderer Nutzer zu stehlen. Das könnte im schlimmsten Fall zur vollständigen Übernahme von Konten und zum unbefugten Zugriff auf sensible Trainingsdaten und KI-Modelle führen.

Anzeige

Der Schutz sensibler KI-Modelle und Trainingsdaten wird angesichts neuer Bedrohungen immer komplexer. Dieser kostenlose Report klärt auf, welche rechtlichen Pflichten und Bedrohungen Unternehmer jetzt kennen müssen, um ihre Infrastruktur langfristig abzusichern. Neue KI-Gesetze und Cyberrisiken jetzt entdecken

Die Istio-Berechtigungslücke

Das Problem liegt in der Istio Service Mesh-Konfiguration, die Kubeflow zur Steuerung des Netzwerkverkehrs zwischen seinen Komponenten nutzt. Die Sicherheitsexperten von ERNW, die das Problem bereits im März 2025 an das Kubeflow-Projekt meldeten, entdeckten, dass die Standardrolle kubeflow-edit übermäßige Berechtigungen innerhalb der Istio-API-Gruppe networking.istio.io vergab.

Eine technische Analyse vom 20. Mai 2026 zeigt: Diese Berechtigungen ermöglichen es Angreifern, die Anfragen und Antworten zu manipulieren, die durch das zentrale Kubeflow-Gateway geleitet werden. Durch Ausnutzung dieser Fehlkonfiguration können sie die Zugriffstokens jedes Nutzers abfangen, der mit der Kubeflow-Oberfläche oder den zugehörigen APIs interagiert – darunter Dashboard, Pipelines und Jupyter Notebooks.

Besonders brisant: Der Zeitplan der Offenlegung. Zwar wurde ein Fix bereits am 8. März 2025 über Pull Request #3043 im GitHub-Repository implementiert, doch eine offizielle CVE-Kennung wurde erst am 2. März 2026 beantragt. Die Veröffentlichung in der globalen CVE-Datenbank erfolgte schließlich am 19. Mai 2026. Das bedeutet eine erhebliche Zeitspanne zwischen dem ersten Patch und der formalen Anerkennung des Risikos für die breite Nutzerbasis.

Angriffsvoraussetzungen und technische Auswirkungen

Für einen erfolgreichen Angriff müssen bestimmte Bedingungen erfüllt sein. Die Forscher betonen: Der Angreifer benötigt ein gültiges Konto mit mindestens der Rolle „Contributor" oder kubeflow-edit in einem beliebigen Namespace. In Unternehmensumgebungen ist diese Voraussetzung häufig erfüllt, wenn die „Automatic Profile Creation" aktiviert ist – eine Funktion, die neuen authentifizierten Nutzern automatisch einen Namespace und die nötigen Rollen zuweist.

Hat der Angreifer erst einmal diese Position erreicht, kann er die vollständige Kontrolle über das kubeflow-gateway übernehmen. Die Hauptgefahr: die Offenlegung von JSON Web Tokens (JWT) anderer Nutzer. Da diese Tokens die Identität des Nutzers im Cluster repräsentieren, kann ein Angreifer mit einem gestohlenen Token:

• Das Opfer in allen Kubeflow-Diensten impersonieren
• Sensitive KI-Modelle einsehen, verändern oder löschen
• Daten abfangen, die in nutzerspezifischen Pipelines verarbeitet werden
• Berechtigungen ausweiten, indem er das Token eines Nutzers mit der Rolle „Owner" stiehlt

Technische Demonstrationen Mitte Mai 2026 zeigten: Selbst wenn ein Angreifer zunächst nicht die Berechtigung hat, Opfer zu einem kontrollierten Namespace hinzuzufügen, kann er ein gestohlenes „Owner"-Token nutzen, um die Umgebung zu manipulieren und den Umfang des Kompromisses zu erweitern.

Betroffene Plattformen und Gegenmaßnahmen

Die Schwachstelle betrifft alle Kubeflow-Installationen, die auf den offiziellen Manifests vor Version 1.10 basieren. Aufgrund der modularen Architektur der Plattform gelten auch mehrere große Cloud-basierte Distributionen als wahrscheinlich verwundbar:

• Google Kubernetes Engine (GKE) (Version 1.8 und älter)
• Azure Kubernetes Service (AKS) (Version 1.7 und älter)
• Charmed Kubeflow von Canonical (Version 1.8)
• IBM Cloud Kubernetes Service (IKS)
• Red Hat Open Data Hub (Version 1.9)
• Nutanix und VMware vSphere Machine-Learning-Erweiterungen

Administratoren sollten ihre Kubeflow-Manifeste umgehend auf die neueste Version aktualisieren. Der Patch entfernt die übermäßigen Istio-Bearbeitungsberechtigungen aus den Standardnutzerrollen. Organisationen, die kein sofortiges Upgrade durchführen können, sollten ihre Istio-RBAC-Einstellungen (Role-Based Access Control) manuell überprüfen und sicherstellen, dass die API-Gruppe networking.istio.io für allgemeine Mitwirkende nicht zugänglich ist.

Die Identitätskrise in MLOps

Die Offenlegung von CVE-2026-47237 reiht sich ein in einen besorgniserregenden Trend: die zunehmenden Angriffe auf nicht-menschliche Identitäten und Service-Account-Tokens in Cloud-nativen Umgebungen. Ein Bericht von Palo Alto Networks' Unit 42 vom 20. April 2026 zeigt: Die Zahl der Kubernetes-basierten Angriffsversuche stieg im vergangenen Jahr um 282 Prozent. Die Studie ergab, dass 2025 rund 22 Prozent aller Cloud-Umgebungen verdächtige Aktivitäten im Zusammenhang mit Token-Diebstahl aufwiesen.

Dieser Trend wird durch weitere aktuelle Erkenntnisse im Bereich der KI-Infrastruktur untermauert. Bereits Anfang 2026 wiesen Forscher auf CVE-2025-49008 hin – eine separate Argument-Injection-Schwachstelle in einer Kubeflow-Komponente, die ebenfalls den Diebstahl von Service-Account-Tokens ermöglichte. Zudem hat die US-amerikanische Cybersicherheitsbehörde CISA am 22. Mai 2026 eine ähnliche Token-exponierende Schwachstelle in Langflow (CVE-2025-34291) in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen und verwies auf aktive Ausbeutung durch staatlich unterstützte Akteure.

Eine Analyse von GitGuardian Ende März 2026 deutet darauf hin, dass die „Secrets Sprawl" in KI-gesteuerten Workflows der Haupttreiber dieser Vorfälle ist. Ihre Forschung entdeckte über 28 Millionen neue hartcodierte Secrets in öffentlichen Commits während des Jahres 2025 – viele davon blieben Jahre nach ihrer ersten Offenlegung gültig.

Anzeige

Da die EU-KI-Verordnung bereits unmittelbar gilt, müssen Unternehmen bei der Nutzung von KI-Systemen nun strenge Anforderungen an Kennzeichnung und Dokumentation erfüllen. Ein kostenloser Umsetzungsleitfaden verschafft Ihnen den nötigen Überblick über alle relevanten Fristen und Pflichten. EU AI Act Umsetzungsleitfaden kostenlos herunterladen

Strategischer Ausblick für KI-Sicherheit

Das wiederkehrende Muster dieser Offenlegungen: KI- und MLOps-Plattformen priorisieren oft Benutzerfreundlichkeit und schnelle Bereitstellung über strenge Sicherheitsgrenzen. Experten, die Anfang 2026 auf der Sicherheitskonferenz TROOPERS26 sprachen, betonten, dass die „Berechtigungslücke" zwischen dem, was ein KI-Agent oder ein Data Scientist benötigt, und dem, was ihnen tatsächlich gewährt wird, ein kritischer Schwachpunkt bleibt.

Während Organisationen auf Kubeflow Version 1.10 und darüber hinaus umsteigen, verschiebt sich der Fokus hin zu einer Zero-Trust-Architektur für maschinelles Lernen. Dazu gehören die Implementierung von Continuous Access Evaluation (CAE), das Zugriffstokens in Echtzeit widerrufen kann, wenn eine IP-Adressänderung erkannt wird, sowie die Einführung externer Secrets-Manager, um sensible Zugangsdaten aus dem Kubernetes-Cluster selbst zu entfernen.

Für den restlichen Teil des Jahres 2026 ist mit zunehmendem regulatorischen Druck zu rechnen. Die schrittweise Umsetzung des EU AI Act, der im Laufe des Jahres neue Transparenz- und Risikomanagementanforderungen in Kraft setzt, wird viele Organisationen zu tiefgreifenden Audits ihrer MLOps-Stacks zwingen. Sicherheitsforscher erwarten, dass mit der anhaltenden „Identitätskrise" maschineller Identitäten weitere Schwachstellen im Zusammenhang mit Token-Handling und Cross-Namespace-Isolation ans Licht kommen werden – regelmäßige Manifest-Updates werden damit zu einem kritischen Bestandteil der Unternehmens-KI-Strategie.