Dell CSM Sicherheitslücke CVE-2026-63688: CVSS 10.0 ohne Workaround

Die Dell CSM Sicherheitslücke CVE-2026-63688 erreicht den maximalen CVSS-Wert 10.0 – und Dell nennt im eigenen Advisory keinen einzigen Workaround. Betroffen sind die Dell Container Storage Modules, also die Bausteine, mit denen Dell-Storage-Arrays an Kubernetes angebunden werden. Wer sie einsetzt, hat keine Wahl: Es hilft nur das Update.

Dell CSM Sicherheitslücke: zwei Treffer mit CVSS 10.0

Dell hat das Advisory DSA-2026-448 am 1. Oktober 2026 veröffentlicht (Revision 1.0). Darin stecken 13 Schwachstellen in eigenem Dell-Code, dazu Updates für mehrere Go-Bibliotheken von Dritten. Die beiden schwersten zielen auf dieselbe Komponente: das Autorisierungsmodul CSM Authorization in Version 2.4.0.

• CVE-2026-63688 (CVSS 10.0) – im gRPC-Server csm-authorization-storage fehlt die Authentifizierung für eine kritische Funktion. Ein nicht angemeldeter Angreifer aus dem Netz kann damit laut Dell die Administrator-Zugangsdaten aller registrierten Storage-Arrays auslesen. Dell beschreibt das als vollständige Umgehung des Berechtigungsmodells, quer über alle fünf unterstützten Storage-Produktfamilien.
• CVE-2026-63692 (CVSS 10.0) – gleiche Fehlerklasse, diesmal im Authorization-Proxy und im Tenant-Service. Ergebnis: Administratorrechte auf dem Autorisierungsdienst, ohne Anmeldung, mandantenübergreifend.
• CVE-2026-67269 (CVSS 9.9) – im Reconciler der ContainerStorageModule-Custom-Resource (CSM Operator 1.12.0). Ein Angreifer mit niedrigen Rechten kommt über eine einzige eingereichte Custom Resource an Root-Rechte auf den Cluster-Knoten.
• CVE-2026-54472 (CVSS 9.8) – hartkodierte Zugangsdaten. Damit lassen sich kryptografisch gültige Admin-Tokens fälschen. Dell empfiehlt ausdrücklich, JWT-Signaturgeheimnisse zu rotieren.
• CVE-2026-61421 (CVSS 9.8) – im archivierten Vorgänger karavi-authorization stand in der offiziellen Dokumentation supersecret als JWT-Signaturschlüssel. Wer der Anleitung gefolgt ist und nie rotiert hat, ist weiter angreifbar.
• CVE-2026-67273 (CVSS 9.6) – eine Schwachstelle in einer Template-Engine (CSM 1.12.0). Laut Dell erhält ein Angreifer mit niedrigen Rechten damit clusterweit Leserechte auf Kubernetes-Secrets und kann cluster-weite RBAC-Ressourcen anlegen.

Betroffen sind laut Dell alle CSM-Versionen vor 1.17.0, behoben ist es in 1.18.0 oder neuer. Im Abschnitt „Workarounds & Mitigations“ steht schlicht: keine. Ein Detail am Rande: Eine kleinere Lücke im selben Advisory (CVE-2026-76105, CVSS 7.7, lokal ausnutzbar) ist ausdrücklich für v1.18.0 gelistet – das Update räumt also nicht restlos alles ab. Angriffe hat bislang weder Dell noch eine der berichtenden Quellen gemeldet. In der CISA-KEV-Liste steht keiner dieser CVEs, und in der NVD waren sie am 4. Oktober 2026 noch nicht erfasst – die Scores stammen damit allein von Dell.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Was die Dell CSM Sicherheitslücke für dich bedeutet

Technisch ist das kein exotischer Spezialfall, sondern ein Muster, das mir in Identity-Projekten immer wieder begegnet: Eine Komponente, die eigentlich Berechtigungen durchsetzen soll, prüft selbst nicht, wer mit ihr spricht. Genau deshalb ist die Einstufung mit 10.0 hier auch plausibel und nicht aufgeblasen – der Scope-Change im CVSS-Vektor sagt nichts anderes, als dass die Lücke über die Grenze der verwundbaren Komponente hinaus wirkt.

Praktisch heißt das: Der Angreifer braucht kein Konto und muss keinen Nutzer täuschen. Er braucht nur Netzzugang zum Dienst. Und er erbeutet nicht Daten, sondern Zugangsdaten – die Admin-Konten der Storage-Backends. Damit verschiebt sich das Risiko von „ein Cluster kompromittiert“ zu „die Speicherschicht unter mehreren Clustern kompromittiert“. Wer dort Admin ist, kann Volumes anlegen, Snapshots löschen und Daten abziehen – und das passiert nach meiner Erfahrung an einer Stelle, die das Kubernetes-Audit-Log gar nicht sieht. In meiner Erfahrung ist das der Grund, warum Storage-Management-Netze eigentlich nie dasselbe Netz wie Anwendungs-Workloads sein sollten.

Zwei Punkte würde ich dabei nicht übersehen. Erstens: CVE-2026-54472 und CVE-2026-61421 bleiben nach dem Update bestehen, wenn die Geheimnisse nicht rotiert werden. Ein gefälschtes Token interessiert sich nicht für die installierte Version. Zweitens: Die Nummer 1.17.0 ist tückisch. Dell nennt „alles vor 1.17.0″ als betroffen und erst 1.18.0 als behoben – wer auf 1.17.x sitzt, sollte deshalb trotzdem auf 1.18.0 gehen, statt sich auf die Formulierung zu verlassen.

Konkrete Handlungsempfehlung

Für Admins mit Dell-Storage an Kubernetes in dieser Reihenfolge:

• Inventar prüfen: kubectl get csm -A und die Image-Tags der CSM-Pods zeigen die eingesetzte Version. Alles unter 1.18.0 ist ein Kandidat.
• Auf CSM 1.18.0 oder neuer aktualisieren. Es gibt keinen Zwischenschritt und keine Mitigation.
• Nach dem Update alle JWT-Signaturgeheimnisse rotieren – und die Storage-Backend-Admin-Passwörter ebenfalls, weil sie möglicherweise schon abgeflossen sind.
• Netzwerkseitig den gRPC-Port des Authorization-Dienstes auf die Hosts einschränken, die ihn wirklich brauchen. Das ist kein Ersatz fürs Patchen, verkleinert aber die Angriffsfläche dauerhaft.
• In den Logs nach ungewöhnlichen Tenant- oder RBAC-Änderungen suchen, insbesondere nach cluster-weit angelegten Rollen, die niemand bestellt hat.

Wer sich gerade generell fragt, wie leicht Zugangsdaten in modernen Build- und Cloud-Ketten abfließen: Dieselbe Mechanik haben wir zuletzt bei der MLflow-Sicherheitslücke CVE-2026-64849 gesehen – ein Dienst ohne Authentifizierung, der fremde Cloud-Credentials herausgibt.

Quellen

• Dell: DSA-2026-448 – Security Update for Dell Container Storage Modules (1. Oktober 2026)
• The Hacker News: Dell CSM Flaws Enable Unauthenticated Admin Access and Root on Kubernetes Nodes (2. Oktober 2026)
• SecurityOnline: Dell Patches Two CVSS 10 Flaws in Container Storage Modules
• CISA: Known Exploited Vulnerabilities Catalog (Gegenprüfung, 4. Oktober 2026)