Dell CSM: Critical Flaws Enable Storage Admin Access and Kubernetes Privilege Escalation

1. Basic Information

• Original Title: DSA-2026-448: Security Update for Dell Container Storage Modules Multiple Vulnerabilities
• Source: Dell
• Published: October 1, 2026
• Updated: None
• Severity: Critical
• Severity Basis: Two vulnerabilities have a CVSS score of 10.0, one is 9.9, two are 9.8, and one is 9.6. These issues include paths allowing unauthenticated acquisition of storage management privileges and CSM Authorization admin rights, as well as paths enabling low-privileged users to impact the entire Kubernetes cluster. No active exploitation in the wild has been publicly reported.
• Reference: Dell
• Related References: BleepingComputer, Kubernetes: Custom resources and controllers
• Related Malware: None
• Related Threat Groups: None
• Related CVEs: CVE-2026-63688, CVE-2026-63692, CVE-2026-67269, CVE-2026-54472, CVE-2026-61421, CVE-2026-67273
• Related Products: Dell Container Storage Modules, Dell CSM Authorization, Dell CSM Operator, karavi-authorization

2. Quick Summary

Dell Container Storage Modules (CSM) have vulnerabilities that can allow unauthenticated attackers to obtain backend administrator credentials for registered storage arrays or forge administrative JWTs. A separate vulnerability can allow a low-privileged attacker to gain root access on cluster nodes by submitting a crafted Custom Resource. This article covers six critical vulnerabilities in DSA-2026-448 and distinguishes current CSM issues from legacy karavi-authorization deployments that still use publicly documented JWT signing secrets.

3. Attack Flow

Flow 1: Path A: Unauthenticated Takeover of CSM Authorization and Storage

1. Paths A, B, and C are independent exploitation paths, not mandatory stages of a single chain. Path A requires network access to the storage gRPC server affected by CVE-2026-63688 or the authorization proxy and tenant service affected by CVE-2026-63692.
2. The attacker bypasses authentication using CVE-2026-63688 or CVE-2026-63692 to obtain backend administrative credentials or CSM Authorization administrator privileges.
3. The attacker uses the acquired privileges to manage multiple tenants and registered storage arrays.

Flow 2: Path B: Forging Administrative JWTs from Public Secrets

1. CVE-2026-54472 targets hard-coded credentials in CSM Authorization 2.4.0. CVE-2026-61421 targets configurations that adopted signing secrets published in outdated official guides for the end-of-life karavi-authorization and remain unrotated.
2. Using CVE-2026-54472 or CVE-2026-61421, the attacker creates a cryptographically valid administrator token.
3. When the target configuration accepts the forged token, the attacker gains administrator access to the CSM Authorization proxy. Legacy karavi-authorization should be clearly inventoried separately from current CSM, and remaining secrets must be verified.

Flow 3: Path C: Escalating from Low-Privileged Kubernetes Access to the Entire Cluster

1. A low-privileged attacker gains the ability to input data into Custom Resources or template processing.
2. The attacker escalates privileges to root on cluster nodes via CVE-2026-67269 or reads Kubernetes Secrets and creates cluster-scoped RBAC resources via CVE-2026-67273.

4. Attacker Position and Execution Location

• Paths A and B involve unauthenticated network attackers with network reachability to the target services.
• Path C involves a low-privileged user capable of submitting Custom Resources within Kubernetes.

5. Victim and Administrator Perspectives

Victim

• No visual changes for end users are expected. While this may manifest as storage access failures or workload outages, no actual incidents have been publicly reported.

Administrator

• Indicators include suspicious gRPC/API access, usage of administrative tokens, Custom Resources, cluster-scoped RBAC, Secret reads, root processes on nodes, and storage configuration modifications.

6. Success and Failure Conditions

Success Conditions

• Vulnerable versions of CSM components are running.
• For Path A, the attacker can reach the affected service over the network.
• For Path B, the target proxy is reachable, hard-coded or legacy public signing secrets are actively used, and the configuration accepts forged tokens.
• For Path C, the low-privileged attacker can submit a relevant Custom Resource or supply input to the vulnerable template-processing functionality.

