SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

Dell's CSM advisory has two 10.0 flaws among 13. The 'root on nodes' one is a 9.9 needing low privileges

Dell's advisory DSA-2026-448 lists 37 CVEs: 13 in its own code, two scored 10.0 and six scored 9.6 or more, with no workaround. The root-on-nodes flaw is a separate 9.9 that needs low privileges, and the version range leaves 1.17.x unaccounted for.

By Parminder Kumar Sharma · · 17 min read

Editorial illustration for the briefing: Dell's CSM advisory has two 10.0 flaws among 13. The 'root on nodes' one is a 9.9 needing low privileges

Thirteen flaws, two scored 10.0, and the headline merges them

Dell's security advisory DSA-2026-448, published on Thursday 1 October 2026, lists 37 CVEs for Dell Container Storage Modules (CSM), the software that connects Dell storage arrays to Kubernetes. Thirteen are in Dell's own code and 24 are in Go libraries. Of the 13, two score 10.0 and six score 9.6 or more. The advisory's Workarounds and Mitigations section says "None", and its remediation table gives one fix: version 1.18.0 or later.

What that does not establish. It does not establish that any cluster is exposed, that anyone has exploited any of the 13, or that the two 10.0 flaws are the ones that give root on Kubernetes nodes. They are not. The 10.0 flaws are in CSM Authorization and need no login. Root on nodes is a different bug, CVE-2026-67269 in the CSM Operator, scored 9.9, and Dell calls its attacker "low privileged". The Hacker News headlines both together as "Unauthenticated Admin Access and Root on Kubernetes Nodes". They do not share a precondition, and a platform team that treats them as one will patch in the wrong order and ask the wrong exposure question.

I read Dell's advisory in full through a browser, because Dell's site refuses plain command-line requests. I then checked the CVE Program, the NVD and CISA's Known Exploited Vulnerabilities (KEV) catalogue. None of the 13 has a CVE record or an NVD entry yet, so every score in this briefing is Dell's alone, and none of the 13 is in KEV. Every state below is time-stamped to about 11:15 BST on Saturday 3 October 2026, two days after the advisory, and any of them could change within hours.

What the advisory states and what it leaves out

The advisory is revision 1.0, an initial release, with impact rated Critical. It is long on scores and short on everything a defender asks next. The table sets what Dell wrote against what a platform team needs and does not get.

Dell advisory DSA-2026-448 (revision 1.0, 1 October 2026), read in full on 3 October 2026, set against the CVE Program, the NVD and CISA KEV.

  1. Question
    Affected versions
    What Dell states
    "Versions prior to 1.17.0"
    What it leaves out
    Nothing on 1.17.0, 1.17.1 or 1.17.2, released 28 May, 23 June and 17 July. A footnote says the table "may not be a comprehensive list"
  2. Question
    Fix
    What Dell states
    "Version 1.18.0 or later"
    What it leaves out
    No fixed version by the Authorization module's or the Operator's own number. No fix for the archived karavi-authorization
  3. Question
    Workaround
    What Dell states
    "None"
    What it leaves out
    No interim step that reduces exposure
  4. Question
    Reachability
    What Dell states
    "unauthenticated remote attacker" for CVE-2026-63688, "unauthenticated network attacker" for CVE-2026-63692, both scored Network
    What it leaves out
    From where: the internet, another cluster, or the pod network. Whether a default install exposes the vulnerable service
  5. Question
    Exploitation
    What Dell states
    Nothing, either way
    What it leaves out
    No "aware of" and no "not aware of". None of the 13 is in KEV
  6. Question
    Who found them
    What Dell states
    Nothing
    What it leaves out
    No acknowledgement section, no researcher or team named
  7. Question
    How they work
    What Dell states
    One weakness class per CVE, such as Missing Authentication for Critical Function
    What it leaves out
    No mechanism, no affected endpoints, no detection guidance, no indicators
  8. Question
    Which arrays
    What Dell states
    "all five supported Dell storage product families"
    What it leaves out
    The five are not named. Dell's 1.17.0 Authorization capability table has four platform columns
  9. Question
    Records
    What Dell states
    Scores and vectors, in the advisory only
    What it leaves out
    No CVE record, NVD entry, named CNA, CWE or reference list for any of the 13

