Executive Summary
Dell published a security advisory on 1 October rating two flaws in the authorization layer of its Container Storage Modules at 10.0, the maximum score. Both are reachable without authenticating, and one hands over the storage backend administrator credentials for every registered array. Four more criticals sit in the same advisory, including one that reaches root on every node in a cluster from a single custom resource.
Two things follow. The component whose entire job is keeping array credentials away from workloads is where those credentials could be picked up. And Dell tells customers to rotate JWT signing secrets immediately for a companion flaw, which says the upgrade alone does not close what was already exposed.
Container Storage Modules are the drivers and helpers that connect Dell arrays to Kubernetes through the Container Storage Interface. The CSM Authorization module sits in front of PowerStore, PowerScale, PowerFlex, PowerMax and Unity XT so a pod never holds the array’s own credentials. It decides which cluster identity may reach which storage.
Per Dell’s advisory, CVE-2026-63688 is a missing authentication flaw in the csm-authorization-storage gRPC server, rated 10.0. An attacker who can reach that service gets storage backend administrator credentials for all registered arrays. Dell calls it a complete bypass of the security model. CVE-2026-63692, also 10.0, sits in the authorization proxy and tenant service, where the same gap hands over administrative control across every tenant.
CVE-2026-67269, 9.9, reaches root on every node in the cluster from a single ContainerStorageModule custom resource. CVE-2026-54472 and CVE-2026-61421, both 9.8, cover hard-coded signing material, and the second one is the archived karavi-authorization component whose documentation once printed supersecret as the JWT key. CVE-2026-67273, 9.6, reads Kubernetes Secrets cluster wide.
Patching Is the Smaller Half of the Job
Dell’s fix is version 1.18.0 or later, with no workaround, so the upgrade is mandatory. It is also not sufficient. Rotate the JWT signing secrets, the storage admin passwords the authorization layer holds, and every token minted before the change. Check whether karavi-authorization is still deployed, because archived code does not get a fix.
Tenant separation failed the same way in Cloudflare’s container disk isolation bug last month. Boundaries nobody wrote down are the ones that leak. One question to answer this week. If a workload could reach the authorization service, who read the array audit logs?
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.