Dell CSM Flaws Enable Unauthenticated Admin Access and Root on Kubernetes Nodes

1. Executive summary

Dell has released Container Storage Modules (CSM) 1.18.0 to fix six critical vulnerabilities in the CSM Authorization stack and the ContainerStorageModule Custom Resource reconciler, affecting all versions prior to 1.17.0. Two flaws carry a CVSS score of 10.0: CVE-2026-63688 (missing authentication in the csm-authorization-storage gRPC server) and CVE-2026-63692 (missing authentication in the authorization proxy and tenant service), both reachable by an unauthenticated remote attacker. Dell states CVE-2026-63688 gives full administrative control over storage infrastructure across all five supported Dell storage product families, and CVE-2026-67269 lets a low-privilege attacker reach root on every node in a Kubernetes cluster through a single custom resource submission. No verified reference data resolved for this item, so no CISA KEV exploitation state is asserted here; Dell reports no workarounds, and the only remediation is the upgrade to 1.18.0 plus rotation of JWT signing secrets. EMEA financial services firms running Dell CSM on Kubernetes clusters that back payment, core banking, or regulated data workloads should treat this as a P1 patch: the Authorization component is the control plane for storage access across tenants, and its compromise is a cross-tenant boundary failure, not a single-workload incident.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 28	The affected component is a third-party ICT product (Dell CSM) deployed inside the client's own Kubernetes estate, and Dell is the sole source of the fix.	Third-party risk management must cover the vendor's patch cadence and the contractual right to be notified of critical flaws; the client cannot self-remediate.
DORA Art. 30	Dell states there are no workarounds or mitigations other than updating to 1.18.0.	Contractual provisions with the ICT provider should give the client the fix, the advisory, and a support path within the remediation window; verify the support entitlement covers this version.
NIS2 Art. 21(2)(d)	The flaw sits in the supply chain of a storage control plane that other in-scope services depend on.	Supply chain security measures must extend to the container storage layer, not just the hypervisor and OS; evidence the patch decision and the residual risk if the upgrade slips.

No DORA Art. 17, 18, 19, 24 or 29 trigger and no NIS2 Art. 23 or UK NIS 2018 trigger is present in the source: the item describes a vulnerability disclosure and vendor patch, not an incident that has occurred at a client. If exploitation is later detected in your estate, Art. 17, 18, 19 and NIS2 Art. 23 become engaged at that point.

3. Technical analysis & attack chain

The affected product is Dell Container Storage Modules, the CSI driver and authorization layer that lets Kubernetes workloads consume Dell storage arrays. All versions prior to 1.17.0 are affected; 1.18.0 is the fixed release. Dell states there are no workarounds or mitigations other than the upgrade.

Confirmed attack chain, from the vendor descriptions:

The attacker reaches the csm-authorization-storage gRPC server over the network with no credentials. CVE-2026-63688 is a missing authentication for critical function flaw (CVSS 10.0). The server returns storage backend administrator credentials for all registered storage arrays. Dell calls this a complete bypass of the csm-authorization security model and states it grants full administrative control over storage infrastructure spanning all five supported Dell storage product families.
In parallel or instead, the attacker targets the authorization proxy and tenant service. CVE-2026-63692 is a second missing authentication for critical function flaw (CVSS 10.0). An unauthenticated network attacker bypasses authentication controls and gains administrative-level privileges, with access to and manipulation of storage resources across all tenants.
Where the JWT path is exposed, the attacker forges tokens rather than authenticating. CVE-2026-54472 (CVSS 9.8) is a use of hard-coded credentials flaw in the CSM Authorization module; a remote unauthenticated attacker forges cryptographically valid administrative tokens and gains unauthorized administrative access to the CSM Authorization proxy. CVE-2026-61421 (CVSS 9.8) is a use of hard-coded cryptographic key flaw in the JWT authentication component of karavi-authorization; an attacker with knowledge of the publicly available signing secret forges authentication tokens and gains administrative privileges. Dell recommends rotating JWT signing secrets as part of remediation, which confirms the signing material is the exposure.
A low-privilege attacker with remote access escalates to root on cluster nodes. CVE-2026-67269 (CVSS 9.9) is an improper privilege management flaw in the ContainerStorageModule Custom Resource reconciler. Dell states a single custom resource submission compromises all nodes in a Kubernetes cluster. CVE-2026-67273 (CVSS 9.6) is an improper neutralization of special elements used in a template engine flaw; a low-privilege attacker with remote access escalates privileges, accesses sensitive information, and carries out unauthorized RBAC tampering. Dell states successful exploitation grants cluster-wide read access to Kubernetes Secrets and the ability to create cluster-scoped RBAC resources, bypassing the intended Kubernetes access controls.

