Dell CSM: Zwei Lücken mit CVSS 10 im Authorization-Modul für Kubernetes

Dell hat am 1. Oktober 2026 mit dem Security Advisory DSA-2026-448 zwei Schwachstellen mit der Höchstwertung CVSS 10.0 im Authorization-Modul der Container Storage Modules (CSM) geschlossen. Über CVE-2026-63688 und CVE-2026-63692 können Angreifer ohne Anmeldung die Zugangsdaten der Storage-Administratoren abgreifen oder volle Administratorrechte im Authorization-Dienst erlangen. Dasselbe Advisory behebt weitere kritische Lücken im CSM Operator und im archivierten Vorgänger karavi-authorization. Behoben ist alles ab CSM 1.18.0.

Betroffen sind ausschließlich Kubernetes-Cluster, die Dell-Speichersysteme (PowerStore, PowerScale, PowerFlex, PowerMax, Unity XT) über CSM anbinden, und dort vor allem Installationen mit dem Authorization-Modul. Wer keine Dell-Arrays an Kubernetes hängt oder nur klassische Dell-Server und PCs betreibt, ist nicht betroffen. Wer CSM Authorization einsetzt, sollte die Version heute prüfen und das Update kurzfristig einplanen, weil Dell keine Workarounds nennt.

Was ist passiert?

Die Container Storage Modules erweitern die CSI-Treiber von Dell um Zusatzfunktionen wie Replikation, Observability und Zugriffssteuerung. Das Authorization-Modul sitzt als Proxy zwischen den CSI-Treibern im Cluster und den Storage-Arrays. Es verwaltet Mandanten, Rollen und Kontingente und hält dafür die Administrator-Zugangsdaten aller registrierten Arrays vor.

Laut Advisory fehlt bei CVE-2026-63688 die Authentifizierung im gRPC-Server csm-authorization-storage. Ein entfernter Angreifer ohne Konto kann darüber die Backend-Zugangsdaten aller registrierten Arrays auslesen. Dell spricht von einer vollständigen Umgehung des Sicherheitsmodells mit voller administrativer Kontrolle über die Speicherinfrastruktur aller fünf unterstützten Produktfamilien. CVE-2026-63692 betrifft den Authorization-Proxy und den Tenant-Service: Auch hier fehlt die Authentifizierung, ein Angreifer im Netz kann sich zum Administrator des Authorization-Dienstes machen und Speicherressourcen aller Mandanten manipulieren. Beide Beschreibungen nennen CSM Authorization 2.4.0.

Das Advisory listet daneben weitere eigene Lücken, darunter:

• CVE-2026-54472 (CVSS 9.8): fest eingebaute Zugangsdaten im Authorization-Modul, mit denen sich gültige Admin-Tokens fälschen lassen. Dell rät zusätzlich, die JWT-Signaturschlüssel sofort zu rotieren.
• CVE-2026-67269 (CVSS 9.9): Rechteausweitung im CSM Operator 1.12.0 über eine präparierte ContainerStorageModule-Ressource bis zu Root-Rechten auf den Cluster-Knoten. Dafür braucht der Angreifer niedrige Rechte.
• CVE-2026-67273 (CVSS 9.6): Template-Injection, die Lesezugriff auf alle Kubernetes-Secrets im Cluster und das Anlegen clusterweiter RBAC-Ressourcen erlaubt.
• CVE-2026-61421 (CVSS 9.8): Im archivierten karavi-authorization stand in der früheren Dokumentation der Signaturschlüssel supersecret. Wer ihn übernommen und nie geändert hat, ist angreifbar.

Hinzu kommen Lücken mittlerer bis hoher Schwere in den CSI-Treibern für PowerFlex, PowerMax und PowerStore sowie zahlreiche CVEs in mitgelieferten Go-Bibliotheken.

Wer ist betroffen?

Die Tabelle im Advisory nennt als betroffen „Container Storage Modules Versions prior to 1.17.0“, als bereinigt Version 1.18.0 oder neuer. Die Einzelbeschreibungen nennen dagegen konkret Authorization 2.4.0, Operator 1.12.0 und in zwei Fällen sogar 1.18.0. Ob CSM 1.17.x sicher ist, lässt das Advisory damit offen. Dell weist selbst darauf hin, dass die Liste nicht vollständig sein muss. Admins sollten deshalb jede Version unter 1.18.0 als betroffen behandeln.

