Eine neu offengelegte Sicherheitslücke in Red Hat OpenShift AI könnte es Nutzern mit geringen Berechtigungen ermöglichen, ihre Privilegien zu eskalieren und die vollständige Kontrolle über die Hybrid-Cloud-Infrastruktur zu übernehmen.
Die Schwachstelle erhielt einen nahezu maximalen CVSS-Score von 9,9, was ihre Schwere für Unternehmen unterstreicht, die OpenShift AI zum Ausführen prädiktiver und generativer KI-Workloads einsetzen.
„Ein Angreifer mit geringen Berechtigungen und Zugriff auf ein authentifiziertes Konto, etwa ein Data Scientist, der ein Jupyter-Notebook verwendet, kann seine Privilegien bis zum vollständigen Clusteradministrator eskalieren“, erklärte das Unternehmen.
KI-Workloads könnten kompromittiert werden
OpenShift AI wird weithin eingesetzt, um den Lebenszyklus von Machine-Learning-Modellen in Hybrid-Cloud-Umgebungen zu verwalten.
Die betroffenen Versionen – OpenShift AI 2.19 und 2.21 sowie die Images des Red Hat OpenShift AI Operator – sind für Unternehmen, die KI-Pipelines im großen Maßstab bereitstellen, von zentraler Bedeutung.
Die Ausnutzung dieser Sicherheitslücke (CVE-2025-10725) könnte es Angreifern ermöglichen, sensible Daten zu stehlen, Workloads zu stören und die zugrunde liegende Infrastruktur zu kompromittieren, wodurch sensible Daten und kritische Abläufe gefährdet werden.
Geringe Berechtigungen, vollständige Übernahme: Ein Blick auf CVE-2025-10725
Im Kern von CVE-2025-10725 steht eine falsch konfigurierte ClusterRoleBinding, die die kueue-batch-user-role an die weit gefasste system:authenticatedGruppe bindet. Dieses Designversäumnis gewährt im Wesentlichen jedem authentifizierten Nutzer im Cluster erweiterte Berechtigungen, anstatt sie auf eng definierte Rollen zu beschränken.
In der Praxis sollten die meisten Nutzer – etwa Data Scientists, die Experimente in Jupyter-Notebooks durchführen – nur eingeschränkte Rechte zum Einreichen oder Verwalten ihrer eigenen Workloads haben. Mit dieser Bindung können jedoch selbst Konten mit geringen Berechtigungen die batch.kueue.openshift.io-API aufrufen und beliebige Job- oder Pod-Ressourcen erstellen.
Sobald dieser Zugang geschaffen ist, können Angreifer ihre Privilegien durch das Einschleusen bösartiger Container oder Init-Container weiter ausbauen. Diese manipulierten Workloads können Verwaltungsbefehle wie oc oder kubectl ausführen, Konten mit höheren Berechtigungen imitieren und die Privilegien Schritt für Schritt eskalieren, bis sie die Rolle cluster-admin erreichen.
Mit cluster-admin-Berechtigungen hat der Angreifer uneingeschränkte Kontrolle und kann Folgendes tun:
- Daten exfiltrieren: Auf Geheimnisse, Datensätze und geistiges Eigentum im Clusterspeicher zugreifen und diese stehlen.
- Dienste stören: Pods beenden, Jobs stoppen oder Dienste bereitstellen, die den Betrieb beeinträchtigen oder verhindern.
- Infrastruktur übernehmen: Clusterkonfigurationen ändern, persistente Hintertüren installieren oder auf andere Cloud-Ressourcen überspringen.
Für die Ausnutzung ist zwar ein authentifiziertes Konto erforderlich, die Hürde ist jedoch relativ niedrig. Tatsächlich könnte bereits ein einziges kompromittiertes oder von einem Insider kontrolliertes Konto zu einer vollständigen Beeinträchtigung von Vertraulichkeit, Integrität und Verfügbarkeit führen. Diese Fehlkonfiguration macht das gemeinsame Multi-User-Design der Plattform im Ergebnis zu ihrer größten Schwachstelle und setzt ganze hybride KI-Pipelines einer Übernahme aus.
Die Angriffskette frühzeitig unterbrechen
Red Hat hat Patches zur Behebung dieser Schwachstelle veröffentlicht. Eine alleinige Installation der Patches reicht jedoch möglicherweise nicht aus.
Um das Risiko einer Privilegieneskalation und einer vollständigen Clusterübernahme zu verringern, sollten Unternehmen die Zugriffskontrollen verstärken und kontinuierlich auf Anzeichen eines Missbrauchs achten. Zu den wichtigsten Gegenmaßnahmen gehören:
- RBAC-Kontrollen verschärfen: Die problematische ClusterRoleBinding entfernen, das Recht zur Joberstellung ausschließlich vertrauenswürdigen Gruppen gewähren und Rollenzuweisungen prüfen, um das Prinzip der geringsten Privilegien durchzusetzen.
- Auf ungewöhnliche Aktivitäten achten: Ungewöhnliche Pod-Erstellungen, Privilegieneskalationen von Servicekonten und verdächtige API-Aufrufe an batch.kueue.openshift.io nachverfolgen.
- Tools zur Richtliniendurchsetzung einsetzen: Admission-Controller oder OPA-/Kyverno-Regeln bereitstellen, um nicht vertrauenswürdige Pods zu blockieren und Privilegienmissbrauch zu verhindern.
- Workloads segmentieren und absichern: Namespaces isolieren, Netzwerkpfade beschränken und Tokens von Servicekonten regelmäßig austauschen sowie in ihrem Geltungsbereich einschränken, um laterale Bewegungen zu begrenzen.
- Kontinuierlich prüfen und testen: Scans der Sicherheitslage des Clusters durchführen, Audit-Protokolle pflegen und Tabletop-Übungen zur Reaktion auf Vorfälle in Kubernetes-/OpenShift-Umgebungen abhalten.
Diese Maßnahmen reduzieren zwar das unmittelbare Risiko, die Offenlegung macht jedoch auch grundlegendere Herausforderungen bei der Absicherung KI-gesteuerter Hybrid-Cloud-Umgebungen deutlich.
Warum KI-Dienste bevorzugte Ziele für Cyberangriffe sind
Diese Offenlegung unterstreicht eine wachsende Herausforderung für Unternehmen: KI-Dienste entwickeln sich aufgrund ihrer zentralen Rolle in Datenpipelines, beim Schutz geistigen Eigentums und in kritischen Entscheidungsprozessen zu besonders wertvollen Zielen.
Die OpenShift-AI-Schwachstelle zeigt, wie eine einzige Fehlkonfiguration im Identitäts- und Zugriffsmanagement zu einem plattformweiten Einbruch eskalieren kann.
Da Unternehmen ihre Hybrid-Cloud-Bereitstellungen ausweiten und GenAI-Dienste einsetzen, müssen die Härtung von RBAC und eine konsequente Patch-Praxis mit derselben Dringlichkeit behandelt werden wie das herkömmliche Patchen von Betriebssystemen und Anwendungen. Angreifer nutzen zunehmend Cloud-native Plattformen nicht durch hochentwickelte Zero-Days aus, sondern durch übermäßig großzügige Standardberechtigungen und übersehene Privilegienbindungen.
Wenn eine einzige Fehlkonfiguration einen gesamten Cluster zu Fall bringen kann, Zero-Trust wird weniger zu einer Strategie als zu einer Notwendigkeit.