The two 10.0 flaws are the entry point that matters. CVE-2026-63688 hands over array administrator credentials, which is control of the storage fabric itself, below the Kubernetes layer. CVE-2026-63692 hands over the authorization service, which is control of who may mount what across every tenant. Either one alone defeats the tenancy model the CSM Authorization layer exists to enforce.

The privilege escalation pair is the persistence and lateral movement path. CVE-2026-67269 turns a single custom resource write into root on every node, and CVE-2026-67273 turns template injection into cluster-scoped RBAC creation and cluster-wide Secret reads. An attacker who lands either can mint their own cluster-admin binding and read every Secret in the cluster, including service account tokens, registry credentials, and any application secret stored there.

Dell's advisory language is the strongest available signal on impact and is quoted directly above. No exploitation in the wild is reported in the source material for any of these six CVEs. The source notes that two unrelated Dell CVEs, CVE-2021-21551 and CVE-2026-22769, have seen active exploitation in recent years; that is historical context about Dell products generally and does not indicate exploitation of the CSM flaws.

Confidence caveats. Every technical claim in this section is single-sourced to Dell's advisories as relayed by The Hacker News. The CVSS scores are as quoted in that reporting; no NVD record was available to corroborate them, and no CISA KEV entry was resolved. Treat the scores as vendor-assigned until independently confirmed. No indicators of compromise, exploitation telemetry, or named threat actor is present in the source material, and none is asserted here.

4. Mitigation & containment

P1 (within 24 hours)

Upgrade Dell CSM to 1.18.0 on every cluster running any version prior to 1.17.0. Dell states there are no workarounds or mitigations other than updating to the latest version, so this is the only remediation. Confirm the running CSM version per cluster before and after the change; the affected range is everything below 1.17.0.
Rotate all JWT signing secrets in the CSM Authorization deployment. Dell recommends this explicitly. Rotation is required even if you believe the cluster was never exposed, because CVE-2026-54472 and CVE-2026-61421 both rest on hard-coded credentials and a publicly available signing secret, so any token ever issued under the old secret must be treated as forgeable.
Restrict network reachability to the csm-authorization-storage gRPC server and the authorization proxy and tenant service. Both 10.0 flaws are unauthenticated and network-reachable. Until the upgrade lands, allow only the specific pod and node CIDRs that must talk to these services, and deny the rest at the network policy and firewall layer.
Audit for unauthorized cluster-scoped RBAC resources. CVE-2026-67273 lets an attacker create cluster-scoped RBAC resources. List ClusterRoleBindings and ClusterRoles with recent creation timestamps and reconcile them against your known baseline.

P2 (within 72 hours)

Audit Kubernetes Secret access. CVE-2026-67273 grants cluster-wide read access to Secrets. Review audit logs for get, list and watch on secrets across all namespaces from identities that do not normally perform those calls, and rotate any credential that was readable during the exposure window.
Review ContainerStorageModule custom resource submissions. CVE-2026-67269 is triggered by a single custom resource submission. Check the audit trail for create and update events on the ContainerStorageModule CRD and confirm each one against a change record.
Check node integrity on every cluster that ran an affected version. CVE-2026-67269 yields root on cluster nodes. Treat any node that was reachable by a low-privilege principal during the exposure window as suspect and rebuild from a known-good image rather than cleaning in place.
Verify storage array administrator credentials were not used outside their normal source. CVE-2026-63688 exposes array admin credentials for all registered arrays. Rotate those credentials on the arrays and confirm no unexpected administrative sessions occurred.

P3 (within 7 days)

Inventory every Dell CSM deployment across the estate, including clusters owned by business units or platform teams outside central change control, and record the version and the upgrade date.
Add CSM version to the standard container platform patch reporting so the next advisory in this product line does not require a manual sweep.
Where the upgrade cannot complete inside the P1 window, document the compensating network restriction and the residual risk, and set a hard date. Dell offers no workaround, so an unpatched cluster remains fully exposed to an unauthenticated attacker for as long as it runs.

5. Indicators of compromise

No indicators of compromise available in the source material. The source describes vulnerability mechanisms and vendor remediation only; it contains no hashes, domains, IP addresses, file paths, or command lines.