CSM 1.18.0 ist laut GitHub am 28. September 2026 erschienen, neue Versionen veröffentlicht Dell nur noch auf dell.com. Das passende Helm-Chart csm-authorization 2.6.0 steht seit dem 25. September im Repository dell/helm-charts. Nicht betroffen sind Cluster ohne Dell-Storage, Umgebungen mit fremden CSI-Treibern sowie Dell-Arrays, die nur per iSCSI, NFS oder Fibre Channel ohne CSM angebunden sind.

Wie kritisch ist das?

Für Umgebungen mit CSM Authorization ist die Lage akut kritisch. Beide Höchstwertungen erfordern weder Anmeldung noch Benutzerinteraktion, der Vektor lautet AV:N/AC:L/PR:N/UI:N/S:C. Erbeutete Array-Zugangsdaten reichen weit über Kubernetes hinaus: Wer PowerMax- oder PowerStore-Admins übernimmt, kann Volumes, Snapshots und Replikation manipulieren oder löschen.

Eine aktive Ausnutzung meldet Dell nicht, auch BleepingComputer kennt keine Angriffe. Ein öffentlicher Exploit ist nach aktuellem Stand nicht bekannt. Weil die Schwachstellen auf fehlender Authentifizierung beruhen, dürfte der Aufwand für Angreifer aber gering sein. Einen Eintrag in der NVD gab es zum Abrufzeitpunkt am 3. Oktober 2026 noch nicht.

Was sollten Admins jetzt tun?

• Inventar prüfen: helm list -A | grep -i csm zeigt Helm-Installationen von csm-authorization und den CSI-Treibern samt Chart-Version. Bei Operator-Installationen liefert kubectl get containerstoragemodules -A die ContainerStorageModule-Ressourcen, die Operator-Version steht im Image des Operator-Deployments.
• Auf CSM 1.18.0 oder neuer aktualisieren, für Helm-Installationen auf das Chart csm-authorization 2.6.0. Alle Versionen darunter als betroffen behandeln, auch 1.17.x.
• JWT-Signaturschlüssel des Authorization-Proxys nach dem Update rotieren, wie Dell es für CVE-2026-54472 empfiehlt. Wer noch karavi-authorization betreibt, sollte auf das aktuelle Authorization-Modul migrieren, weil das Projekt archiviert ist.
• Administrator-Passwörter der registrierten Arrays ändern, sobald die gepatchte Version läuft. Bei offener Erreichbarkeit lässt sich ein Abfluss nicht ausschließen.
• Erreichbarkeit einschränken: Proxy, Tenant- und Storage-Dienst nur aus dem Cluster und dem Admin-Netz erreichbar machen, NetworkPolicies und Firewall-Regeln prüfen.
• Logs auswerten: Audit-Logs der Arrays auf unbekannte Admin-Anmeldungen, gelöschte Snapshots oder neue Volumes prüfen, im Cluster nach unerwarteten Tenants, Rollen und ClusterRoleBindings suchen.

Einordnung für Unternehmen

Für die meisten kleinen Unternehmen ist die Meldung kein Thema, weil Dell-Enterprise-Storage mit Kubernetes-Anbindung eher in größeren Umgebungen und bei Dienstleistern läuft. Wo es eingesetzt wird, betrifft die Lücke aber die zentrale Stelle der Speicherinfrastruktur.

Hinzu kommt ein organisatorischer Punkt: CSM-Releases ab 1.18 erscheinen nur noch auf dell.com, nicht mehr auf GitHub. Wer Updates über GitHub-Releases verfolgt, sollte auf die Dell-Supportseite umstellen.

Passende Anleitungen auf S-EDV

• K3s-Kubernetes-Server einrichten: Grundlagen zu Clusteraufbau, Helm und Zugriffssteuerung.
• containerd CVE-2026-46680 umgeht runAsNonRoot: weitere aktuelle Schwachstelle im Kubernetes-Unterbau.
• containerd DoS: Docker und Kubernetes stürzen ab: Hintergrund zur Patchpflege von Container-Laufzeiten.

Quellen

• Dell Security Advisory DSA-2026-448 zu den Container Storage Modules (1. Oktober 2026)
• BleepingComputer: Bericht zu den Dell-CSM-Lücken mit Höchstwertung (2. Oktober 2026)
• GitHub dell/csm: Release v1.18.0 (28. September 2026)
• GitHub dell/helm-charts: csm-authorization 2.6.0 (25. September 2026)
• GitHub dell/karavi-authorization: archiviertes Vorgängerprojekt