Failure Conditions

• Update to CSM 1.18.0 or later as advised by Dell and verify that the fixes have been applied to all affected components. Updating current CSM alone does not confirm the resolution of separately remaining legacy karavi-authorization or public signing secrets.
• Immediately rotate JWT signing secrets and verify the invalidation of old tokens. Assess exposure and compromise risks for storage backend credentials and rotate them after verifying the impact on connection destinations.
• Inference: Restrict service reachability and Custom Resource or template input permissions. Even if low-privileged users lack direct permissions to manipulate Secrets or RBAC, paths through vulnerable controllers must be evaluated separately, and these restrictions should not be treated as a substitute for updates.

7. What Happens Upon Success

• Exposure of administrator credentials and acquisition of management control over all registered storage arrays.
• Acquisition of administrator privileges across all tenants in CSM Authorization.
• Acquisition of root privileges on Kubernetes cluster nodes.
• Reading of Kubernetes Secrets and creation of cluster-scoped RBAC resources across the entire cluster.

8. Observable Logs

Email

• There are no email logs specific to this issue.

Proxy / SWG / DNS

• If CSM APIs/gRPC traverse a proxy, check for requests from unknown sources and high volumes of error or success responses.

Endpoint / EDR

• Check for unexpected root processes, file modifications, or container launches originating from CSM Operator or its controllers on cluster nodes.

Identity / IdP

• Verify authentication events for CSM/JWT admin tokens, service accounts, and Kubernetes users/groups.

SaaS / Cloud

• Use Kubernetes audit logs to correlate the identity that created a Custom Resource with subsequent Secret get/list operations and ClusterRole or ClusterRoleBinding creation. Check which identity performed each operation, including controller service accounts, rather than assuming all actions ran as the original user. Review storage array audit logs for administrative activity.

Network

• Check reachability sources to CSM Authorization gRPC/APIs and operations from the cluster to the storage management interface.

9. Attack Success Determination

Confirm Malware Execution or Successful Authentication

• Public Information and Criteria: Public Information: Dell explains that unauthenticated administrator privileges and credential access are possible, but no active exploitation has been reported. Criteria: Verify the usage of admin APIs or credential reading in correlation with unauthenticated requests or forged tokens.
• Target Scope: CSM Authorization and storage backends
• Related CVEs: CVE-2026-63688, CVE-2026-63692, CVE-2026-54472, CVE-2026-61421

Confirm Subsequent Compromise

• Public Information and Criteria: Public Information: Low-privileged users can reportedly acquire node root privileges, read Secrets, and create RBAC. Criteria: Verify root processes, Secret access, and cluster-scoped RBAC modifications correlated with malicious Custom Resources.
• Target Scope: Kubernetes clusters
• Related CVEs: CVE-2026-67269, CVE-2026-67273

10. Investigation Playbook

Trigger

• Trigger investigations based on vulnerable versions, external or cross-namespace exposure, suspicious tokens, Custom Resources, Secret access, and storage administrator operations.

Initial Verification

• Verify CSM versions, enabled modules, service exposure scopes, JWT secret rotation history, RBAC, and audit log retention status.

Endpoint

• Preserve and check processes, images, mount configurations, file modifications, and root-privileged executions on CSM pods and nodes.

Identity and Cloud

• Examine issuance, usage, and rotation status for JWTs, service accounts, Kubernetes RBAC, and storage backend credentials.

Subsequent Operations

• Track credentials obtained from Secrets, storage array operations, workload modifications, and lateral movement between nodes.

Containment

• Restrict service exposure and update to CSM 1.18.0 or later after preserving evidence. Rotate JWT signing secrets. Identify remaining legacy karavi-authorization deployments and migrate away from or retire them. Remove unauthorized RBAC resources and rotate exposed storage backend credentials after assessing the impact on dependent systems.

Decision Categories

• Categorize and record vulnerable configurations, authentication bypasses, credential access, administrator operations, node root privilege acquisition, and impacts on Secrets/RBAC.

11. Defense and Detection Ideas

Single Event

• Alert on suspicious Custom Resource/template inputs, unexpected Secret get/list actions or cluster-scoped RBAC modifications by entities including controller service accounts, and unauthenticated administrator requests to CSM services.

