Dell Named 1.18.0 As The Fix. One Of The Flaws Is Filed Against 1.18.0.

On 1 October Dell published security advisory DSA-2026-448 for Container Storage Modules, the software layer that connects its enterprise storage arrays to Kubernetes clusters. The advisory lists thirteen Dell proprietary vulnerabilities. Six are critical. Two carry a CVSS base score of 10.0, the maximum the scale allows, both for missing authentication on functions that sit in front of storage administrator credentials. The Workarounds and Mitigations section reads, in full, "None".

That is the version of this story already in circulation, and it is accurate. The more useful finding is in the table underneath it.

Dell names the affected versions as those prior to 1.17.0, and the remediated version as 1.18.0 or later. One of the thirteen flaws is recorded against 1.18.0 itself. Every one of the six critical entries identifies a component version rather than a bundle version: CSM Authorization 2.4.0, CSM Operator 1.12.0, Container Storage Modules 1.12.0. And the advisory carries Dell's own caution that the table "may not be a comprehensive list of all affected supported versions".

So the question a board will ask this week, whether the organisation is exposed, cannot be answered from this advisory. That is not a patching problem. It is an inventory problem, and it has been sitting in the gap between the storage team and the platform team for as long as both have existed.

What happened

• 21 May 2026Dell publishes DSA-2026-234, covering CVE-2026-40710, a use of hard-coded credentials vulnerability in Container Storage Modules at CVSS 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Affected are CSM Operator 1.6.0 through 1.16.3 and CSM Helm Charts 1.11.0 through 1.16.3. The remediated version is 1.17.0 or later. Belgium's Centre for Cybersecurity issued an advisory on it on 28 May.
• 18 June 2026Dell publishes DSA-2026-259, covering CVE-2026-40711, an OS command injection in the CSI drivers at CVSS 8.0, remediated in driver versions 2.17.0 and 1.15.2. Included here because it establishes the cadence rather than because it carries the same weight.
• 1 October 2026Dell publishes DSA-2026-448 at revision 1.0. Thirteen proprietary CVEs alongside third party component fixes. The six critical are CVE-2026-63688 and CVE-2026-63692 at 10.0, CVE-2026-67269 at 9.9, CVE-2026-54472 and CVE-2026-61421 at 9.8, and CVE-2026-67273 at 9.6. Affected versions are stated as those prior to 1.17.0, remediation as 1.18.0 or later. Workarounds and Mitigations: "None".
• 2 October 2026The advisory is picked up by the security press. Dell's advisory makes no statement about exploitation in either direction, names no victim and publishes no indicators.
• 5 October 2026Four days on, the advisory remains at revision 1.0 and the affected products table, the remediation version and the "None" in the mitigations section are unchanged. No national authority advisory has followed. None of the six critical CVE identifiers has a published record in the CVE Program or the National Vulnerability Database, which is also still true of Dell's May CSM identifier more than four months on. Secondary coverage dated 4 October reports no public exploitation, no proof of concept code and no CISA Known Exploited Vulnerabilities listing.

The two at maximum severity, and what they reach

CVE-2026-63688 sits in CSM Authorization 2.4.0, specifically the csm-authorization-storage gRPC server. Dell describes it as a missing authentication for critical function flaw permitting an unauthenticated remote attacker to obtain unauthorised access to storage backend administrator credentials. Its vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

The element of that vector worth a board's attention is S:C, a changed scope. In CVSS terms it means the impact does not stop at the vulnerable component. Here the component is a credential broker, so what lies beyond it is the arrays themselves. The credentials are not a route to one system. They are the administrative credentials for the registered storage backends.

CVE-2026-63692 carries the same score, the same vector and the same component, and permits an unauthenticated network attacker to bypass authentication controls outright.

