Falhas críticas no Dell Container Storage Modules permitem acesso administrativo sem autenticação e root em nós Kubernetes

Seis vulnerabilidades, quatro delas com CVSS 9,6 ou superior, afetam todas as versões do CSM anteriores à 1.17.0; correção consolidada na versão 1.18.0 exige atualização imediata e rotação de segredos de assinatura JWT

Componente	Dell Container Storage Modules (CSM), incluindo csm-authorization-storage gRPC server, authorization proxy, tenant service, ContainerStorageModule Custom Resource reconciler, CSM Authorization module e karavi-authorization
Vetor	Atacantes remotos sem autenticação ou com privilégios baixos exploram ausência de autenticação em funções críticas, credenciais e chaves criptográficas embutidas, falha de gerenciamento de privilégios e injeção em template engine
Impacto	Controle administrativo completo sobre a infraestrutura de armazenamento das cinco famílias de produtos suportadas, acesso root em nós do cluster Kubernetes, leitura de Secrets em todo o cluster e manipulação de RBAC e políticas de armazenamento
Prioridade	Atualizar o CSM para a versão 1.18.0 imediatamente e rotacionar todos os segredos de assinatura JWT; não existem soluções alternativas
Versões	Afeta todas as versões do CSM anteriores à 1.17.0; corrigido na 1.18.0
CVEs	CVE-2026-63688 (CVSS 10.0), CVE-2026-63692 (CVSS 10.0), CVE-2026-67269 (CVSS 9,9), CVE-2026-54472 (CVSS 9,8), CVE-2026-61421 (CVSS 9,8), CVE-2026-67273 (CVSS 9,6)

Resumo técnico

A Dell divulgou correções de segurança para um conjunto de seis vulnerabilidades críticas no Dell Container Storage Modules (CSM), a suíte de módulos que integra clusters Kubernetes aos arrays de armazenamento da fabricante. As falhas afetam todas as versões do CSM anteriores à 1.17.0 e foram corrigidas na versão 1.18.0, sem qualquer solução alternativa disponível — a atualização é o único caminho de mitigação reconhecido oficialmente. Duas das falhas recebem pontuação máxima CVSS 10.0 e quatro ultrapassam 9,6, configurando um dos boletins mais graves recentes envolvendo infraestrutura de storage orquestrada em Kubernetes.

O núcleo do problema está na arquitetura de autorização do CSM. Serviços sensíveis como o servidor gRPC csm-authorization-storage, o authorization proxy e o tenant service executam funções críticas sem exigir autenticação adequada, enquanto outros componentes embarcam credenciais fixas e chaves criptográficas hard-coded, que permitem forjar tokens administrativos válidos. Somam-se a isso uma falha de gerenciamento de privilégios no reconciler do Custom Resource ContainerStorageModule e uma injeção em template engine, ampliando a superfície para comprometimento dos próprios nós do cluster.

• CVE-2026-63688 (CVSS 10.0): ausência de autenticação no servidor gRPC csm-authorization-storage permite que atacante remoto sem autenticação obtenha credenciais de administrador do backend de armazenamento de todos os arrays registrados
• CVE-2026-63692 (CVSS 10.0): ausência de autenticação no authorization proxy e no tenant service permite obter privilégios administrativos e manipular recursos de armazenamento de todos os tenants
• CVE-2026-67269 (CVSS 9,9): gerenciamento inadequado de privilégios no reconciler do Custom Resource ContainerStorageModule permite escalada para root nos nós do cluster
• CVE-2026-54472 (CVSS 9,8): credenciais hard-coded no CSM Authorization permitem forjar tokens administrativos válidos
• CVE-2026-61421 (CVSS 9,8): chave criptográfica embutida no componente JWT do karavi-authorization permite forjar tokens de autenticação
• CVE-2026-67273 (CVSS 9,6): neutralização inadequada de caracteres especiais em template engine permite escalada de privilégios, acesso a informações sensíveis e adulteração de RBAC

Fluxo técnico

A cadeia de exploração mais severa começa nas falhas de autenticação ausente. Na CVE-2026-63688, o servidor gRPC csm-authorization-storage expõe funções críticas sem verificação de identidade, o que permite a um atacante remoto não autenticado recuperar credenciais de administrador do backend de armazenamento válidas para todos os arrays registrados. A própria Dell classifica o cenário como um bypass completo do modelo de segurança do csm-authorization, concedendo controle administrativo total sobre a infraestrutura de armazenamento das cinco famílias de produtos suportadas. A CVE-2026-63692 segue lógica análoga no authorization proxy e no tenant service, com o agravante de alcançar recursos de armazenamento de todos os tenants conectados.