Two of those gaps decide your first hour. Reachability decides whether the 10.0 flaws are an internet problem or a network-segmentation problem, and the advisory does not say. The version row decides whether the 1.17.x release you installed since May is safe, and the advisory does not say that either.

The crux for a cluster: what "network" means

Both 10.0 flaws carry the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Read left to right: reachable over a network, low attack complexity, no privileges, no user interaction, scope changed, and high impact on confidentiality, integrity and availability. I recomputed the score from that vector with the CVSS 3.1 formula and it is 10.0.

The word "network" is a ceiling, not a position. FIRST's CVSS 3.1 specification defines the Network value as one where the set of possible attackers extends "up to and including the entire Internet". It defines Adjacent as limited to a logically adjacent topology, such as a local subnet or a secure administrative domain. So AV:N tells you the worst case the scorer was prepared to allow, and says nothing about where an attacker would have to stand against your estate.

Dell's documentation shows why that matters for this product. The Authorization proxy is built to be reached from other clusters. The documentation for the 1.16.3 line says the proxy server is "exposed outside the Kubernetes cluster via an Ingress controller" and that the driver and Authorization namespaces "can reside on different Kubernetes clusters". So the intended deployment puts the vulnerable service behind a hostname that driver pods elsewhere resolve and call. Who else can reach that hostname, and the proxy, tenant and storage services behind it, is a property of your network. The advisory is silent on it.

A component diagram of a Dell Container Storage Modules deployment with the 13 CVEs placed on the components Dell names. A driver pod calls an Ingress into the Authorization proxy. The proxy and tenant service carry the 10.0 CVE-2026-63692, the storage gRPC server the 10.0 CVE-2026-63688, the JWT signing secret two 9.8 flaws. The cluster-wide operator carries the 9.9 root-on-nodes CVE-2026-67269 and a 9.6.
Drawn from Dell advisory DSA-2026-448, Dell's CSM Authorization documentation (1.16.3 line) and Dell's csm-operator manifests at tag v1.12.0. Placement of the storage gRPC server follows Dell's image and service names and is inferred.

Inference, labelled. I read the practical test as three questions. Can any host outside your driver clusters and storage administrators open a connection to the Authorization Ingress? Can any pod in the Authorization cluster reach the proxy, tenant and storage services directly? And for the root-on-nodes flaw, who can create or change a ContainerStorageModule custom resource? Dell says that attacker is low privileged and that one custom resource submission is enough. Dell does not define "low privileged" beyond the CVSS metric, which FIRST describes as basic user capabilities.

Dell scores four other rows Adjacent and one Local. Those need a position on the network, or on the host, that the Network rows do not. The ladder below puts all 13 on one scale, with the reach and the privileges Dell scored for each.

A bar chart drawn to scale of the 13 CVEs in Dell's own code in advisory DSA-2026-448, from CVE-2026-63688 and CVE-2026-63692 at 10.0 down to CVE-2026-63690 at 5.4, with the component, attack vector and privileges required for each. Six score 9.6 or more. Four are Network with no privileges required. Two, including the 9.9 root-on-nodes flaw, need low privileges. Four of the 13 are Adjacent and one is Local.
Scores, vectors and component wording from Dell advisory DSA-2026-448. Bars and the counts beneath are drawn and derived by me from the advisory's table.

What "unauthenticated admin" and "root on nodes" mean in Dell's words

Both phrases are headline compressions of six rows. Here is what each critical row says, kept to Dell's own claims about who can exploit it and what follows.