Two further criticals are forged token flaws, and the distinction between them matters operationally. CVE-2026-54472 at 9.8 is a use of hard-coded credentials issue in CSM Authorization 2.4.0 that Dell says allows a remote unauthenticated attacker to forge cryptographically valid administrative tokens. CVE-2026-61421, also 9.8, is a hard-coded cryptographic key: Dell's wording is that an attacker "who knows this publicly available signing secret could forge authentication tokens". That one sits in karavi-authorization, which Dell records as archived and no longer actively maintained. There is no upgrade path inside a component that is no longer developed.

The remaining two require a foothold. CVE-2026-67269 at 9.9 is an improper privilege management flaw in CSM Operator 1.12.0, and CVE-2026-67273 at 9.6 is a template engine injection in Container Storage Modules 1.12.0 granting cluster-wide read access to Kubernetes Secrets. Both carry PR:L in their published vectors, meaning a low privileged attacker rather than an unauthenticated one.

One point of precision, because it is being reported loosely. At least one widely read account described the privilege escalation flaw as exploitable without privileges. Dell's own published vector for CVE-2026-67269 is PR:L. Where a vendor's vector and a secondary account disagree, the vector governs, and the difference is not academic: it changes whether this is an internet facing exposure or a lateral movement one.

Three of the six criticals are recorded against CSM Authorization 2.4.0, and one against a component Dell has archived. Neither number appears in a release note.

Why this one is different

Most critical advisories ask an organisation to schedule work. This one asks it to answer a question first, and then declines to supply the information needed to answer it.

Consider an organisation that did everything right in May. DSA-2026-234 named a CVSS 10.0 hard-coded credentials flaw and told it to move to 1.17.0. It moved to 1.17.0. Four months later DSA-2026-448 names affected versions as those prior to 1.17.0, and remediation as 1.18.0 or later. On the face of the table, 1.17.0 is named neither as affected nor as remediated. It sits in a gap, and the advisory's own completeness caution means that gap cannot be read as safety.

Underneath that, the six critical entries point at component versions that most organisations do not track at all. CSM Authorization 2.4.0 is not a number that appears in a bundle release note. An asset register that records the storage array, its firmware and the Kubernetes distribution will very often record nothing about the authorization module brokering credentials between them. So a status report saying the estate is on the current CSM release is not an answer to this advisory, and three of the six criticals are not addressed by that sentence at all.

Then there is the line that removes the usual fallback. Where a vendor cannot ship a fix immediately it normally offers a compensating control: disable a feature, restrict an interface, segment a network. Dell's Workarounds and Mitigations section for DSA-2026-448 reads "None". Patching is the only remedy on offer, which means the inventory work is not a parallel task to be done later. It is on the critical path.

Four accurate statements from one advisory that do not combine into an answer. The mitigations section reads None, so the inventory work is on the critical path.

The pattern is the finding

Two maximum severity failures in the same subsystem, five months apart, both turning on secrets that should never have shipped. In May it was credentials exposed in public source repositories. In October it is hard-coded credentials and a hard-coded cryptographic key whose signing secret Dell describes as publicly available. Our assessment, offered as an assessment rather than a vendor finding, is that this is a recurring secrets management weakness in the CSM authorization layer rather than two unrelated events.

That matters commercially for one reason. If the reading is right, the correct response is not a patch cycle. It is a decision about whether this component belongs in the critical path of the storage estate at all, and what assurance the organisation requires from the vendor before the next advisory. That is a procurement conversation, and it happens at a level above the team that will be asked to run the upgrade.

The commercial exposure for UK organisations

Regulatory. A storage array is not a system that holds a copy of the data. It holds the data. If an organisation cannot exclude unauthorised access to the administrative credentials for its storage backends, it is in the territory where UK GDPR Article 33 has to be assessed. Inability to exclude compromise is not in itself a notifiable breach; it is the trigger to investigate promptly. The clock starts when the controller has a reasonable degree of certainty that a breach has occurred, and from that point a notifiable breach must be reported to the ICO without undue delay and, where feasible, within 72 hours. Operators of essential and digital services face a parallel question under the UK NIS Regulations, entities in scope of NIS2 face their own notification duties, and financial entities face DORA's major ICT incident reporting. The Cyber Security and Resilience Bill remains before Parliament and is not yet law. Nothing here is legal advice, and whether any obligation is engaged turns on facts not visible from outside.