As falhas de material criptográfico embutido atacam a mesma arquitetura por outro caminho. Com a credencial fixa da CVE-2026-54472 e a chave de assinatura JWT hard-coded da CVE-2026-61421 — descrita como publicamente disponível —, um atacante remoto sem autenticação consegue gerar tokens administrativos criptograficamente válidos, invalidando na prática qualquer controle de acesso baseado em JWT do karavi-authorization. Já a CVE-2026-67269 ataca o controlador: um atacante remoto com privilégios baixos pode enviar um único Custom Resource manipulado ao reconciler do ContainerStorageModule e escalar até root em todos os nós do cluster, conforme alerta a própria fabricante. A CVE-2026-67273 complementa o quadro com injeção em template engine, resultando em leitura de Secrets em todo o cluster e criação de recursos RBAC cluster-scoped por atacante de baixo privilégio, burlando os controles de acesso nativos do Kubernetes.

Superfície afetada

O escopo do boletim cobre qualquer implantação do Dell CSM em versão anterior à 1.17.0 que utilize os módulos de autorização e o operator de storage em clusters Kubernetes. O impacto se estende às cinco famílias de produtos de armazenamento Dell suportadas pelo CSM, o que significa que um único serviço de autorização comprometido pode expor todos os arrays registrados, independente do tenant que os consuma. Ambientes multitenant são particularmente sensíveis às CVEs 2026-63692 e 2026-54472, que atravessam fronteiras de tenant.

Do lado do cluster Kubernetes, as CVEs 2026-67269 e 2026-67273 elevam o risco para o plano de controle e os nós de trabalho: a primeira entrega execução com root nos nós, e a segunda concede leitura cluster-wide de Secrets e a capacidade de criar objetos RBAC cluster-scoped, efeitos que persistem na configuração do cluster mesmo após a atualização do CSM se não houver revisão e contenção adequadas.

• Todas as versões do Dell CSM anteriores à 1.17.0
• Servidor gRPC csm-authorization-storage e authorization proxy do CSM
• Componente karavi-authorization e sua autenticação via JWT
• Reconciler do Custom Resource ContainerStorageModule em clusters Kubernetes
• Cinco famílias de produtos de armazenamento Dell suportadas pelo CSM

Hunting e telemetria

Equipes de defesa devem priorizar a inspeção dos logs do servidor gRPC csm-authorization-storage, do authorization proxy e do tenant service em busca de requisições bem-sucedidas sem credenciais válidas associadas, chamadas administrativas provenientes de origens fora do plano esperado de gerenciamento e consultas que retornem credenciais de backend de armazenamento. Como as falhas de autenticação ausente não geram eventos de login negado, a anomalia aparece justamente na ausência de falhas onde elas seriam esperadas.

No plano Kubernetes, convém revisar o histórico de objetos Custom Resource do tipo ContainerStorageModule em busca de submissões incomuns vindas de contas de baixo privilégio, auditorar criações recentes de ClusterRole, ClusterRoleBinding e outros recursos RBAC cluster-scoped sem justificativa operacional e verificar acessos de leitura a Secrets que rompam o padrão histórico por identidade. Vale ainda verificar a integridade dos tokens administrativos emitidos, buscando assinaturas aceitas que não correspondam a chaves rotacionadas conhecidas, e monitorar processos com root nos nós associados ao operador de storage.

• Chamadas gRPC administrativas bem-sucedidas sem identidade associada nos serviços de autorização do CSM
• Submissões do Custom Resource ContainerStorageModule por contas de baixo privilégio
• Criação inexplicada de recursos RBAC cluster-scoped
• Leitura cluster-wide de Kubernetes Secrets fora do padrão por identidade
• Tokens JWT administrativos aceitos com origem de emissão não mapeada

Mitigação

A resposta imediata é atualizar o Dell Container Storage Modules para a versão 1.18.0, que corrige as seis vulnerabilidades; a Dell afirma categoricamente que não existem workarounds ou mitigações alternativas à atualização. Em conjunto, a fabricante recomenda expressamente a rotação de todos os segredos de assinatura JWT, medida indispensável porque as chaves comprometidas pela CVE-2026-61421 e a credencial da CVE-2026-54472 são publicamente conhecidas e permitem forjar tokens administrativos válidos mesmo depois da atualização se os segredos não forem trocados.

Após a atualização e a rotação, a validação deve incluir a verificação de que nenhum token emitido com as chaves antigas ainda é aceito, a revisão de RBAC cluster-scoped criado recentemente em busca de objetos plantados por exploração prévia, a checagem das contas registradas nos serviços de autorização do CSM e o replay dos logs do período de exposição para identificar acesso não autorizado. O histórico de exploração ativa de vulnerabilidades em produtos Dell observado nos últimos anos reforça a urgência de aplicar as correções sem atraso.

• Atualizar o Dell CSM para a versão 1.18.0 em todas as instâncias
• Rotacionar todos os segredos de assinatura JWT do karavi-authorization
• Auditar recursos RBAC cluster-scoped criados recentemente no Kubernetes
• Revisar Custom Resources ContainerStorageModule por submissões anômalas
• Investigar logs dos serviços gRPC e do authorization proxy quanto a acesso não autenticado no período de exposição