The six critical rows of Dell advisory DSA-2026-448, paraphrased except where quoted. Versions are as Dell prints them.

  1. CVE and score
    CVE-2026-63688, 10.0
    Who can exploit it, per Dell
    An unauthenticated remote attacker. CSM Authorization 2.4.0, storage gRPC server
    Outcome, per Dell
    Access to storage backend administrator credentials for all registered arrays. A "complete bypass of the csm-authorization security model"
  2. CVE and score
    CVE-2026-63692, 10.0
    Who can exploit it, per Dell
    An unauthenticated network attacker. Authorization proxy and tenant service, version 2.4.0
    Outcome, per Dell
    Bypass of authentication, administrative privileges, complete control of the authorization service, and access to storage resources across all tenants
  3. CVE and score
    CVE-2026-67269, 9.9
    Who can exploit it, per Dell
    A low privileged remote attacker. CSM Operator 1.12.0, the ContainerStorageModule custom resource reconciler
    Outcome, per Dell
    Root-level access on cluster nodes. All nodes compromised "through a single custom resource submission"
  4. CVE and score
    CVE-2026-54472, 9.8
    Who can exploit it, per Dell
    A remote unauthenticated attacker. CSM Authorization 2.4.0, hard-coded credentials
    Outcome, per Dell
    Forged administrative tokens, administrative access to the proxy, and management of access policies across all connected tenants. Dell adds: rotate any JWT signing secrets
  5. CVE and score
    CVE-2026-61421, 9.8
    Who can exploit it, per Dell
    A remote unauthenticated attacker who knows a publicly available signing secret. karavi-authorization, archived
    Outcome, per Dell
    Forged authentication tokens and administrative privileges. Dell says the secret was shown in documentation that was "removed without a security advisory"
  6. CVE and score
    CVE-2026-67273, 9.6
    Who can exploit it, per Dell
    A low privileged attacker with remote access. Component not named, version "[1.12.0]"
    Outcome, per Dell
    Cluster-wide read access to Kubernetes Secrets and the ability to create cluster-scoped RBAC resources

Three readings follow. First, "unauthenticated admin access" is four flaws, not two. The two 9.8 rows need no privileges and give administrative tokens, so the 0.2 between them and the 10.0 rows is not a difference in how easily they are reached. Second, "root on nodes" is a low-privilege flaw in the operator, so its risk is set by who can create resources in your cluster, not by who can reach a port. Third, the 9.6 row names no component, but its stated outcome, reading every Secret and creating ClusterRoles, matches what the operator's service account is allowed to do in the manifest Dell publishes. That match is my inference, not Dell's statement.

One report differs from the advisory on privileges. BleepingComputer says four further flaws can be exploited without privileges, and lists the root-on-nodes and Secrets rows among them. The advisory says both of those need low privileges, and this briefing follows the advisory. The same report says Dell asks admins to patch as soon as possible. Dell's own words are "upgrade at the earliest opportunity", and its rotation advice for JWT signing secrets is attached to CVE-2026-54472 alone.

Three names that are not controls

"Container Storage Module". The label sounds like a driver or a plug-in. CSM Authorization is a server. Dell's documentation describes a proxy with its own namespace, an Ingress, a tenant service, a role service, a storage service, a Redis store and a policy engine. Dell's 1.17.0 guide lists, as the first capability, keeping "storage passwords safe by locking them in a vault" away from Kubernetes administrators. CVE-2026-63688, as Dell describes it, hands over administrator credentials for all registered arrays. The component that exists to keep array passwords away from Kubernetes administrators is the place where a missing authentication check puts them within reach. The same label covers the operator, which in Dell's v1.12.0 manifest runs under a ClusterRole that can read and write Secrets in every namespace and create DaemonSets, ClusterRoles and bindings.

Storage plumbing under a container platform has failed at its tenancy boundary before. Brief 130 covers Cloudflare's Containers, where the boundary that failed was an option on the disk pool and not the virtual machine. Here the tenancy boundary is a service rather than a flag, and it is labelled a module.