Time-Series Correlation

• Correlate Custom Resource creation -> CSM controller processing -> node root process, or token usage -> storage administrator operations as a unified workflow.

Hunting Perspectives

• Search for legacy default signing secrets, JWT signing secrets that have not been rotated, exposed CSM services, historical access to Kubernetes Secrets, and storage configuration changes.

Log Gaps

• gRPC payloads and CSM internal processing may not be verifiable through Kubernetes audit logs alone. Combine service mesh/network and storage audit logs.

Priority Countermeasures

• Prioritize updating to 1.18.0 or later, rotating secrets, restricting service exposure, and enforcing least privilege for RBAC.

12. Facts / Inference / Hypothesis

Facts

• CVE-2026-63688 is missing authentication in the storage gRPC server of CSM Authorization 2.4.0, allowing unauthenticated remote attackers to access backend administrator credentials for all registered storage arrays.
• CVE-2026-63692 is missing authentication in the authorization proxy and tenant service, allowing unauthenticated network attackers to elevate to administrator level.
• CVE-2026-67269 is a privilege management flaw in the Custom Resource reconciler of CSM Operator 1.12.0, potentially allowing low-privileged remote attackers to escalate from submitting a single Custom Resource to root privileges on cluster nodes.
• CVE-2026-54472 is an issue where administrator JWTs can be forged due to hard-coded credentials in CSM Authorization 2.4.0, prompting Dell to recommend updates and immediate rotation of JWT signing secrets. CVE-2026-61421 targets end-of-life karavi-authorization, where configurations adopting signing secrets from old official guides may remain vulnerable if the signing secret has not been rotated.
• CVE-2026-67273 is a template engine processing flaw, potentially allowing low-privileged remote attackers to read Kubernetes Secrets across the cluster and create cluster-scoped RBAC resources.
• Dell's advisory table instructs updating to CSM 1.18.0 or later and lists no workarounds. However, the affected versions column lists versions below 1.17.0, making it impossible to determine the exact handling of 1.17.x and its correspondence with component versions based on the table alone. Retirement/migration of legacy karavi-authorization and replacement of remaining secrets require separate verification. No active exploitation in the wild has been reported.

Inference

• In configurations where CSM Authorization is reachable from outside the cluster or from wide network segments, the impact of unauthenticated paths increases significantly; thus, service exposure settings and NetworkPolicies should be verified with priority.
• If storage backend credentials or Kubernetes Secrets are exposed, updating CSM alone will not invalidate the acquired credentials. Rotation and review of usage history are required.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "14. Open Questions and Additional Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1068	Exploitation for Privilege Escalation	high	The impact of escalating from low-privileged Custom Resource submissions to root privileges on cluster nodes is explicitly stated.

14. Open Questions and Additional Investigation

• Specific endpoints and requests for each vulnerability, whether CSM 1.17.x is affected, and the mapping between overall CSM versions and component versions such as Authorization and Operator.
• Which network segments can reach each service under default deployment configurations.
• Existence of active exploitation in the wild, public PoCs, or known IoCs.

15. Impact on SOCs and Organizations

In Japanese organizations that connect Dell storage to Kubernetes, even if storage teams and platform teams are separated, treat this as a single incident. Coordinate across CSM 1.18.0 updates, service exposure settings, Custom Resources/RBAC, Kubernetes Secrets, and storage array management operations, ensuring credential rotation is fully completed.

16. Summary by Role

• SOC: Correlate gRPC/API access, Custom Resources, RBAC, Secret reads, and storage management operations, and investigate by separating unauthenticated paths from low-privileged paths.
• Administrators: Update CSM to 1.18.0 or later and immediately rotate JWT signing secrets. Rotate storage backend credentials suspected of compromise after assessing the impact on dependent systems. Separately identify any remaining legacy karavi-authorization deployments and publicly documented signing secrets, migrate away from or retire those deployments, and replace the affected secrets. Restrict network access to Authorization services and apply least privilege to their RBAC permissions.
• Users: No end-user actions are required. Follow any storage or Kubernetes maintenance notices if provided.