When teams secure Kubernetes, they often focus on images, containers, RBAC and secrets. But another layer deserves the same attention: storage and the privileged components that connect it to the cluster.
What the Dell CSM advisory shows
On October 1, 2026, Dell published security advisory DSA-2026-448 covering several vulnerabilities in Container Storage Modules (CSM). Two of them, CVE-2026-63688 and CVE-2026-63692, received CVSS scores of 10.0.
According to Dell, CVE-2026-63688 could allow an unauthenticated remote attacker to access administrator credentials for registered storage systems. CVE-2026-63692 could allow privilege escalation up to administrator level in the authorization service.
Key point
A weakness in a storage extension can become a weakness in the cluster itself, and potentially in the infrastructure behind it.
Why storage is so sensitive in Kubernetes
Kubernetes commonly relies on the Container Storage Interface (CSI) to connect workloads to persistent volumes. CSI drivers and related modules can create, attach, mount and delete volumes, manage snapshots and handle storage credentials.
These components therefore require significant privileges. If compromised, their impact can be much broader than that of an application confined to a single pod.
The real attack surface is wider than Kubernetes itself
A modern cluster often depends on many components that are not part of Kubernetes core but still hold powerful permissions:
- CSI drivers and storage systems;
- operators and controllers;
- Ingress controllers;
- monitoring and security agents;
- backup tools;
- certificate and secret managers;
- GitOps tooling and CI/CD runners.
So the question “Is Kubernetes up to date?” is not enough. A better question is: which privileged components surround the cluster, and are all of them identified, maintained and monitored?
Other vulnerabilities reinforce the lesson
The Dell advisory also includes other critical issues. CVE-2026-67269, rated 9.9, could allow a low-privileged user to gain root access on cluster nodes through the CSM Operator. CVE-2026-67273 could expose Kubernetes Secrets cluster-wide and allow changes to RBAC resources.
Storage is therefore not a peripheral component. It can become a path to nodes, secrets and central authorization.
Three checks worth integrating
1. Inventory privileged components
Operators, DaemonSets, CSI drivers, monitoring agents and services that can interact with the Kubernetes API should be explicitly inventoried. Components that are forgotten are often also forgotten when updates are released.
2. Review permissions
Regularly inspect ClusterRoles, ClusterRoleBindings, ServiceAccounts, access to Secrets, privileged pods and host-mounted volumes to identify permissions that have become too broad.
3. Track security advisories for dependencies
Updating Kubernetes does not automatically update its drivers, operators and third-party tools. These components need to be treated as security dependencies in their own right.
What Dell CSM users should do
Dell recommends upgrading affected installations to Container Storage Modules 1.18.0 or later. The advisory does not provide a workaround for the main vulnerabilities.
- identify the CSM version currently deployed;
- apply the recommended update;
- review network exposure of CSM services;
- review secrets and credentials used by storage components;
- audit permissions granted to CSM components.
What this suggests for TechAtelier
For posture analysis, it is useful not to stop at Kubernetes versions and visible workloads. Installed extensions, privilege level, exposure and maintenance lifecycle matter just as much.
The same principle applies more broadly to infrastructure: the real attack surface includes the components that administer, observe, back up or connect the primary systems.
What to remember
This Dell advisory matters beyond CSM alone. In Kubernetes, cluster security also depends on everything connected to the cluster.
A storage driver, operator or monitoring agent can hold more privileges than the applications it supports. The chain to monitor is therefore:
applications → containers → Kubernetes → extensions → storage → infrastructure.
Sources
Published October 4, 2026. Versions and recommendations reflect Dell's advisory available on that date.