Vulnerabilities

Cybersecurity News: Dell CSM CVSS 10 Auth Bypass Flaws

Published October 4, 2026 · DNS Benchmark Pro Editorial · Reading time: 7 minutes

The most consequential cybersecurity news for platform teams this week did not involve an internet-facing VPN appliance. It involved the unglamorous plumbing underneath the cluster: the controllers that let a Kubernetes PersistentVolumeClaim become real capacity on a real storage array. Dell published advisory DSA-2026-448 on 1 October 2026, and two of the thirteen proprietary flaws in it carry a CVSS base score of 10.0 — the ceiling. Vendors reach that number rarely, and almost never twice in one document.

What Dell Container Storage Modules actually do

Container Storage Modules (CSM) is Dell’s layer on top of its Container Storage Interface drivers for PowerFlex, PowerMax, PowerStore, PowerScale and Unity XT. The CSI driver does the basic work — provision a volume, attach it to a node, take a snapshot. CSM adds the enterprise wrapper around it: observability, replication, resiliency, and the piece at the centre of this advisory, CSM Authorization, which sits between cluster tenants and the storage array and enforces per-tenant quotas and permissions.

That architecture explains the severity. CSM Authorization holds array administrator credentials so that individual tenants do not have to. It is, deliberately, a credential vault with a network listener in front of it. When the listener forgets to check who is calling, the vault is simply open.

Two perfect scores: missing authentication on the control path

Both 10.0 findings share the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Read it left to right and the picture assembles itself: network reachable, low attack complexity, no privileges required, no user interaction, scope changed, and total loss of confidentiality, integrity and availability.

The scope-changed flag is the part worth dwelling on. It means the vulnerable component and the impacted component are not the same security authority. An attacker who reaches the CSM Authorization gRPC server (CVE-2026-63688) does not merely compromise that pod; they obtain the storage administrator credentials it is holding and act directly against the array behind it. CVE-2026-63692 does the equivalent through the authorization proxy and tenant service, bypassing the controls that are supposed to keep tenant A out of tenant B’s volumes.

Dell has not described either as a zero-day vulnerability, and there are no public reports of in-the-wild abuse. That is the one piece of good news in this round of cybersecurity news, and it is a perishable one. Perfect-score authentication bypasses in enterprise infrastructure have a short grace period, and patch diffing a Go binary is not difficult work.

Hard-coded keys and the archived-component trap

The 9.8-rated pair deserve separate attention because they fail differently. CVE-2026-54472 is hard-coded credentials inside the CSM Authorization module. CVE-2026-61421 is a hard-coded cryptographic key in karavi-authorization, the archived predecessor to CSM Authorization, used to sign JSON Web Tokens.

A static JWT signing key means anyone who extracts it from a container image can mint valid tokens for any tenant, with any claim, indefinitely. Patching does not fix that on its own — tokens signed with the leaked key stay valid until the secret is rotated. Dell’s remediation note is explicit on this point, and it is the step most teams will skip. This is also a reminder that archived does not mean absent: deprecated components keep running in clusters for years because nothing forces them out.

Why cloud security teams should treat this as urgent

Three structural factors make this cybersecurity news more urgent than a routine patch note suggests.

First, exposure assumptions. CSM services are internal, so they are routinely deployed without the hardening applied to anything facing the public internet. “Network reachable” in a flat cluster means reachable from any compromised pod, any CI runner with cluster access, and any developer laptop on the management VLAN. A workload compromise that would normally be contained becomes a storage-fabric compromise.

Second, blast radius. Storage sits below the application layer. An attacker with array administrator rights can read volumes belonging to workloads they never touched, snapshot them, clone them elsewhere, or delete them. Encryption at the application layer helps; encryption configured by the array does not, because the attacker now controls the array.

Third, patch friction. Upgrading CSM means a coordinated change to drivers mediating live persistent volumes. That is a maintenance window, a change ticket, and a rollback plan — which is exactly why these upgrades slip. The gap between advisory and deployment is where exploitation lives.

What IT security teams should do with this cybersecurity news

1. Inventory CSM and CSI driver versions across every cluster, including lab and DR. Anything below 1.18.0 is in scope.
2. Rotate JWT signing secrets anywhere karavi-authorization has ever been deployed. Patching alone leaves forged tokens valid.
3. Apply NetworkPolicy to the storage namespace. The authorization gRPC endpoint should accept connections from the CSI driver pods and nothing else. This single control downgrades a 10.0 to something far less interesting.
4. Audit array credentials held by CSM and reduce their rights to the minimum the drivers actually need.
5. Hunt retrospectively — unexpected snapshot or clone operations, new array admin sessions, and authorization-service connections from pods outside the storage namespace.

The DNS security angle: watching east-west and egress paths

None of this is a DNS flaw. But the way an attacker moves after a storage-fabric compromise runs straight through name resolution, which is why a DNS security posture belongs in the response plan. Pods find the CSM authorization service by its cluster DNS name; an attacker enumerating the storage namespace generates service-discovery queries that look nothing like normal application traffic. Cluster DNS query logs are a cheap, high-signal detection surface that most teams never read.

The same applies on the way out. Bulk data taken from a storage array has to cross an egress boundary, and port 53 to the internal resolver is the rule that nobody removes. A steady stream of long, high-entropy subdomain labels to a single zone is not ordinary traffic — it is a tunnel. Knowing the baseline, including the network latency profile of your resolvers, is what makes the anomaly visible at all.

Running our free DNS benchmark and network diagnostic tool from the segment that hosts your control plane answers two questions at once: which resolvers actually answer for that segment, and whether their response profile has shifted in a way consistent with interception. Where policy permits, moving upstream resolution to authenticated encrypted transport closes the easiest tampering path — our guide to DNS over HTTPS and DNS over TLS covers the trade-offs, including the visibility you surrender and how to keep it with an internal DoH endpoint.

Industry impact: the infrastructure layer is the new edge

Set this alongside the FortiMail zero-day we covered on 2 October. That was a classic perimeter story: an internet-facing appliance, exploited before a fix existed. The Dell advisory is the opposite shape — an internal component, patched before anyone attacked it, protected mainly by the assumption that nothing hostile is already inside the cluster. Both end in the same place if that assumption fails.

The broader pattern in this year’s cybersecurity news is that the valuable targets have moved below the application. Authorization proxies, operators, admission controllers and storage drivers run with enormous privilege, are rarely reviewed, and are almost never segmented from the workloads they serve. A perfect CVSS score on a component most security teams cannot name is a reasonable summary of where enterprise risk now sits.

Dell did the hard part: found the flaws, scored them honestly, and shipped a fix. What happens next is a scheduling problem, not a technical one — and scheduling problems are the ones that turn an advisory into an incident.

Sources

• Dell — DSA-2026-448: Security Update for Dell Container Storage Modules Multiple Vulnerabilities
• BleepingComputer — Dell asks admins to patch max severity CSM flaws as soon as possible
• SC Media — Dell patches critical vulnerabilities in container storage modules
• SecurityOnline — Dell patches two CVSS 10 flaws in Container Storage Modules

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The Dell headquarters photograph is by Tim Patterson, licensed CC BY 2.0, via Wikimedia Commons; the Dell Technologies logo is a public-domain reproduction of an official corporate mark, via Wikimedia Commons; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated. DNS Benchmark Pro is not affiliated with Dell Technologies.