Vulnerabilities

Dell has fixed two maximum-severity flaws in Container Storage Modules (CSM), the add-ons that sit next to Dell's CSI drivers and connect Kubernetes clusters to PowerFlex, PowerMax, PowerScale, PowerStore and Unity XT arrays. Both are in CSM Authorization 2.4.0 and both are rated CVSS 10.0. CVE-2026-63688 lets an attacker with no credentials pull the storage administrator credentials for every array registered with CSM Authorization. CVE-2026-63692 lets the same attacker skip login on the authorization proxy and tenant service and act as an administrator over every tenant's storage.

Advisory DSA-2026-448, published on October 1, lists affected releases as CSM versions prior to 1.17.0 and the fix as 1.18.0 or later. Dell says there are no workarounds. No exploitation or public proof of concept had been reported when the advisory came out, but an unauthenticated network flaw with a perfect score rarely stays quiet for long. If you run CSM Authorization in front of Dell arrays, plan the upgrade this week.

How CSM Authorization works, and where it breaks

CSM Authorization puts a proxy between the CSI driver in each Kubernetes cluster and the storage array. Instead of giving every cluster the array's admin password, the storage team gives each cluster a tenant token, a signed JSON Web Token (JWT). The driver sends its storage calls to a local sidecar, the sidecar forwards them to the Authorization proxy server with the token attached, and the proxy checks the token, applies role and quota rules, and only then makes the call on the array with credentials it holds itself.

Several services sit behind the proxy. The tenant service configures tenants and issues the JWTs. The role service defines the storage pools and quotas a tenant may use. The storage service holds each array's configuration and makes the API calls to it, using admin credentials pulled from Kubernetes Secrets, HashiCorp Vault or Conjur through the Secrets Store CSI driver. Dell's documentation notes that the proxy is usually exposed outside the cluster through an Ingress controller, because driver clusters elsewhere need to reach it.

The design concentrates the most valuable secret in one place on purpose: the array admin credential lives only in the storage service. CVE-2026-63688 is a missing authentication check on that service's gRPC server (gRPC is the remote procedure call framework the CSM services use to talk to each other). Anyone who can reach it can ask for the stored backend credentials, and Dell says that covers all registered storage arrays. With those, an attacker can log into each array's management interface directly and do anything that admin account can do, on volumes that may also serve systems outside Kubernetes.

CVE-2026-63692 is the same class of bug in the authorization proxy and tenant service. Dell describes the result as complete administrative control over the authorization service, which means reading or changing storage resources belonging to every tenant. Both carry the vector AV:N/AC:L/PR:N/UI:N/S:C: network reachable, low complexity, no privileges, no user interaction, with an impact that crosses into other components.

The other critical CVEs in the advisory

DSA-2026-448 lists 13 Dell CVEs plus updates to bundled Go libraries (golang.org/x/crypto, golang.org/x/net, golang-jwt and protobuf). Four more are rated critical, and two of them matter even if nobody outside the cluster can reach your services.

• CVE-2026-67269 (CVSS 9.9) is improper privilege management in the CSM Operator 1.12.0 reconciler for the ContainerStorageModule custom resource. A user with low privileges who can create or edit that resource can get root on cluster nodes.
• CVE-2026-67273 (CVSS 9.6) is a template injection flaw in CSM 1.12.0. Reports describe it as a way around Kubernetes role-based access control (RBAC) to read Secrets across the cluster.
• CVE-2026-54472 (CVSS 9.8) is a hard-coded credential in CSM Authorization 2.4.0 that can be used to forge tokens and gain admin access to the proxy.
• CVE-2026-61421 (CVSS 9.8) is a hard-coded JWT signing key in karavi-authorization, the archived predecessor of CSM Authorization. Old deployments that kept the documented default secret accept tokens anyone can sign.

The remaining seven range from 8.2 down to 5.4. They include improper certificate validation in the proxy server that can expose storage credentials (CVE-2026-67270), sensitive data written to logs (CVE-2026-61411 and CVE-2026-63689), a further missing authentication check in the csm-authorization-tenant gRPC service (CVE-2026-70411), use of insufficiently random values (CVE-2026-76105), and missing authentication or authorization checks in the CSI drivers, one of them specific to PowerMax (CVE-2026-63690 and CVE-2026-63691).

What attackers are doing

Nothing confirmed yet. Dell, BleepingComputer and SQ Magazine all report no known exploitation and no public proof of concept as of October 1 and 2. Expect that to change once someone diffs 1.18.0 against the previous release, since a missing authentication check is usually easy to spot in a patch.

What to do

1. Find every CSM deployment and upgrade it

Upgrade Container Storage Modules to 1.18.0 or later. Dell's table names CSM versions prior to 1.17.0 as affected, while the CVE text names CSM Authorization 2.4.0 and CSM Operator 1.12.0, and the fix is only stated for 1.18.0. Given that mismatch, treat anything below 1.18.0 as vulnerable. List the component images with kubectl get pods -A -o jsonpath='{range .items[*].spec.containers[*]}{.image}{"\n"}{end}' | grep -i csm | sort -u and check the operator, the Authorization services and the driver sidecars. Look as well for any karavi-authorization install still running on an old cluster or VM: it is archived and has no fix, so migrate it.

2. Until the upgrade is in

Dell lists no workaround. You can still cut down who reaches the vulnerable services. Make sure only the Ingress for the proxy is published outside the cluster, never the storage, tenant or role services, and add a Kubernetes NetworkPolicy in the Authorization namespace so the storage and tenant services accept traffic only from the proxy server pods. On the arrays, limit management API access to the addresses of the nodes running CSM Authorization. That shrinks the attacker pool; it does not fix the bug.

3. Check whether you were hit

• On each array, review admin logins and API sessions since the CSM Authorization install for source addresses other than the Authorization nodes, and for volumes, snapshots or exports nobody requested.
• In the Kubernetes audit log, look for get and list requests on Secrets from service accounts that do not normally read them, and for new ClusterRoles and ClusterRoleBindings: kubectl get clusterrolebindings --sort-by=.metadata.creationTimestamp.
• Review changes to ContainerStorageModule resources (kubectl get csm -A) and who made them, given CVE-2026-67269.

4. Rotate after upgrading

Upgrading closes the holes but does not invalidate anything already stolen. Replace the storage admin password for every array registered with CSM Authorization and update it in the Secret, Vault or Conjur path the storage service reads. Rotate the JWT signing secret, then issue new admin tokens with dellctl admin token and new tenant tokens for every driver cluster, since tokens signed with the old secret or the hard-coded one stay valid until you do.

The wider lesson

The credential leak, CVE-2026-63688, sits on an internal gRPC service that is never meant to face users. Teams often review the public Ingress and assume service-to-service gRPC inside the namespace is private, but any pod that can route to it, or any attacker who reaches the node network, gets the same access. Default-deny NetworkPolicies around services that hold secrets are worth having before the next advisory.

Our Kubernetes and cloud security reviews look at exactly this: which pods and networks can reach the services holding your credentials, and what RBAC lets a low-privileged user change. For a broader hardening pass, see safeguarding and hardening. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Dell DSA-2026-448, Dell CSM Authorization v2.x documentation, BleepingComputer, Cybersecurity News, SecurityOnline, SQ Magazine, HackerPosts, DEV Community.