Dell patches six critical CSM flaws that handed admins the storage array and root on the Kubernetes nodes
Dell closed six maximum-severity vulnerabilities in Container Storage Modules, the layer that ties its PowerStore, PowerScale and PowerFlex arrays to Kubernetes. With no authentication at all, an attacker steals the arrays’ admin credentials, gains root on the nodes and reads every Secret: move to CSM 1.18.0 now.
October 2, 2026. Dell publishes a security advisory closing six critical vulnerabilities in Container Storage Modules (CSM), the software layer that ties its enterprise storage arrays to Kubernetes. October 2, 2026. Two of the flaws, both in the CSM Authorization module, let an unauthenticated attacker retrieve the admin credentials of every registered array and seize full administrative control over the storage infrastructure. October 2, 2026. Four more flaws deliver root on the cluster nodes, admin on the authorization proxy, forged authentication tokens, and read access to every Kubernetes Secret. Why it matters: CSM is the hinge between enterprise storage and containerized workloads — compromising it means compromising both the data and the control plane of the cluster.
A hinge that became a privileged pivot
Container Storage Modules is the layer Dell ships to extend the standard CSI drivers for Kubernetes across its PowerStore, PowerScale, PowerFlex, PowerMax and Unity XT platforms. In practice, CSM adds authorization, replication, observability and resilience services on top of the CSI driver — including the CSM Authorization module that decides who may access which array.
That position makes CSM a privileged pivot. It holds the storage array credentials, it talks to the Kubernetes API server, and it often runs with elevated privileges on the nodes. A flaw in this layer does not hit one isolated business service: it opens the door to both the storage and the cluster that consumes it. It is exactly the kind of component the storage team installs and the Kubernetes team forgets to inventory.
Two flaws that hand over the array administration
The two most severe vulnerabilities share the same root cause, missing authentication for critical functions (CWE-306).
The first, CVE-2026-63688, lets a remote unauthenticated attacker access the storage backend admin credentials for all registered arrays, then bypass authorization to gain full administrative control over the storage infrastructure.
The second, CVE-2026-63692, sits in the authorization proxy and the tenant service. It too lets an attacker bypass authentication controls to reach admin privileges. Dell put it plainly: the flaw “is considered critical as it enables an unauthenticated attacker to gain complete administrative control over the authorization service, potentially allowing unauthorized access to and manipulation of storage resources across all tenants.”
Four more flaws: root, forged tokens, Secrets
The same day, Dell patched four additional critical CSM issues, all remotely exploitable without privileges:
- CVE-2026-67269: gain root on the cluster nodes;
- CVE-2026-54472: administrative access to the CSM Authorization proxy;
- CVE-2026-61421: forge authentication tokens to gain administrative privileges;
- CVE-2026-67273: bypass Kubernetes access controls for cluster-wide read access to every Secret.
Together they paint a coherent attack path. An attacker who reaches the authorization module can chain a few of these flaws to go from no access to storage administrator, then to root on the nodes, collecting read access to every Secret along the way — the Kubernetes objects that concentrate the passwords, keys and tokens of every application.
What exploitation actually buys
The severity is not only about the privileges, but what they represent. Administrative control of the storage means reading, modifying or destroying the volumes that carry production data. Root on the nodes means escaping the container boundary and moving laterally through the cluster. Read access to Secrets means grabbing the credentials of services, databases and cloud accounts in one move.
Dell has not yet flagged these six flaws as actively exploited, but the precedent argues for speed. In February 2026, Mandiant and Google Threat Intelligence Group revealed that UNC6201, a suspected China-linked group close to Silk Typhoon, had been exploiting a hardcoded-credential flaw (CVE-2026-22769) in Dell RecoverPoint for Virtual Machines since mid-2024 to drop malware on VMware ESXi servers. Days later, CISA ordered federal agencies to patch their vulnerable Dell systems within three days.
The fix is a single upgrade
Dell asks customers to upgrade their container storage modules to version 1.18.0 or later, which fixes all six flaws. The company “recommends customers to upgrade at the earliest opportunity.”
The good news is that the fix is centralized: because all six vulnerabilities live in CSM and its companion modules, one version bump covers them all. The bad news is that CSM rarely sits inside the Kubernetes team’s watchlist: the storage team deploys it, then it gets forgotten. An authentication flaw only fires, in practice, if an attacker can reach the service — so network exposure is the first thing to check, before the upgrade even lands.
A recurring pattern in the storage layer
Missing authentication (CWE-306) on critical functions is not an exception in the containerized storage ecosystem. The CSI layer and its companion modules talk to both the storage and the cluster, which makes them a high-yield target: a single flaw there is often worth several privileges at once.
The operational consequence is twofold. First, these components rarely appear on the Kubernetes team’s map, which tracks pods, services and ingresses, but not the CRDs and controllers the storage team deployed upstream. Second, their attack surface is poorly controlled: the CSM Authorization service often listens behind a ClusterIP or LoadBalancer whose reachability nobody has actually checked.
To detect this kind of compromise, three signals matter: an unauthenticated connection to the authorization service, an unexpected creation of administrator accounts on the arrays, and abnormal Secret reads — often betrayed by changes in volume access or unusual configuration exports. The 1.18.0 upgrade closes the flaws, but without these signals nothing tells you whether a past exploitation already happened.
The trap of missing authentication is its silence. A CWE-306 leaves no trace in a diff: the function exists, it runs, and nothing in the code shouts “a check is missing.” It is a design flaw, not a coding error — it slips past reviews that hunt for bugs, and surfaces mainly when you audit who can reach which endpoint, not when you reread the lines.
Dell’s advisory marks all six as maximum severity, and its language — “critical”, “complete administrative control” — leaves no ambiguity about the urgency. For triage, treat this like the vendor is effectively requesting a CISA-style urgent patch: block the reachable CSM Authorization service first, then schedule the 1.18.0 upgrade as a change with rollback, since storage components underpin every workload that depends on them.
Verdict
If you run Dell CSM in production, apply the 1.18.0 upgrade this week, without waiting for an exploitation signal: six critical flaws that combine into a complete path to storage admin and cluster root do not justify patience. Until then, cut the CSM Authorization service off from untrusted networks. And if you don’t know whether CSM is installed, that is the real problem: inventory your CSI deployments and their companion modules, because this layer has become a privileged pivot that too many teams monitor poorly.