"Max severity". A score someone assigned. So far Dell alone assigned it: the advisory is the only place the 10.0 appears, the same position as in brief 200. The arithmetic is sound. I recomputed all 13 scores from their vectors and every one matches. What the formula cannot check is the inputs. The two 10.0 rows and the two 9.8 rows differ by one letter, Scope, Changed against Unchanged. FIRST defines a scope change as impact beyond the security scope of the vulnerable component's authority. Whether the authorisation service and the arrays count as separate authorities is a judgement, and it moves a score by 0.2.

Rank by what is reachable and what sits behind it, not by 10.0 against 9.8. Dell also prints CVSS 3.1 only, with no v4.0 score. Brief 131 scored seventeen CVEs under both and found that six crossed a severity band, every one upward, so the number that reaches your ticket depends on the calculator. Dell publishes the advisory, the fix and the score, and benefits from a calm reading. None of that is evidence of mis-scoring here. The criticism is narrower: this is a first revision, and the next section shows it.

"Archived" and "no longer actively maintained". Dell's own words for the karavi-authorization project behind CVE-2026-61421. Its GitHub repository is archived, its last push was on 17 June 2025, 471 days before the advisory, and its description says CSM Authorization v1 is deprecated and tells users to migrate to v2. There is no fixed version to name because nothing is being released. Dell says the flaw is that configuration documentation showed an example signing secret next to real token output, and that the page was removed without an advisory. The control is rotation and migration, not patching. I have not reproduced the example value: Dell's advisory names it and your documentation archive will show it. Treat any signing secret that was copied from documentation, or never rotated, as known.

The version numbers do not line up

The affected-versions row says "Versions prior to 1.17.0". Six things in the advisory and in Dell's public repositories make that row hard to rely on.

Version statements in DSA-2026-448 checked against Dell's GitHub releases for dell/csm and dell/csm-operator, and Dell's CSM component table (1.16.3 line), read on 3 October 2026.

  1. Item
    Headline range
    What is published
    Affected: prior to 1.17.0. Remediated: 1.18.0 or later
    The problem
    1.17.0, 1.17.1 and 1.17.2 sit in neither column. They were released 28 May, 23 June and 17 July 2026
  2. Item
    Operator rows
    What is published
    CVE-2026-67269 names CSM Operator 1.12.0. CVE-2026-67273 names version "[1.12.0]"
    The problem
    Dell's csm-operator repository tags v1.12.0 on a commit titled "CSM 1.17 updates", and v1.12.1 follows with "CSM 1.17.1 updates". So 1.12.x looks like the 1.17 line, which the headline range excludes. Inference from commit titles
  3. Item
    Authorization rows
    What is published
    Five rows name CSM Authorization 2.4.0
    The problem
    Dell's 1.16.3 component table lists Authorization v2.x at 2.4.0. The advisory does not say which Authorization version holds the fixes
  4. Item
    Fixed version named as affected
    What is published
    CVE-2026-76105 names v1.18.0
    The problem
    That is the version the remediation row gives as the fix. Typo or open bug: Dell has not said
  5. Item
    Unfilled rows
    What is published
    Four rows (CVE-2026-61411, 63689, 63691 and 63690) give version(s) as "[Versions]"
    The problem
    The template placeholder was published as the value
  6. Item
    Remediation link
    What is published
    Points to a git host on a lab.emc.com domain
    The problem
    It is not a download page. Dell's public repositories list v1.18.0 and operator v1.13.0 on 28 September

The practical reading is plain. Treat 1.18.0 as the only version Dell says is safe. Check what each component reports after you upgrade, because the advisory names three different version series: the CSM release, the Authorization module and the operator. Ask Dell in writing about 1.17.x. And re-read the advisory before closing the ticket, because Dell's footnote says the table may be updated.

One more date matters. Dell's csm repository tags v1.18.0, and csm-operator tags v1.13.0, at 14:32 UTC on 28 September, 3 days before the advisory. The v1.18.0 release body I read contains only a notice that documentation has moved to Dell.com, with no security wording. That is a fact about the public release page. When Dell told customers privately, if it did, is not stated.

