Dell Container Storage Modules Flaws Rated CVSS 10 Expose Storage Array Admin Credentials to Unauthenticated Attackers (CVE-2026-63688, CVE-2026-63692)

Dell has fixed two maximum-severity authentication flaws in Dell Container Storage Modules (CSM). CSM is the set of Kubernetes components that connects container platforms to Dell enterprise storage. Security advisory DSA-2026-448, published on 1 October 2026, lists 13 Dell-specific CVEs. Two of them are rated CVSS 10.0: CVE-2026-63688 and CVE-2026-63692. Both are missing-authentication flaws in the CSM Authorization module. Dell says the first can hand an unauthenticated remote attacker the storage backend administrator credentials for "all registered storage arrays". Any cluster running CSM Authorization should be treated as a route to the storage behind it. Dell's fix is CSM 1.18.0 or later, and it lists no workarounds.

CVE-2026-63688 and CVE-2026-63692: How the Authentication Breaks

CSM Authorization sits between Kubernetes workloads and the storage arrays. Its job is to hold the array administrator credentials centrally and hand tenants limited, policy-controlled access. Both 10.0 flaws remove authentication from that intermediary.

• CVE-2026-63688 (CVSS 10.0). The csm-authorization-storage gRPC server has a "Missing Authentication for Critical Function" flaw (CWE-306). Dell says it can lead to "unauthorized access to storage backend administrator credentials for all registered storage arrays". Dell also says the flaw "enables a complete bypass of the csm-authorization security model, allowing an attacker to gain full administrative control over the storage infrastructure spanning all five supported Dell storage product families."
• CVE-2026-63692 (CVSS 10.0). Missing authentication in the authorization proxy and tenant service. Dell says an unauthenticated network attacker could bypass authentication controls and elevate privileges to administrative level, "potentially allowing unauthorized access to and manipulation of storage resources across all tenants."

Both carry the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The scope change (S:C) reflects the way the damage spreads from the Kubernetes component to the storage arrays it manages. Dell describes the affected CSM Authorization release as version 2.4.0. It has not published the specific gRPC methods or request flows involved, and this article does not reconstruct them.

The Wider Batch: Root on Nodes, Forged Tokens and Secrets Access

Five more Dell-specific flaws are rated 9.6 or higher:

• CVE-2026-67269 (9.9). Improper privilege management in the CSM Operator's ContainerStorageModule custom-resource reconciler (Operator 1.12.0). Dell says a low-privileged remote attacker can gain "root-level access on cluster nodes", and that the flaw "can be leveraged to completely compromise all nodes in the Kubernetes cluster through a single custom resource submission".
• CVE-2026-54472 (9.8). Hard-coded credentials in CSM Authorization 2.4.0. Dell says these let a remote unauthenticated attacker "forge cryptographically valid administrative tokens" for the CSM Authorization proxy, and it tells customers to "immediately rotate any JWT signing secrets".
• CVE-2026-61421 (9.8). A hard-coded cryptographic key in the archived, unmaintained karavi-authorization project. Dell says the official proxy-server configuration documentation once showed supersecret as the JWT signing secret, alongside real token output. That page was later removed without a security advisory. Dell warns that any deployment that followed the guide and never rotated the secret "may remain vulnerable".
• CVE-2026-67273 (9.6). Template-engine injection in CSM 1.12.0. A low-privileged attacker can gain cluster-wide read access to Kubernetes Secrets and create cluster-scoped RBAC resources.
• CVE-2026-67270 (8.2). Improper certificate validation in the CSM Authorization proxy-server. An unauthenticated attacker on an adjacent network could obtain storage backend administrator credentials.

The rest of the batch is lower severity:

• CVE-2026-76105 (7.7): insufficiently random values.
• CVE-2026-61411 (7.7) and CVE-2026-63689 (6.5): sensitive information written to log files.
• CVE-2026-70411 (7.1): missing authentication in the csm-authorization-tenant gRPC TenantService, which allows cross-tenant role injection from an adjacent network.
• CVE-2026-63691 (6.1): missing authorization in the PowerMax csireverseproxy.
• CVE-2026-63690 (5.4): missing authentication in the csi-powerflex, csi-powermax and csi-powerstore drivers.

DSA-2026-448 also bundles fixes for known third-party flaws in golang.org/x/crypto, golang.org/x/net, github.com/golang-jwt/jwt/v4 and google.golang.org/protobuf.

Exploitation Status

Dell's advisory says nothing about exploitation and includes no indicators of compromise. None of the 13 CVEs had a published CVE.org record when we checked on 4 October 2026, so DSA-2026-448 is the only authoritative description for now. Dell rates the advisory "Critical" overall. For several of the flaws, its descriptions end with the same instruction: "Dell recommends customers to upgrade at the earliest opportunity."

This is not the first credential-handling problem in CSM this year. On 21 May 2026, Dell published DSA-2026-234 for a separate hard-coded credentials flaw in the same product, CVE-2026-40710.

Affected and Fixed Versions

Dell's remediation table lists the affected product as "Container storage modules, Versions prior to 1.17.0", and the remediated version as "Version 1.18.0 or later". The table does not mention the 1.17.x line. Dell also notes that the table "may not be a comprehensive list of all affected supported versions". The advisory text for CVE-2026-76105 names v1.18.0 itself as affected. Until Dell clarifies, the safe reading is to run the newest available CSM release at or above 1.18.0, and to treat 1.17.x as in scope.

Defensive Playbook for Kubernetes and Storage Teams

1. Find every CSM install. The CSM Operator manages deployments through the ContainerStorageModule custom resource (short name csm). List the resources and the module images running in each cluster:

   # ContainerStorageModule resources managed by the CSM Operator
   kubectl get csm -A
   
   # Image tags of Dell CSM / CSI / authorization workloads
   kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"	"}{.metadata.name}{"	"}{.spec.containers[*].image}{"
   "}{end}'   | grep -Ei 'dell|csm|karavi|authorization'

2. Upgrade to CSM 1.18.0 or later on every cluster, including the Operator, CSM Authorization and the CSI drivers it fronts.
3. Rotate secrets after upgrading. Dell explicitly tells users to rotate JWT signing secrets (CVE-2026-54472). Because CVE-2026-63688 and CVE-2026-67270 can expose array administrator credentials, rotate the storage administrator credentials registered in CSM Authorization on every array too.
4. Remove karavi-authorization. If any cluster still runs the archived karavi-authorization project, migrate off it. If the signing secret is still the documented example value, assume tokens could have been forged.
5. Restrict network reach. Limit which networks can reach the CSM Authorization proxy, the storage and tenant gRPC services, and the CSI reverse proxy. Use Kubernetes NetworkPolicies and perimeter firewalls. Several of the flaws in this batch need only adjacent network access. (This is editorial guidance; Dell lists no workarounds.)
6. Audit Kubernetes and array activity. Review the Kubernetes API audit logs for unexpected ContainerStorageModule creates or updates (CVE-2026-67269), reads of Secrets across namespaces, and new ClusterRoles or ClusterRoleBindings (CVE-2026-67273). On the arrays themselves, review administrator logins and configuration changes made with the credentials CSM holds.

Storage credentials are high-value because they allow snapshot deletion, volume exposure and data destruction from a single control point. That is why the order of operations matters: patch, then rotate, then hunt.