Sechs Dell-CSM-Schwachstellen gefährden Speicherzugangsdaten, Mandantenkontrollen und Kubernetes-Knoten

Dell hat Sicherheitsupdates für sechs schwerwiegende Schwachstellen in den Dell Container Storage Modules (CSM) veröffentlicht. Zwei davon haben den maximalen CVSS-Score von 10,0.

Je nach Schwachstelle könnten Angreifer Zugangsdaten von Speicheradministratoren stehlen, gefälschte Administrator-Token erstellen, Autorisierungsdienste übernehmen, auf Kubernetes-Secrets zugreifen, clusterweite Zugriffskontrollen ändern oder Root-Rechte auf Cluster-Knoten erlangen.

Betroffen sind unter anderem der gRPC-Server csm-authorization-storage, der Autorisierungsproxy, der Mandantendienst, der Reconciler für die Custom Resource ContainerStorageModule, das CSM Authorization-Modul sowie der JWT-Authentifizierungscode in karavi-authorization.

Laut dem Bericht zu Dells Sicherheitsupdates sind Versionen vor 1.17.0 betroffen. Die Schwachstellen wurden in Version 1.18.0 behoben. Der Bericht macht keine Angaben zum Sicherheitsstatus von 1.17.0. Administratoren sollten daher nicht allein aus den genannten Versionsgrenzen ableiten, dass diese Version entweder betroffen oder fehlerbereinigt ist.

Nicht authentifizierte Angriffe ermöglichen Zugriff auf die Speicherverwaltung

Die schwerwiegendsten Schwachstellen eröffnen Angriffswege, für die kein bestehendes Konto erforderlich ist.

CVE-2026-63688 hat einen CVSS-Score von 10,0. Bei dieser Schwachstelle im gRPC-Server csm-authorization-storage versagt die Authentifizierung. Ein nicht authentifizierter Angreifer könnte die exponierte Funktion ausnutzen, um Administratorzugangsdaten für alle registrierten Speicher-Arrays zu erlangen.

Dell bezeichnet das Problem als vollständige Umgehung des Sicherheitsmodells von CSM Authorization. Bei erfolgreicher Ausnutzung könnten Angreifer die Speicherinfrastruktur mit vollständigen Administratorrechten kontrollieren. Sie umfasst alle fünf von CSM unterstützten Dell-Speicherproduktfamilien. Welche Produktfamilien das sind, geht aus dem genannten Bericht nicht hervor.

Das Risiko geht über den Zugriff auf ein einzelnes Volume oder einen einzelnen Mandanten hinaus. Zugangsdaten von Speicher-Backends können Zugriff auf Array-Ebene ermöglichen. Besonders schwerwiegend ist die Schwachstelle daher in Clustern, die mit mehreren registrierten Systemen verbunden sind.

Eine zweite Schwachstelle mit maximalem Schweregrad, CVE-2026-63692, betrifft den Autorisierungsproxy und den Mandantendienst. Auch sie hat einen CVSS-Score von 10,0.

Ein nicht authentifizierter Angreifer im Netzwerk könnte die betroffenen Authentifizierungsprüfungen umgehen und Administratorrechte erlangen. Laut Dell könnte die Ausnutzung zur vollständigen Übernahme des Autorisierungsdienstes führen. Dazu zählt auch die Möglichkeit, Speicherressourcen über alle Mandanten hinweg aufzurufen oder zu manipulieren.

Die beiden Schwachstellen betreffen unterschiedliche Vertrauensgrenzen. CVE-2026-63688 gibt Zugangsdaten preis, mit denen Speicher-Backends verwaltet werden. CVE-2026-63692 kompromittiert dagegen den Dienst, der die Autorisierung zwischen Mandanten und Speicherressourcen durchsetzt.

Fest eingebaute Geheimnisse ermöglichen gefälschte Token

Zwei weitere Schwachstellen betreffen Zugangsdaten oder kryptografisches Material, das in CSM-Komponenten eingebettet ist.

CVE-2026-54472 hat einen CVSS-Score von 9,8. Die Schwachstelle im CSM Authorization-Modul beruht auf fest eingebauten Zugangsdaten. Ein nicht authentifizierter Angreifer könnte gültige kryptografische Administrator-Token erstellen und sie gegen den CSM Authorization-Proxy einsetzen.