Behavioural indicators, derived from the exploitation paths Dell describes. These are hypotheses to hunt against, not observed activity, and each rests on a single vendor description.

behaviour	where to observe	confidence
Unauthenticated connection to the csm-authorization-storage gRPC server from outside the expected pod or node CIDR	Network flow logs, Kubernetes network policy logs, gRPC server access logs	Medium, single-sourced to Dell's advisory description
Administrative token presented to the CSM Authorization proxy that was not issued by the current signing secret	CSM Authorization proxy logs, JWT validation failures and successes	Medium, single-sourced
Creation of cluster-scoped RBAC resources (ClusterRole, ClusterRoleBinding) by an identity that does not normally create them	Kubernetes audit log, cluster-scoped RBAC object creation events	Medium, single-sourced
Cluster-wide get, list or watch on Secrets from an unexpected identity	Kubernetes audit log, secrets access events	Medium, single-sourced
Create or update on the ContainerStorageModule custom resource outside a change window	Kubernetes audit log, CRD write events	Medium, single-sourced
Root-level process execution on a cluster node following a custom resource write	Node EDR, process telemetry on worker nodes	Medium, single-sourced

6. Detection

The source contains no file artefacts, command lines, mutexes, registry keys, or filenames from the vulnerabilities themselves. It names the affected components (csm-authorization-storage, the authorization proxy and tenant service, karavi-authorization, the ContainerStorageModule reconciler) and the fixed version (1.18.0), but those are product and component names, not threat artefacts, and a rule built on them would detect reporting about the flaw rather than exploitation of it. No YARA rule is emitted for that reason.

The behavioural indicators in §5 are log-shaped and support a Sigma rule. The rule below hunts the cluster-scoped RBAC creation path Dell describes for CVE-2026-67273. It is a behavioural hunt, not a signature, and will need tuning to your baseline before it is promoted to alerting.

title: Cluster-Scoped RBAC Resource Creation by Non-Admin Identity
id: 8f2c1a44-6b7e-4d19-9c3a-2e5f7a1b0d63
status: experimental
description: Detects creation of ClusterRole or ClusterRoleBinding by an identity outside the known cluster administration set, consistent with the RBAC tampering path described for CVE-2026-67273 in Dell Container Storage Modules.
author: Adverse Trace
date: 2026/10/02
references:

  - https://thehackernews.com/2026/10/dell-csm-flaws-enable-unauthenticated.html
logsource:
  product: kubernetes
  service: audit
detection:
  selection:
    verb:

      - create
    objectRef.resource:

      - clusterroles
      - clusterrolebindings
  filter_known_admins:
    user.username:

      - system:admin
      - system:kube-controller-manager
      - system:kube-scheduler
  condition: selection and not filter_known_admins
falsepositives:

  - Legitimate platform engineering change windows that create cluster-scoped RBAC
  - GitOps controllers reconciling cluster-scoped roles
level: medium

7. Sources

The Hacker News, "Dell CSM Flaws Enable Unauthenticated Admin Access and Root on Kubernetes Nodes", https://thehackernews.com/2026/10/dell-csm-flaws-enable-unauthenticated.html, 2026-10-02. Single source for all technical detail in this advisory; it relays Dell's own advisories for the six CVEs.

8. Adverse Trace position

Adverse Trace assesses this as a high-priority patch for any EMEA financial services client running Dell CSM on Kubernetes clusters that back regulated or payment workloads. The severity is vendor-assigned and single-sourced: two CVSS 10.0 unauthenticated flaws in the storage authorization control plane, a 9.9 privilege escalation to root on all cluster nodes from a single custom resource write, and two 9.8 token-forging flaws resting on hard-coded credentials and a publicly available signing secret. No verified reference data resolved for this item, so we assert no CISA KEV exploitation state and no confirmed in-the-wild activity; the source reports none. The client impact is a cross-tenant boundary failure, not a single-workload compromise: an attacker who reaches the authorization service can read and manipulate storage across all tenants, and one who lands the reconciler flaw can read every Secret in the cluster and mint cluster-admin RBAC. We will track Dell's advisory for any revision to the affected version range or the fixed release, watch for exploitation reporting that would move this from patch-now to incident-response, and re-issue this advisory if either changes. Clients who cannot complete the 1.18.0 upgrade inside the P1 window should contact us to scope the network restriction and the residual exposure.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.