What is said about exploitation, as at 11:15 BST on 3 October

Every row is time-stamped, because each could be overtaken within hours.

Exploitation and record evidence for the 13 CVEs in Dell's own code, read between 11:10 and 11:25 BST on 3 October 2026.

  1. Source
    Dell advisory DSA-2026-448
    What it says
    Nothing on exploitation, either way
    Reading
    Silence, not a denial
  2. Source
    CISA KEV, catalogue 2026.10.02
    What it says
    1,733 entries, released 2 October at 15:19 UTC. None of the 13, and no entry names CSM
    Reading
    Not listed at that release
  3. Source
    NVD API
    What it says
    Zero records for each of the 13, and zero for a keyword search on "Container Storage Modules" among records published since 25 September
    Reading
    No NVD score exists
  4. Source
    CVE Program API
    What it says
    "CVE_RECORD_DNE" for each of the 13
    Reading
    No public CVE record yet
  5. Source
    BleepingComputer, 2 October
    What it says
    Dell has yet to flag these as actively exploited
    Reading
    Restates the advisory's silence. Secondary
  6. Source
    Public exploit code
    What it says
    I found no primary source either way. Two secondary reports say none has surfaced
    Reading
    Not verified

Dell has two entries in KEV, CVE-2021-21551 in the dbutil driver (added 31 March 2022) and CVE-2026-22769 in RecoverPoint for Virtual Machines (added 18 February 2026). Neither is CSM. That history is context, not evidence about these 13. Absence from KEV says CISA has not listed these CVEs. It does not say nobody is using them.

What to do about it, in order

Written for a UK platform or infrastructure team that runs Dell storage with Kubernetes, or depends on a supplier that does. Dell lists no workaround, so every item that goes beyond Dell's own instructions starts with the word Judgement and is not a Dell mitigation.

Take this with you

In the order worth doing

  • Find every CSM component in every cluster, including clusters the storage team built. Record each version: CSI driver pods with an authorization sidecar, the Authorization namespace (proxy, tenant, role and storage services), the operator (usually deployments named with the prefix dell-csm-operator-, and kubectl get csm -A lists what it manages) and any karavi-authorization v1 install. If you cannot find one, ask the storage team before you assume it is absent.
  • Judgement: decide today who can reach the Authorization Ingress and the proxy, tenant and storage services. List the hostname, the load balancer or node addresses, firewall and security group rules, and network policies, then allow only the driver clusters and the storage administrators' hosts. This is your own compensating control. It does not replace the patch.
  • Judgement on order: upgrade CSM Authorization first, to 1.18.0 or later, then the operator, then the drivers. Authorization goes first because its flaws need no privileges, while the operator's need a low privilege. Afterwards read the version each component reports instead of trusting the version you meant to install.
  • Rotate every JWT signing secret, as Dell advises for CVE-2026-54472, and regenerate admin and tenant tokens. Dell's documentation describes re-applying the proxy-authz-tokens secret in each driver namespace when tokens are reissued, so schedule that with the storage team. Treat any secret copied from documentation as known.
  • Judgement: treat the array administrator credentials held by CSM Authorization as possibly exposed on any instance that was reachable and unpatched. Dell does not say any were taken, but CVE-2026-63688 describes exactly that outcome. Plan to rotate them on the arrays after patching, and review array audit logs for administrator logins from any address other than the proxy.
  • Retire karavi-authorization v1. It is archived, there is no fix to wait for, and Dell's repository tells users to migrate to v2. Rotate its signing secret now and follow Dell's v1 to v2 migration guide.
  • Judgement: restrict who can create, update or patch ContainerStorageModule resources (API group storage.dell.com) to your deployment pipeline. Dell says one resource submission is enough for CVE-2026-67269, so this narrows who could try. Dell does not list it as a mitigation.
  • Judgement: search Kubernetes audit logs for creates and updates of ContainerStorageModule resources by anyone other than your pipeline, and for ClusterRoles, ClusterRoleBindings and DaemonSets you did not deploy. Absence proves little, because the advisory gives no indicators.
  • Write to Dell Support and ask four things: are 1.17.0 to 1.17.2 affected, which Authorization version holds the fixes, is CVE-2026-76105 fixed in 1.18.0 given that it names that version, and does Dell know of exploitation. Keep the reply with the risk record.
  • Re-check on a schedule: the CVE records and NVD entries, CISA KEV, and any revision of DSA-2026-448. All were empty or silent at 11:15 BST on 3 October. If a record appears with a different score, work to the higher one until Dell explains the difference.

