← Back to Feed CACHED · 2026-10-02 20:22:20 · CACHE_KEY CVE-2026-63688
CVE-2026-63688 · CWE-306 · Disclosed 2026-10-02

Dell CSM Authorization Storage gRPC Server Missing Authentication — Unauthenticated Admin Credential…

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Unauthenticated gRPC call dumps every storage-array admin password in your fleet"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain Kubernetes cluster network position

The attacker needs network reachability to the csm-authorization-storage gRPC service. This can come from a compromised pod (supply-chain attack on a container image, vulnerable application workload, CI runner), a misconfigured NodePort/LoadBalancer, or by chaining CVE-2026-63692 which affects the Ingress-exposed authorization proxy. In many enterprise clusters, NetworkPolicy is either absent or over-permissive, making lateral movement between namespaces trivial.
Conditions required:
  • Network access to the Kubernetes cluster where CSM Authorization is deployed
Where this breaks in practice:
  • 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
Detection/coverage: Kubernetes audit logs can capture unusual pod-to-service connections; Falco rules can flag unexpected gRPC calls to the dell-csm-authorization namespace
STEP 02

Discover the CSM Authorization storage gRPC endpoint

The attacker enumerates Kubernetes services in the cluster. The CSM Authorization deployment creates well-known service names in its namespace. Standard 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.
Conditions required:
  • Ability to perform service discovery within the cluster
Where this breaks in practice:
  • Requires at least exec access in a pod or DNS resolution capability
  • RBAC-locked clusters may restrict service enumeration
Detection/coverage: Kubernetes audit logs show unauthorized service list/get requests; network monitoring can flag port scans within the cluster
STEP 03

Send unauthenticated gRPC request to harvest credentials

The attacker crafts a gRPC request to the csm-authorization-storage service. Because the service has no authentication check (CWE-306), any well-formed request is accepted. The response contains backend administrator credentials for every registered storage array — PowerStore, PowerScale, PowerFlex, PowerMax, and Unity XT. No brute-forcing, no token theft, no privilege escalation: the service simply returns the credentials to anyone who asks.
Conditions required:
  • Network reachability to the gRPC port
  • Knowledge of the gRPC service definition (protobuf), obtainable via reflection
Where this breaks in practice:
  • None once the service is reachable — zero authentication, zero complexity
Detection/coverage: gRPC access logs (if enabled); anomalous credential-read volume in CSM audit trail; SIEM correlation of storage-admin logins from unexpected source IPs
STEP 04

Authenticate to storage arrays as administrator

With harvested admin credentials, the attacker connects directly to Dell storage management interfaces (REST APIs, PowerStore Manager, PowerScale OneFS WebUI, PowerFlex Gateway). Full administrator access grants the ability to read, modify, delete, or encrypt any volume, share, or LUN across the entire storage fleet. The attacker can also create backdoor accounts or modify replication targets to exfiltrate data.
Conditions required:
  • Network access to storage array management planes (typically on the management VLAN)
  • Valid admin credentials (obtained in step 3)
Where this breaks in practice:
  • Storage management interfaces may be on a separate management network segment
  • Jump hosts or PAM gateways may gate admin access to arrays
Detection/coverage: Storage array audit logs show new admin sessions from unexpected IPs; SIEM alerts on concurrent admin logins across multiple arrays
STEP 05

Achieve full storage infrastructure compromise

The attacker now controls all Dell storage arrays managed by this CSM instance. They can exfiltrate production databases, destroy backups stored on PowerScale/PowerStore, deploy ransomware-style volume encryption, or silently alter data. If replication is configured, the attacker can pivot to DR sites. The blast radius spans every application whose persistent volumes reside on the compromised arrays — potentially the entire Kubernetes estate and any non-containerized workloads using the same arrays.
Conditions required:
  • Completed steps 1-4
Where this breaks in practice:
  • Immutable snapshots or air-gapped backups may survive
  • Data-at-rest encryption with externally-managed keys limits plaintext exfiltration
Detection/coverage: Anomalous volume deletion or snapshot destruction; mass data-read patterns; storage capacity alerts from unexpected consumption
03 · Compensating Control

1
CRITICAL 9.3→HIGH 7.5
SEVERITY REDUCED
Apply Kubernetes NetworkPolicy to isolate the CSM Authorization namespace — Create a NetworkPolicy that restricts ingress to the csm-authorization-storage service to only the pods that legitimately need it (CSM proxy pods, CSI driver sidecars). This breaks the flat-network assumption and prevents arbitrary pods from reaching the gRPC endpoint. Deploy within the noisgate mitigation SLA of 3 days for CRITICAL severity. This does not fix the vulnerability but dramatically shrinks the reachable attack surface.
2
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Upgrade to CSM 1.18.0 immediately — This is the only vendor-supported remediation. Dell offers no workaround. Schedule the Helm chart upgrade to CSM 1.18.0 within the noisgate mitigation SLA of 3 days. Test in a staging Kubernetes cluster first, then roll to production. After upgrade, proceed immediately to credential rotation.
3
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Rotate all storage-array admin credentials and JWT signing secrets — Even after patching, assume credentials were exposed. Rotate admin passwords on every Dell storage array registered with CSM (PowerStore, PowerScale, PowerFlex, PowerMax, Unity XT). Replace all JWT signing secrets used by CSM Authorization. Audit storage-array access logs for any unauthorized admin sessions since the CSM instance was deployed. Complete within 7 days of patching.
4
CRITICAL 9.3→CRITICAL 8.5
Deploy Falco or equivalent runtime security to detect anomalous gRPC calls — Add Falco rules to detect unexpected network connections to the CSM Authorization namespace from non-whitelisted source pods. This provides detection-in-depth while patching is underway. Will not prevent exploitation but enables rapid incident response.
5
CRITICAL 9.3→HIGH 7.0
SEVERITY REDUCED
Segment storage management interfaces from the Kubernetes data plane — Place Dell storage array management interfaces (REST APIs, WebUI) on a dedicated management VLAN with strict firewall rules. Even if credentials leak, the attacker cannot use them without reaching the management plane. This is a defense-in-depth control that limits blast radius. Deploy within 3 days alongside NetworkPolicy.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot 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 availabilityNo 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 scoreNot 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 assessmentDell 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 versionsAll 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 versionCSM 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 vulnerabilitiesCVE-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 / exposureNo 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 advisoryDSA-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 researcherNot publicly attributed. Dell's advisory does not credit a specific researcher or organization.

Sources.

  1. The Hacker News — Dell CSM Flaws Enable Unauthenticated Admin Access
  2. BleepingComputer — Dell asks admins to patch max severity CSM flaws
  3. Shield53 — Dell CSM Authorization Flaws Expose Kubernetes Storage Infrastructure
  4. Security Online — Dell Patches Two CVSS 10 Flaws in Container Storage Modules
  5. Dell CSM Authorization v2.x Architecture Documentation
  6. CVEmon — CVE-2026-63688 Overview
  7. SQ Magazine — Dell Patches Two CVSS 10 Container Storage Modules Flaws
  8. Dell CSM Helm Charts (GitHub)
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.3/10)

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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously