CVE-2026-61421: Hard-Coded JWT Signing Key in Dell CSM Authorization Enables Admin Token Forgery

Overview

Dell has disclosed CVE-2026-61421, a critical vulnerability in CSM Authorization (the karavi-authorization component of Container Storage Modules) caused by a hard-coded, publicly-known cryptographic signing key. Rated CVSS 9.8, the flaw lets an unauthenticated attacker forge valid JSON Web Tokens (JWTs) and gain administrative privileges over the storage-authorization layer.

This is one of five critical CSM vulnerabilities Dell patched together in advisory DSA-2026-448; see also CVE-2026-67269, CVE-2026-54472, CVE-2026-63688, and CVE-2026-63692.

Technical Details

How It Works

CSM Authorization issues JWTs to control which clients and tenants may access registered Dell storage systems through the module. Those tokens are cryptographically signed so that only the Authorization service itself should be able to mint valid ones.

The signing secret used to generate and validate these JWTs is hard-coded into the product rather than generated uniquely per deployment. Because the key value is identical across unpatched installations — and is effectively public once known — an attacker does not need to steal it from a specific target; they only need to know the fixed value shared by every vulnerable deployment. With that key, the attacker can craft a JWT asserting administrative privileges, present it to CSM Authorization, and be treated as a fully trusted, privileged caller.

Impact Assessment

Who Is At Risk

Any Kubernetes environment running CSM Authorization before 1.18.0, particularly:

• Deployments using CSM Authorization to broker multi-tenant access to shared Dell storage arrays (PowerStore, PowerScale, PowerFlex, PowerMax, Unity XT)
• Clusters exposing the Authorization service's API beyond trusted, cluster-internal callers

Potential Attack Chains

1. Key knowledge — Attacker obtains the hard-coded signing key (publicly documented or reverse-engineered from the shipped binary)
2. Token forgery — Attacker crafts a JWT with administrative claims and signs it using the known key
3. Privileged access — CSM Authorization accepts the forged token as legitimate, granting the attacker administrative control over tenant and storage-system access policy
4. Downstream compromise — With admin-level authorization privileges, the attacker can grant themselves access to any registered storage system, affecting every tenant relying on CSM Authorization for isolation

Combined with CVE-2026-63688's missing authentication on the underlying gRPC server, this creates a near-complete bypass of CSM's entire authorization model.

Mitigation

Immediate Actions

• Upgrade CSM Authorization to 1.18.0 or later, which replaces the hard-coded key with a properly generated, deployment-unique signing secret
• Rotate all JWT signing secrets post-upgrade, and invalidate any tokens issued prior to patching
• Restrict network access to the Authorization service's API to trusted, cluster-internal sources only as an interim measure

Detection Opportunities

• Audit Authorization service logs for tokens with administrative claims issued outside of normal provisioning workflows
• Monitor for unexpected grants of storage-system access to tenants that shouldn't hold them

Defence-in-Depth

• Never rely on vendor-shipped default secrets for any authorization boundary — verify post-upgrade that signing keys are unique per deployment
• Apply network segmentation so that CSM Authorization's API is unreachable from untrusted or multi-tenant workloads directly

Discovery & Disclosure

CVE-2026-61421 was published alongside Dell's advisory DSA-2026-448 on October 6, 2026. As of publication, there is no public proof-of-concept exploit and the flaw is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. There is no workaround short of upgrading to CSM 1.18.0 and rotating signing secrets.

References

• NVD — CVE-2026-61421
• Dell DSA-2026-448 — Security Update for Dell Container Storage Modules
• VulDB — Entry 414314