Someone left the master key cabinet wide open inside your server room, and it holds every storage safe combination you own
CVE-2026-63688 is a missing-authentication flaw (CWE-306) in the csm-authorization-storage gRPC server shipped with Dell Container Storage Modules (CSM), the Kubernetes-native orchestration layer that connects Dell enterprise storage arrays — PowerStore, PowerScale, PowerFlex, PowerMax, and Unity XT — to containerized workloads. All CSM versions prior to 1.18.0 are affected. An unauthenticated attacker who can reach the gRPC endpoint can issue a single request that returns backend administrator credentials for every registered storage array. No token, no certificate, no user context — the service simply hands over the keys. This is accompanied by a companion flaw, CVE-2026-63692 (also CVSS 10.0), which strips authentication from the externally-exposed authorization proxy and tenant service, widening the reachable attack surface.
Dell assigned CVSS 10.0, and that score is directionally correct for the raw impact: unauthenticated credential disclosure for every managed storage backend is about as bad as it gets. The slight downward pressure comes from the fact that the gRPC storage service runs as a ClusterIP inside Kubernetes — it is not directly internet-routable in most deployments. An attacker needs either a foothold inside the cluster (compromised pod, container escape, CI/CD pivot) or must chain CVE-2026-63692 to punch through the Ingress-exposed proxy first. That said, Kubernetes cluster networks are notoriously flat, and any compromised workload in the same namespace or a pod with permissive NetworkPolicy can reach the service trivially. Dell offers no workaround — the only remediation is upgrading to CSM 1.18.0 and rotating every credential the service ever stored.
5 steps from start to impact.
Obtain Kubernetes cluster network position
- Network access to the Kubernetes cluster where CSM Authorization is deployed
- Service is typically ClusterIP, not internet-facing
- Requires prior foothold inside the cluster OR chaining CVE-2026-63692
- Well-configured NetworkPolicy would restrict cross-namespace traffic
Discover the CSM Authorization storage gRPC endpoint
kubectl get svc or DNS probing (csm-authorization-storage.<namespace>.svc.cluster.local) reveals the endpoint. Even without kubectl access, gRPC reflection or port scanning within the cluster exposes the service.- Ability to perform service discovery within the cluster
- Requires at least exec access in a pod or DNS resolution capability
- RBAC-locked clusters may restrict service enumeration
Send unauthenticated gRPC request to harvest credentials
- Network reachability to the gRPC port
- Knowledge of the gRPC service definition (protobuf), obtainable via reflection
- None once the service is reachable — zero authentication, zero complexity
Authenticate to storage arrays as administrator
- Network access to storage array management planes (typically on the management VLAN)
- Valid admin credentials (obtained in step 3)
- Storage management interfaces may be on a separate management network segment
- Jump hosts or PAM gateways may gate admin access to arrays
Achieve full storage infrastructure compromise
- Completed steps 1-4
- Immutable snapshots or air-gapped backups may survive
- Data-at-rest encryption with externally-managed keys limits plaintext exfiltration
- Kubernetes RBAC alone — RBAC controls API server access, not pod-to-pod network traffic. An attacker in a compromised pod bypasses RBAC entirely when making direct gRPC calls to the storage service.
- WAF / Ingress-level filtering — The vulnerable gRPC service is a ClusterIP, not behind the Ingress. WAF rules on the Ingress controller do not intercept intra-cluster traffic to the storage gRPC endpoint.
- Pod Security Standards / OPA Gatekeeper — These enforce pod admission policies (no privileged containers, no host networking) but do not restrict what network calls a running pod can make to other services within the cluster.
- Rotating only the JWT secrets without patching — New secrets are immediately re-exposed via the same unauthenticated gRPC endpoint. The leak is continuous, not a one-time disclosure.
The supporting signals.
| In-the-wild exploitation | Not observed. Dell states no active exploitation has been detected. Not listed in CISA KEV. Disclosed October 2, 2026 — only 1 day old at time of assessment. |
|---|---|
| Proof-of-concept availability | No public PoC. No exploit code found on pocindex.io, GitHub, ExploitDB, or Nuclei templates as of October 3, 2026. No CVE-specific repos on GitHub. Given the simplicity of the flaw (unauthenticated gRPC call), weaponization is trivial once the protobuf service definition is reverse-engineered from the container image. |
| EPSS score | Not yet scored. FIRST EPSS API returns no data — CVE was published <48 hours ago. Expect rapid EPSS climb once NVD enrichment and initial scanning data feed in, given the CVSS 10.0 base and zero-complexity exploitation. |
| CVSS assessment | Dell self-assigned CVSS 10.0. Implied vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. All metrics at maximum — network-accessible, no privileges, no interaction, changed scope (impacts storage arrays beyond the vulnerable component), full CIA impact. |
| Affected versions | All Dell CSM versions prior to 1.17.0 (CSM Authorization module). Some sources reference CSM Authorization 2.x series. Affects all five supported Dell storage families: PowerStore, PowerScale, PowerFlex, PowerMax, Unity XT. |
| Fixed version | CSM 1.18.0 (released October 1, 2026). No workaround available — upgrade is the only remediation. Post-patch: rotate all JWT signing secrets and replace all stored storage-array admin passwords. |
| Companion vulnerabilities | CVE-2026-63692 (CVSS 10.0) — missing authentication in the authorization proxy and tenant service (Ingress-exposed). Also fixed in 1.18.0. Additional CSM CVEs in the same advisory (DSA-2026-448): CVE-2026-67269, CVE-2026-54472, CVE-2026-61421, CVE-2026-67273. |
| Scanning / exposure | No GreyNoise, Shodan, or Censys tags specific to this CVE yet. The CSM Authorization Proxy Server is exposed via Ingress controller (NGINX or OpenShift Router) by design. The vulnerable gRPC storage service is typically ClusterIP-only. Dell PowerScale CSI driver alone has >5 million container image pulls, indicating a large installed base. |
| Vendor advisory | DSA-2026-448, published October 1, 2026. Dell rates both lead CVEs as Critical. Advisory link not indexed on dell.com search yet — referenced in BleepingComputer and The Hacker News. |
| Reporting researcher | Not publicly attributed. Dell's advisory does not credit a specific researcher or organization. |
Sources.
- The Hacker News — Dell CSM Flaws Enable Unauthenticated Admin Access
- BleepingComputer — Dell asks admins to patch max severity CSM flaws
- Shield53 — Dell CSM Authorization Flaws Expose Kubernetes Storage Infrastructure
- Security Online — Dell Patches Two CVSS 10 Flaws in Container Storage Modules
- Dell CSM Authorization v2.x Architecture Documentation
- CVEmon — CVE-2026-63688 Overview
- SQ Magazine — Dell Patches Two CVSS 10 Container Storage Modules Flaws
- Dell CSM Helm Charts (GitHub)
Why this verdict
- Zero-authentication credential dump: The gRPC service requires no token, certificate, or session — any network-reachable caller gets admin passwords for every storage array. This is the lowest-friction credential harvest possible once the service is reachable.
- Canonical high-value role — storage credential vault: CSM Authorization is, by definition, a centralized credential store for enterprise storage infrastructure. It is functionally equivalent to a PAM/secrets-manager for Dell arrays. ≥90% of CSM Authorization deployments exist specifically to manage production storage credentials, making this a high-value-role component by definition. The blast radius is fleet-scale: all arrays, all data.
- Flat Kubernetes networks erase the ClusterIP friction: While the gRPC service is not internet-facing, most enterprise Kubernetes clusters lack granular NetworkPolicy enforcement. Any compromised pod — from a vulnerable application, a poisoned container image, or a CI/CD runner — gains immediate reachability. The companion CVE-2026-63692 on the Ingress-exposed proxy further lowers the bar.
- No workaround available: Dell explicitly states there is no mitigation short of upgrading to 1.18.0. You cannot firewall the service without breaking CSM functionality. You cannot add authentication without the patched version.
- Role multiplier: CSM Authorization manages admin credentials for PowerStore, PowerScale, PowerFlex, PowerMax, and Unity XT arrays. In its canonical deployment role (production Kubernetes storage orchestration), compromise yields admin access to the entire storage fleet. Blast radius: cluster → all storage arrays → all production data → potential DR/replication site pivot. This is supply-chain-scale impact on the data layer. The floor is CRITICAL.
Why not higher?
The reassessed score of 9.3 is already within the CRITICAL band. A full 10.0 would require confirmed internet-facing exposure as a default configuration. The gRPC storage service defaults to ClusterIP (not directly routable from the internet), and while the companion CVE-2026-63692 opens an Ingress path, this assessment covers CVE-2026-63688 alone. No active exploitation or public PoC exists yet, which slightly tempers urgency versus a confirmed-weaponized 10.0.
Why not lower?
Any score below 9.0 would require evidence that the gRPC service is unreachable in practice or that the credential exposure is limited. Neither is true: Kubernetes cluster networks are flat by default, any compromised pod can reach the service, and the credential dump covers all arrays — not a subset. CSM Authorization is by definition a high-value credential store; the floor for this component class is CRITICAL regardless of network position friction. The absence of a workaround further blocks any downgrade.
Crowdsourced verification payload.
Run this script from any host with kubectl access to the Kubernetes cluster where Dell CSM is deployed. Requires read access to the dell-csm or authorization namespace (adjust CSM_NAMESPACE if your deployment uses a custom namespace). Invoke: bash check_csm_cve_2026_63688.sh. No elevated cluster privileges needed — only get on deployments and pods.
#!/usr/bin/env bash
# check_csm_cve_2026_63688.sh
# Checks whether Dell CSM Authorization is vulnerable to CVE-2026-63688
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
set -euo pipefail
# Adjust namespace if your CSM deployment uses a different one
CSM_NAMESPACES=("dell-csm" "authorization" "csm-authorization" "dell-csm-operator")
FIXED_VERSION="1.18.0"
FOUND=false
version_gte() {
# Returns 0 if $1 >= $2 using sort -V
[ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}
echo "[*] CVE-2026-63688 — Dell CSM Authorization Storage gRPC Missing Authentication"
echo "[*] Fixed in CSM >= ${FIXED_VERSION}"
echo ""
# Check kubectl connectivity
if ! kubectl cluster-info &>/dev/null; then
echo "[!] Cannot connect to Kubernetes cluster."
echo "UNKNOWN"
exit 2
fi
for NS in "${CSM_NAMESPACES[@]}"; do
# Check if namespace exists
if ! kubectl get namespace "$NS" &>/dev/null; then
continue
fi
# Look for CSM authorization-related deployments
DEPLOYS=$(kubectl get deployments -n "$NS" -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.template.spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' 2>/dev/null || true)
if [ -z "$DEPLOYS" ]; then
continue
fi
while IFS=$'\t' read -r DEPLOY_NAME IMAGES; do
# Match CSM authorization images
if echo "$IMAGES" | grep -qiE 'csm-authorization|dell/csm'; then
FOUND=true
echo "[*] Found CSM deployment: $DEPLOY_NAME in namespace $NS"
for IMG in $IMAGES; do
if echo "$IMG" | grep -qiE 'csm-authorization|dell/csm'; then
# Extract version tag
TAG=$(echo "$IMG" | grep -oE ':[^:]+$' | tr -d ':' || echo "unknown")
echo "[*] Image: $IMG"
echo "[*] Detected version tag: $TAG"
# Clean version string (remove leading v)
CLEAN_TAG=$(echo "$TAG" | sed 's/^v//')
# Check if it looks like a version
if echo "$CLEAN_TAG" | grep -qE '^[0-9]+\.[0-9]+'; then
if version_gte "$CLEAN_TAG" "$FIXED_VERSION"; then
echo ""
echo "PATCHED — CSM version $CLEAN_TAG >= $FIXED_VERSION"
exit 0
else
echo ""
echo "VULNERABLE — CSM version $CLEAN_TAG < $FIXED_VERSION"
echo "[!] Upgrade to CSM $FIXED_VERSION immediately."
echo "[!] Post-patch: rotate JWT secrets and all storage-array admin passwords."
exit 1
fi
else
echo "[!] Could not parse version from tag: $TAG"
fi
fi
done
fi
done <<< "$DEPLOYS"
done
if [ "$FOUND" = false ]; then
echo "[*] No Dell CSM Authorization deployment found in checked namespaces."
echo "[*] Checked: ${CSM_NAMESPACES[*]}"
echo "[*] If CSM is deployed in a custom namespace, set CSM_NAMESPACES."
echo ""
echo "UNKNOWN"
exit 2
fi
echo ""
echo "UNKNOWN — Found CSM artifacts but could not determine version."
exit 2