Financial. The upgrade itself is ordinary work. The cost sits in two places the security budget rarely names. The first is establishing component level exposure across a Kubernetes estate, which is manual in most organisations because the data was never collected. The second applies to anyone still running karavi-authorization: an archived component with no in-project upgrade path is a migration, with its own design, testing and window, and it cannot be closed by a patch at all.

Contractual. Enterprise security schedules and data processing agreements increasingly commit a supplier to two things this advisory tests directly: notification of critical vulnerabilities affecting systems that process customer data, within a defined window, and the maintenance of an accurate asset inventory. An organisation that cannot map a vendor advisory onto its own estate within that window has a contractual problem as well as a technical one, and the window usually runs from publication rather than from the point the organisation worked out what it runs.

Governance. The gap this advisory exposes is specific and common. The storage array has an owner. The Kubernetes platform has an owner. The authorization module that issues storage credentials to workloads frequently has neither, because it was installed as part of a storage integration and is operated as part of a platform. When an advisory lands on it, the first hour goes on establishing who answers.

What leaders should do now

1. Ask for component versions, not a release number. The answer this advisory requires is three separate numbers: the CSM Authorization version, the CSM Operator version and the Container Storage Modules release. A report that the estate is on the latest CSM version does not address three of the six critical flaws, because they are recorded against components tracked independently of it.
2. Treat 1.17.x as unresolved until Dell states otherwise. Affected is given as prior to 1.17.0 and remediation as 1.18.0 or later, which leaves 1.17.x unaddressed on the face of the table, and Dell cautions that the table may not be comprehensive. Anyone who upgraded to 1.17.0 for the May advisory should plan on moving again rather than reading silence as coverage.
3. Find karavi-authorization and decide its future this quarter. It is archived and no longer actively maintained, and it shipped a signing secret Dell describes as publicly available. This is the one item on the list that a patch cannot resolve, so it needs an owner, a replacement and a date rather than a ticket.
4. Name an owner for the storage control plane. Not the array, and not the cluster. The credential and authorization layer between them, with a named individual, an inventory obligation and a place in the vulnerability management process. Most organisations will find this is the first time anyone has been asked.
5. Re-read the advisory on the morning you act. DSA-2026-448 is at revision 1.0 and states that the affected products table may be updated as more information becomes available. Acting on a four day old copy of a table the vendor has told you is provisional is an avoidable way to be wrong.

Three actions for this week, and two that decide how the next advisory of this shape lands.

Three questions for the board

1. When a vendor publishes a maximum severity advisory against a component rather than a product, how long does it currently take us to establish whether we run that component, and who produces that answer?
2. Which systems in our estate issue administrative credentials to other systems, and does any one person own that list?
3. When a vendor offers no mitigation at all, what is our standard for deciding between accelerating the upgrade, isolating the component and removing it, and who signs that decision?

The strategic takeaway

The industry measures vulnerability management in time to patch. It is the wrong clock for an advisory like this one. The upgrade here is not difficult. What is difficult, and what almost every organisation will discover this week, is the step before it: establishing what you run, at a level of detail the vendor's advisory assumes you already hold.

That capability has a value well beyond this advisory. The same component level inventory answers the enterprise buyer's security questionnaire, the ISO 27001 assessor's question about asset management, the insurer's proposal form and the regulator's question after an incident. Organisations tend to build it four times, badly, under four different deadlines.

Built once, with an owner, it stops being a cost of compliance and becomes the thing that lets a company answer a hard question in an afternoon while its competitors spend a fortnight on it. That is the difference between a security function that absorbs budget and one that shortens sales cycles.

