Dell Told Kubernetes Teams to Install 1.18.0. That Build Still Carries a Flaw.

Dell Container Storage Modules are how the company’s storage shows up inside Kubernetes. The operator installs the pieces, the drivers present an array to the cluster, and the authorization module decides which pods may reach which storage. That last piece is where the two maximum-severity flaws live, and it is also the piece most teams treat as internal plumbing.

The advisory went out on 1 October. Six proprietary CVEs are listed, and the scores are not close to the line. Two are 10.0, one is 9.9, two more are 9.8, and the last is 9.6. Dell rates the 10.0 pair with the same vector, network reachable, low complexity, no privileges and no user interaction.

One network call returns the storage credentials for every array

CVE-2026-63688 sits in the authorization module’s storage gRPC server, which has no authentication on a critical function. An unauthenticated remote attacker can use it to read the storage backend administrator credentials for every registered array. Dell’s own note adds that success bypasses the authorization model entirely. A second flaw, CVE-2026-63692, affects the authorization proxy and the tenant service and lets an unauthenticated attacker bypass authentication and take administrative control.

Two more flaws in the same module make the recovery harder. CVE-2026-54472 and CVE-2026-61421 both involve hard-coded credentials or signing keys, so an attacker can forge a valid administrative token without brute force. Dell tells admins to rotate the JWT signing secrets immediately, which matters because a software update alone does not invalidate a token an attacker already knows how to mint.

A single custom resource buys root on the cluster nodes

The operator is the other half of the story. CVE-2026-67269 is a privilege management flaw in the reconciler for the ContainerStorageModule custom resource. A low-privileged remote attacker who can write that resource can escalate to root on the cluster nodes, and Dell notes that one submission can compromise every node in the cluster. The reconciler runs the workload, so this is a case where the control plane acts on input without checking the source.

CVE-2026-67273 is a template injection flaw at 9.6. A low-privileged attacker can read Kubernetes Secrets cluster-wide and create cluster-scoped RBAC resources. Taken together with the authorization flaws, an attacker who starts with a namespace token and no special rights can end up holding storage credentials, cluster secrets and node root.

The upgrade has a footnote, and the footnote is the point

Dell points every customer at CSM 1.18.0 and lists no workarounds. That is a clean instruction until you read the rest of the advisory. CVE-2026-76105, an insufficiently random values flaw at 7.7, affects 1.18.0. Dell also warns that the affected-product table may not include every supported version, so the build people will reach for as the all-clear is not an all-clear. eSecurityPlanet and the University of Toronto advisory both flag the same gap, and The Hacker News ran the upgrade as the headline advice.

The practical path is inventory first. CSM ships as several pieces, the operator, the storage drivers and optional modules such as Authorization, so one cluster can hold three or four version numbers at once. Check every component against the advisory rather than the top-line release, rotate the JWT signing secrets and the storage admin credentials, and treat any credential reachable from the authorization service as exposed. The nodes are the reason this cannot wait. Root on a Kubernetes node is a platform compromise, not a storage incident.

Related reading. Last week’s NetScaler patch is still vulnerable as a SAML identity provider, and an AI agent crossed from a perimeter into plant control in sixteen minutes. Both are cases where the fix arrived after the exposure.