UK note. A search restricted to the NCSC, CISA and Australian Cyber Security Centre sites on 3 October found no advisory for these CVEs. No UK-specific guidance is cited here for that reason.

The question this leaves

Dell's advisory fixes the code. It cannot say who in your estate can open a connection to it. For the service that exists to keep array passwords away from Kubernetes administrators, who has written down which networks can reach it, and when was that last tested rather than assumed?

Sources

  1. PrimaryAdvisory DSA-2026-448, revision 1.0 of 1 October 2026, read in full through a browser: every CVE, score, vector, version, the remediation table and the Workarounds and Mitigations sectionDell Technologiesaccessed 2026-10-03
  2. PrimaryCSM Authorization v2.x documentation (1.16.3 line): the proxy architecture, the services, how the proxy is exposed through an Ingress, and how admin tokens are signedDell Technologiesaccessed 2026-10-03
  3. PrimaryContainer Storage Modules Administrator Guide 1.17.0, Authorization page: the capability table and the stated purpose of keeping storage passwords in a vaultDell Technologiesaccessed 2026-10-03
  4. PrimaryCSM component and image details (1.16.3 line): the Authorization 2.4.0 version seriesDell Technologiesaccessed 2026-10-03
  5. Primarydell/csm release list: dates of 1.17.0, 1.17.1, 1.17.2 and 1.18.0, and the v1.18.0 release bodyDell Technologies (GitHub)accessed 2026-10-03
  6. Primarydell/csm-operator release list and the v1.12.0 tag commit and ClusterRole manifest, used for the operator version line and what its service account can doDell Technologies (GitHub)accessed 2026-10-03
  7. PrimaryThe archived karavi-authorization repository: archive state, last push date and the deprecation notice for CSM Authorization v1Dell Technologies (GitHub)accessed 2026-10-03
  8. PrimaryCVSS v3.1 specification, used for the definitions of Network, Adjacent, Low privileges and Scope, and for recomputing all 13 scoresFIRSTaccessed 2026-10-03
  9. PrimaryKnown Exploited Vulnerabilities catalogue, version 2026.10.02, checked for all 13 CVEs and for any CSM entryCISAaccessed 2026-10-03
  10. PrimaryNVD API lookup, repeated for all 13 CVEs: zero records for each at about 11:15 BST on 3 OctoberNIST NVDaccessed 2026-10-03
  11. PrimaryCVE record API lookup, repeated for all 13 CVEs: no record exists for any of them at the time of readingCVE Programaccessed 2026-10-03
  12. Reported byCoverage of the advisory, used as a pointer and for its headline pairing of unauthenticated admin access with root on nodesThe Hacker Newsaccessed 2026-10-03
  13. Reported byCoverage of the advisory, cited only for its statement that no public proof of concept has surfaced, which I could not verifySQ Magazineaccessed 2026-10-03
  14. Reported byCoverage of the advisory, cited only for its statement that no public proof of concept has surfaced, which I could not verifySecurityOnlineaccessed 2026-10-03
  15. Reported byCoverage of the advisory, read in a browser, used as a pointer and for its statement that Dell has yet to flag exploitationBleepingComputeraccessed 2026-10-03

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.