Confidence note

Confirmed. From Dell security advisory DSA-2026-448, revision 1.0 dated 1 October 2026, read directly and re-checked on 5 October 2026 when it remained at revision 1.0: that it covers Dell Container Storage Modules; that the affected products table gives affected versions as "Versions prior to 1.17.0" and remediated versions as "Version 1.18.0 or later"; that the table carries the caution that it "may not be a comprehensive list of all affected supported versions and may be updated as more information becomes available"; that the Workarounds and Mitigations section reads "None"; and that the six critical CVEs are CVE-2026-63688 at 10.0 and CVE-2026-63692 at 10.0, both missing authentication for critical function in CSM Authorization 2.4.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CVE-2026-67269 at 9.9, improper privilege management in CSM Operator 1.12.0 at PR:L, CVE-2026-54472 at 9.8, use of hard-coded credentials in CSM Authorization 2.4.0 permitting forged administrative tokens, CVE-2026-61421 at 9.8, use of a hard-coded cryptographic key in karavi-authorization which Dell records as archived and no longer actively maintained, and CVE-2026-67273 at 9.6, template engine injection in Container Storage Modules 1.12.0 granting cluster-wide read access to Kubernetes Secrets at PR:L. Also from the same advisory: that CVE-2026-76105 at 7.7 is recorded against version v1.18.0. From DSA-2026-234, dated 21 May 2026: CVE-2026-40710 at CVSS 10.0, use of hard-coded credentials, CSM Operator 1.6.0 to 1.16.3 and CSM Helm Charts 1.11.0 to 1.16.3 affected, remediated in 1.17.0. From DSA-2026-259, dated 18 June 2026: CVE-2026-40711 at CVSS 8.0, OS command injection, remediated in 2.17.0 and 1.15.2. That CSM supports the PowerStore, PowerScale, PowerFlex, PowerMax and Unity XT platforms is reported by BleepingComputer on 2 October rather than stated in the advisory, which identifies components rather than platforms.

Assessed. That the May and October advisories together indicate a recurring secrets management weakness in the CSM authorization layer rather than two unrelated events is a Garzon Cyber Solutions assessment. So is the judgement that most asset registers do not record component versions at this level, which is drawn from how these estates are typically run rather than from survey data, and the argument that the correct response includes a procurement question rather than only an upgrade. The reading of S:C as placing the storage backends beyond the vulnerable component's boundary follows the CVSS specification and Dell's own description of the flaw, but Dell does not state it in those terms. The commercial, contractual and governance arguments in this briefing are judgements rather than findings.

Not known. Whether any of these flaws has been exploited. Dell's advisory makes no statement in either direction, publishes no indicators and names no victim, and we have found no public proof of concept as at 5 October; silence from a vendor is not evidence of absence. Whether any of the six has been added to the CISA Known Exploited Vulnerabilities catalogue. The catalogue page and its feed did not return to us on checking, so we have not verified this directly; secondary coverage dated 4 October reports that they are not listed, and we repeat that as a report rather than as our own finding. Whether 1.17.x is affected, which the advisory does not resolve. Whether a UK, EU or other national authority advisory follows; none had been published four days after the vendor release, and national roll-ups commonly run a week or more behind, so absence today should not be read as a judgement on severity. The exact total of proprietary CVEs in the advisory, which we read as thirteen and describe as such, though a reader counting the third party component entries alongside them will arrive at a larger figure. None of the six critical identifiers had a published CVE Program or NVD record as at 5 October, which on the evidence of Dell's May identifier reflects publication lag rather than anything about the flaws. Nothing here is legal advice.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and Americas. We are a young firm and we publish our own research. Founder Jonathan Garzon spent his career selling cybersecurity, compliance and technology to security and technology buyers, working alongside marketing and technical colleagues, before building GCS around a single argument: delivered in the right order, security, compliance and the people to sustain them stop being three cost lines and become one commercial capability.