Dell Forced To Patch Critical Flaws Carrying Highest Possible Severity Rating

Dell is contending with another round of security problems after disclosing six critical vulnerabilities in its Container Storage Modules platform, including two that carry the highest possible severity score under the Common Vulnerability Scoring System.

The flaws affect the CSM Authorization module, a component designed to act as a gatekeeper between Kubernetes applications and enterprise storage arrays. That a security-critical access control layer is itself the source of the exposure raises uncomfortable questions about the vendor’s development and review practices.

Storage infrastructure at risk

CSM is an open-source collection of Kubernetes storage components maintained by Dell. The project includes drivers for PowerStore, PowerScale, PowerFlex, PowerMax and Unity, alongside modules covering authorisation, observability, replication and resiliency.

The Authorization module sits as a proxy between a Container Storage Interface driver and the storage system. Administrators rely on it to enforce role-based permissions and storage quotas, allowing tenants to consume resources without being handed storage administrator credentials.

It is precisely this trust boundary that the disclosed vulnerabilities undermine.

Two flaws – CVE-2026-63688 and CVE-2026-63692 – each carry a CVSS score of 10.0, the maximum rating. The first exposes registered arrays’ administrator credentials through an unauthenticated gRPC service. The second bypasses authentication in the authorization proxy and tenant service entirely. Dell identifies Authorization 2.4.0 in both descriptions.

Broader cluster compromise

Four additional critical vulnerabilities broaden the scope of the problem well beyond storage access.

CVE-2026-67269, rated 9.9, permits low-privileged attackers to gain root access on cluster nodes. CVE-2026-67273, rated 9.6, enables low-privileged attackers to read Secrets across an entire cluster and create cluster-scoped role-based access control resources.

Two further flaws concern embedded authentication material and token forgery. CVE-2026-54472 and CVE-2026-61421, both rated 9.8, involve hard-coded authentication material and the ability to forge administrative tokens.

Dell had not flagged any of the issues as actively exploited at the time of publication. That distinction is relevant but offers limited comfort given the severity of the attack paths described.

Hard-coded credentials and legacy exposure

The presence of hard-coded authentication material in a product of this nature is a particular concern. Dell’s advisory recommends immediate JWT signing-secret rotation for CVE-2026-54472. A legacy issue with the karavi-authorization component also leaves deployments using the documented signing secret at risk.

Replacing vulnerable software does not, by itself, invalidate authentication material that remains trusted elsewhere in the environment. Teams assessing their exposure need to establish which systems consume each credential, how replacements will be distributed and whether existing tokens must be explicitly invalidated.

These are operational tasks that go beyond applying a patch and restarting a service.

Kubernetes Secrets in the firing line

The references to Kubernetes Secrets are consequential. These objects can hold passwords, OAuth tokens and SSH keys. A credential’s value to an attacker depends on what it unlocks, meaning the effects of disclosure may extend well beyond the workload that stores it.

The Kubernetes project’s own security guidance warns that permission to list Secrets exposes their contents and that a user able to create a pod consuming a Secret may obtain its value indirectly. Its documentation recommends encrypting Secrets at rest, limiting read permissions, using short-lived Secrets and implementing audit rules capable of identifying events such as a single user reading multiple Secrets concurrently.

For incident responders, the practical implication is to trace dependencies. If there is evidence of unauthorised access, the investigation must establish which credentials were accessible and what services accepted them. Restarting a workload would not, by itself, answer whether an external account or storage system remained accessible through stolen material.

Network assumptions under scrutiny

The distinction between unauthenticated and low-privileged attacks also affects how organisations should prioritise their response. Both network access to storage-management services and the permissions granted to users or automation inside clusters need review.

An internal deployment is not exempt from scrutiny if less-trusted workloads or accounts can reach privileged components. Kubernetes pods can communicate with one another by default. For environments requiring strict tenant isolation, the Kubernetes project recommends beginning with restrictive network policies and explicitly allowing only necessary communication.

Applied to storage infrastructure, that guidance supports checking actual connectivity rather than relying on assumptions about internal networks. Teams should verify which workloads can contact management services and whether the routes match the intended trust boundaries. Any temporary restriction should be tested against legitimate storage operations to avoid breaking production workloads.

Confusing remediation guidance

Dell lists CSM 1.18.0 or later as the path to remediation and offers no workaround. Its affected-version table states versions before 1.17.0 are affected, but component descriptions differ across the advisory, with one separate issue naming 1.18.0.

The inconsistency in Dell’s own documentation creates an unwelcome ambiguity for administrators trying to determine whether their deployments are safe. Administrators should seek clarification on their exact deployment rather than infer safety from an omitted version number.

A pattern of concern

The disclosure adds to a growing list of security headaches for Dell. The combination of two maximum-severity scores, hard-coded credentials, authentication bypasses and privilege escalation paths in a single advisory paints a troubling picture for enterprise customers who depend on Dell’s infrastructure software.

That the affected component is specifically tasked with enforcing access controls – and fails at that function in multiple distinct ways – compounds the concern.

What organisations should do now

A controlled response should begin with an accurate inventory of deployed modules, component versions and connected storage resources. Platform and Storage Administrators should coordinate the upgrade, credential changes and validation of application access. Security teams should preserve relevant logs and records and investigate unexplained administrative changes where there is reason to suspect compromise.

The Kubernetes project’s RBAC guidance recommends granting only necessary permissions, using namespace-level access where possible and avoiding wildcard permissions. It also advises limiting the distribution of powerful service-account tokens and separating privileged workloads from untrusted or publicly exposed ones.

The CVSS maximum score is a prioritisation signal, but it is not an estimate of the likelihood that any particular organisation will be attacked. FIRST’s CVSS guidance explains that base scores describe intrinsic severity and must be supplemented with exposure, threat information and environmental context when assessing risk.

For decision-makers, the immediate questions are concrete: where is the affected software running, what does it control, who can reach it and how quickly can it be patched? Answering those questions allows the response to focus on the deployments with the greatest business consequences.

Simply owning Dell equipment does not establish exposure. It is the software connecting and managing Kubernetes storage environments that administrators need to inventory. But for those running affected versions of CSM, the urgency is clear.

Last Updated on October 3, 2026 by Nick Ross