Dell CSM 六个严重漏洞：一次完整的补丁 + 轮换应急演练

Dell 给 Container Storage Modules（CSM）发了紧急安全更新，六个严重漏洞，两个 CVSS 满分 10.0。如果你在用 Dell 存储对接 Kubernetes，这是要立刻动起来的级别。

六个漏洞分别是什么

• CVE-2026-63688（CVSS 10.0）：CSM Authorization 的 storage gRPC 服务缺少关键函数的身份验证，未认证的远程攻击者能拿到已注册存储阵列的管理员凭据。CWE-306。
• CVE-2026-63692（CVSS 10.0）：授权代理与租户服务，可绕过认证跨租户获取管理权限。
• CVE-2026-67269（CVSS 9.6-9.9）：ContainerStorageModule 自定义资源 reconciler 的权限管理问题，低权限攻击者提交一个自定义资源就可能拿下集群所有节点。
• CVE-2026-54472：硬编码凭据，可伪造 CSM Authorization 代理的管理员令牌。
• CVE-2026-61421：已归档的 karavi-authorization 项目的 JWT 认证组件，签名密钥在公开文档里能查到，知道它就能签出合法令牌。
• CVE-2026-67273：模板引擎注入，成功后可集群范围读取 Kubernetes Secrets，还能创建集群级 RBAC 资源。

影响范围 CSM 1.17.0 之前的版本受影响，修复版本是 1.18.0 及以上。涉及的存储平台包括 PowerStore、PowerScale、PowerFlex、PowerMax 和 Unity XT。目前没有公开的在野利用证据。

官方说没有缓解方案，只能升级。 这句话要当真——别指望靠网络策略糊弄过去。

完整的处置清单

1. 立刻升级 CSM 到 1.18.0 或更高。
2. 用 NetworkPolicy 和防火墙把 gRPC 管理接口从不可信网络隔离出去——这是补丁之外的纵深防御，不是替代。
3. 扫描集群里所有暴露的 CSM 相关 gRPC 端口。
4. 轮换 JWT 签名密钥。用了 CSM Authorization 或老的 karavi-authorization 的必须做，因为 61421 那条是签名密钥公开导致的令牌伪造，光打补丁不换密钥等于门还开着。
5. 审查 Kubernetes API 审计日志和网络流量日志，找异常的 gRPC 调用。
6. 检查集群里有没有可疑的集群级 RBAC 资源被创建过。

为什么要把这当成一次演练 这个漏洞组合很典型：一个是认证缺失，一个是硬编码凭据，一个是密钥泄露，一个是模板注入，最后一个是权限提升。一次事件里同时出现四类完全不同的错误，说明问题不在某个实现细节，而在整个组件的威胁建模没做。

我的判断：把这次当成一次完整的应急响应演练来做，别只打补丁。补丁 + 密钥轮换 + 日志审查 + RBAC 复查这四件事一起做，做完写一份复盘。下次再出类似的事，你手上有现成的清单。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

补丁和轮换演练一起做才完整。很多团队只打补丁但不轮换凭据，等于默认已被拿到的东西继续有效，这一步最容易被省掉，也最致命，建议提前把轮换窗口排进计划。

两个 CVSS 10.0 且能直接拿到存储阵列管理员凭据，这个等级已经不是排期问题了。我的处理顺序是先确认 CSM Authorization 组件有没有暴露在业务网段，然后立刻轮换所有已注册阵列的凭据，最后才安排补丁窗口。轮换这步很多人会漏，因为补丁打完不代表之前泄露的凭据自动失效。

两个 CVSS 满分且是未认证远程，这种组合没有缓冲时间。存储阵列的管理员凭据被拿走意味着攻击面从容器扩到整个存储层，能读也能删。补丁之外建议把轮换做全：服务账号、gRPC 证书、还有 Kubernetes 里存的 Secret，很多人只改密码就以为完事了。