Dadurch ließen sich die üblichen Authentifizierungskontrollen des Proxys umgehen. Die erlangten Rechte könnten es ermöglichen, Speicherzugriffsrichtlinien für alle verbundenen Mandanten unbefugt zu verwalten.

CVE-2026-61421 hat ebenfalls einen CVSS-Score von 9,8. Sie betrifft einen fest eingebauten kryptografischen Schlüssel in der JWT-Authentifizierungskomponente von karavi-authorization. Ein nicht authentifizierter Angreifer im Netzwerk, der das öffentlich verfügbare Signaturgeheimnis kennt, könnte gefälschte Authentifizierungs-Token erstellen und Administratorrechte erlangen.

Diese Schwachstellen greifen das Vertrauen in signierte Token an. Akzeptiert ein Verifizierer Token, die mit einem kompromittierten oder öffentlich bekannten Signaturgeheimnis erstellt wurden, beweist eine gültige Signatur nicht mehr, dass ein autorisierter Dienst das Token ausgestellt hat.

Mit einem Softwareupdate wird die anfällige Implementierung behoben. Dell empfiehlt außerdem, die JWT-Signaturgeheimnisse zu rotieren. Dieser zusätzliche Schritt ist wichtig, damit zuvor offengelegtes Schlüsselmaterial nach dem Upgrade nicht weiterhin als vertrauenswürdig gilt.

Rechteausweitung in Kubernetes kann alle Knoten betreffen

Die übrigen Schwachstellen setzen Zugriff mit geringen Rechten voraus, können aber wichtige Sicherheitsgrenzen in Kubernetes überwinden.

CVE-2026-67269 betrifft die fehlerhafte Rechteverwaltung im Reconciler für die Custom Resource ContainerStorageModule. Die Schwachstelle hat einen CVSS-Score von 9,9.

Ein Angreifer mit geringen Rechten und Fernzugriff könnte eine speziell gestaltete Custom Resource einreichen und auf den Cluster-Knoten Root-Rechte erlangen. Laut Dell könnte bereits eine einzige Übermittlung einer Custom Resource ausreichen, um alle Knoten eines Kubernetes-Clusters zu kompromittieren.

Die Schwachstelle macht damit aus der Berechtigung, mit einer CSM-Custom-Resource zu interagieren, einen möglichen Weg zur Übernahme auf Knotenebene. Sie zeigt auch, warum der Zugriff auf Kubernetes-Custom-Resources nicht als harmlos gelten kann, wenn privilegierte Controller deren Inhalte verarbeiten.

CVE-2026-67273 hat einen CVSS-Score von 9,6. Ursache ist die unzureichende Neutralisierung spezieller Elemente, die von einer Template-Engine verarbeitet werden. Ein Angreifer mit geringen Rechten und Fernzugriff könnte die Schwachstelle ausnutzen, um seine Rechte auszuweiten, sensible Daten auszulesen und Änderungen an der rollenbasierten Zugriffskontrolle vorzunehmen.

Laut Dell könnte eine erfolgreiche Ausnutzung Lesezugriff auf Kubernetes-Secrets im gesamten Cluster ermöglichen. Außerdem könnten clusterweite RBAC-Ressourcen erstellt werden, wodurch sich die Zugriffsbeschränkungen umgehen ließen, die die bestehenden Rechte des Angreifers eigentlich begrenzen sollten.

Die gemeldeten Folgen reichen bei beiden Schwachstellen über den CSM-Dienst hinaus. Eine kann Root-Rechte auf allen Knoten ermöglichen, die andere Kubernetes-Secrets offenlegen und die Autorisierungsrichtlinien in der gesamten Kubernetes-Umgebung verändern.

Version 1.18.0 behebt die Schwachstellen

Laut den vorliegenden Angaben sind alle CSM-Versionen vor 1.17.0 betroffen. Dell behebt die sechs Schwachstellen in Version 1.18.0.

Da der Sicherheitsstatus von 1.17.0 anhand der verfügbaren Versionsangaben offenbleibt, sollten Unternehmen die von Dell bereitgestellte fehlerbereinigte Version installieren, statt 1.17.0 als implizit sicher einzustufen. Empfohlen wird ein Update auf die neueste Version.

Der zitierte Bericht nennt keine alternativen Workarounds oder Gegenmaßnahmen. Netzwerkbeschränkungen und andere Schutzmaßnahmen können das Risiko in manchen Umgebungen verringern, sollten aber kein Ersatz für das Herstellerupdate sein.

Administratoren sollten die folgenden Maßnahmen gemäß den veröffentlichten Empfehlungen ergreifen:

1. Die installierten Dell-CSM-Versionen erfassen und Installationen ermitteln, auf denen nicht 1.18.0 läuft.
2. Betroffene Installationen auf die fehlerbereinigte Version aktualisieren.
3. Die von Dell empfohlenen JWT-Signaturgeheimnisse rotieren.
4. Die Rechte von Identitäten überprüfen, die ContainerStorageModule-Custom-Resources einreichen können.
5. Sicherstellen, dass Autorisierungsdienste, Mandantenschnittstellen und der gRPC-Server csm-authorization-storage nur im betrieblich erforderlichen Umfang erreichbar sind.

Der Bericht enthält keine Indikatoren für eine Kompromittierung. Das Fehlen solcher Indikatoren belegt jedoch nicht, dass über andere Kanäle keine veröffentlicht wurden.

Für diese sechs CVEs wurden keine Angriffe gemeldet

Den verfügbaren Berichten zufolge wird keine der sechs CSM-Schwachstellen aktiv ausgenutzt. Diese Unterscheidung ist wichtig: Die möglichen Auswirkungen sind schwerwiegend, doch die vorliegenden Informationen reichen nicht aus, um die Schwachstellen als nachweislich aktiv ausgenutzt einzustufen.

Dell-Produkte waren allerdings bereits im Katalog der bekannten ausgenutzten Schwachstellen der Cybersecurity and Infrastructure Security Agency (CISA) vertreten.

CVE-2026-22769 betrifft Dell RecoverPoint for Virtual Machines in Versionen vor 6.0.3.1 HF1. Die Schwachstelle durch fest eingebaute Zugangsdaten hat einen CVSS-Score von 10. Ein nicht authentifizierter Angreifer mit Fernzugriff kann dadurch Zugriff auf das zugrunde liegende Betriebssystem mit Root-Rechten und dauerhafter Präsenz erlangen.

CISA nahm CVE-2026-22769 am 18. Februar 2026 in den KEV-Katalog auf. Für Bundesbehörden galt eine Behebungsfrist bis zum 21. Februar 2026. Als erforderliche Maßnahme wurde genannt: „Die Gegenmaßnahmen gemäß den Anweisungen des Herstellers umsetzen, bei Cloud-Diensten die einschlägigen Vorgaben aus BOD 22-01 befolgen oder das Produkt außer Betrieb nehmen, falls keine Gegenmaßnahmen verfügbar sind.“

Eine ältere Dell-Schwachstelle, CVE-2021-21551, betrifft unzureichende Zugriffskontrollen im Treiber dbutil_2_3.sys. Sie setzt lokalen authentifizierten Zugriff voraus und kann zur Rechteausweitung, zu einem Denial-of-Service-Angriff oder zur Offenlegung von Informationen führen. Ihr CVSS-Score beträgt 8,8.

CISA nahm CVE-2021-21551 am 31. März 2022 in den KEV-Katalog auf und setzte für betroffene US-Bundesbehörden eine Behebungsfrist bis zum 21. April 2022. Die erforderliche Maßnahme bestand darin, die Updates gemäß den Anweisungen des Herstellers zu installieren.

Diese früheren KEV-Einträge liefern Kontext dazu, dass Dell-Produkte bereits von aktiv ausgenutzten Schwachstellen betroffen waren. Sie stehen jedoch nicht mit den sechs CSM-Schwachstellen in Verbindung. Aus den verfügbaren Informationen lassen sich weder ein gemeinsamer Angreifer noch eine Kampagne oder eine zusammenhängende Angriffskette ableiten.