Dell corrige dos vulnerabilidades críticas CVSS 10.0 en Container Storage Modules para Kubernetes

Qué pasó

Dell Technologies publicó el 1 de octubre de 2026 el advisory DSA-2026-448, una actualización de seguridad que cubre 13 vulnerabilidades en sus Container Storage Modules (CSM), el software que conecta sus arreglos de almacenamiento empresarial (PowerStore, PowerScale, PowerFlex, PowerMax y Unity XT) con clusters de Kubernetes.

Dos de los CVEs tienen CVSS 10.0, el máximo posible, y permiten a un usuario sin autenticarse tomar control administrativo completo del arreglo de almacenamiento. Otros cuatro CVEs adicionales tienen severidad crítica (CVSS entre 9.6 y 9.9). Dell recomienda actualizar al menos a la versión 1.18.0 de CSM, donde están parchados los problemas de autenticación del módulo CSM Authorization v2.4.0 y del CSM Operator v1.12.0.

Por qué importa para sysadmins Linux

CSM corre como pods dentro del cluster Kubernetes, así que un atacante que explote estos fallos no solo accede al almacenamiento: si lo combinás con CVE-2026-67269 (CVSS 9.9, escalación a root vía reconciler de ContainerStorageModule CRD) o CVE-2026-67273 (CVSS 9.6, lectura de Kubernetes Secrets cluster-wide y manipulación de RBAC), termina con la posibilidad de comprometer todos los nodos del cluster desde un único Custom Resource maliciosamente diseñado.

El ataque más realista que describe el advisory es así:

1. Un atacante no autenticado llega al endpoint gRPC de csm-authorization-storage (CVE-2026-63688) y exfiltra las credenciales de administrador de todos los arreglos registrados.
2. Con esas credenciales, llama al proxy de autorización y al servicio de tenants (CVE-2026-63692), bypasseando autenticación y creando entidades de tenant cruzadas.
3. Si el cluster además corre karavi-authorization con el secreto JWT que figuraba en la documentación oficial (CVE-2026-61421, “supersecret”), puede forjar tokens criptográficamente válidos y persistir el acceso aunque rotes el resto de las claves.

En resumen: un solo POST al gRPC equivocado le entrega a un atacante las llaves del kingdom storage de tu cluster.

Tabla de CVEs críticos y su impacto

CVE	CVSS	Componente	Vector de ataque	Impacto
CVE-2026-63688	10.0	csm-authorization-storage (gRPC)	Red, sin autenticación	Exfiltra credenciales admin de TODOS los storage arrays
CVE-2026-63692	10.0	authorization proxy + tenant service	Red, sin autenticación	Bypass auth + control admin multi-tenant
CVE-2026-67269	9.9	CSM Operator 1.12.0 reconciler	Red, usuario low-priv	Escalación a root en TODOS los nodos del cluster
CVE-2026-54472	9.8	CSM Authorization 2.4.0	Red, sin autenticación	Credenciales hardcodeadas, forja tokens admin
CVE-2026-61421	9.8	karavi-authorization (archivo)	Red, sin autenticación	Secreto JWT público “supersecret” de docs oficiales
CVE-2026-67273	9.6	CSM 1.12.0 template engine	Red, usuario low-priv	Lee todos los Kubernetes Secrets cluster-wide + bypassa RBAC
CVE-2026-67270	8.2	proxy-server	Red adyacente, sin auth	Validación de certificados rota, expone credenciales
CVE-2026-76105	7.7	CSM 1.18.0 valores random	Local, sin autenticación	Manipulación de información
CVE-2026-61411	7.7	CSM logs	Red, usuario low-priv	Información sensible en logs
CVE-2026-70411	7.1	csm-authorization-tenant gRPC	Red adyacente, sin auth	Inyección cross-tenant, modificación de ACLs

Hay además cinco CVEs sobre dependencias de terceros (golang.org/x/crypto, golang-jwt/jwt v4, golang/protobuf, golang.org/x/net) que arrastra el árbol de CSM y que Dell parchea de paso. Es la típica situación de supply chain: actualizás CSM y te llevás de regalo 25 CVEs upstream corregidos.

Cómo verificar si estás afectado

Lo primero: confirmá qué versión de CSM tienes corriendo. La forma más rápida es describir el Deployment del operator y la versión de Authorization en el cluster:

# Versión del CSM Operator
kubectl get deploy -n csm-operator-system 
  -l app=csm-operator -o jsonpath='{.items[*].spec.template.spec.containers[].image}{"n"}'
# Versión del Authorization
kubectl get deploy -A -l app=csm-authorization 
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"t"}{.spec.template.spec.containers[].image}{"n"}{end}'
# Pods de CSM en cualquier namespace
kubectl get pods -A -l app.kubernetes.io/part-of=csm -o wide

Si tu Authorization dice v2.4.0 o tu Operator dice 1.12.0, estás vulnerable. Las versiones afectadas explícitamente según Dell son CSM Authorization v2.4.0 y CSM Operator v1.12.0; la remediación está en CSM 1.18.0 o superior.

Para confirmar si tienes karavi-authorization desplegado (el proyecto archivado que arrastra CVE-2026-61421 con “supersecret”):

# Detectar el deployment archivado
kubectl get deploy -A -l app=karavi-authorization-proxy
kubectl get deploy -A -l app=karavi-authorization
# Si aparece algo, sacá el secreto que estás usando
kubectl get secret -A -l app=karavi-authorization 
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"n"}{end}'

Si el secreto JWT se llama algo tipo karavi-jwt-signing-key y su valor es literalmente supersecret, cambialo ahora mismo, antes de actualizar Dell CSM, porque karavi-authorization ya está fuera de mantenimiento y la actualización de CSM no te protege de ese CVE por sí sola.

Cómo actualizar a CSM 1.18.0

El procedimiento oficial usa csm-upgrade, la CLI de Dell. Si la instalaste en algún momento, el flujo es:

# Actualizar la CLI
csm-upgrade version
# Listar los módulos instalados
csm-upgrade list
# Para cada módulo (authorization, operator, replication, etc.):
csm-upgrade module --module-name authorization --repo dell/csm --target-tag v1.18.0
csm-upgrade module --module-name operator --repo dell/csm --target-tag v1.18.0

Si no usas la CLI, también puedes actualizar el Operator manualmente con Helm o con un kubectl apply -f del manifiesto oficial. La documentación de Dell cubre los tres caminos y mantiene compatibilidad con Kubernetes 1.27 en adelante.

Antes de actualizar, dos cosas que conviene hacer en orden:

1. Backup de los secrets de Authorization. Si algo sale mal durante la migración, puedes restaurar los tokens de firma y los certificados de storage backend.
2. Rotar el JWT signing secret si venís de karavi-authorization. La actualización no te protege de CVE-2026-61421 si dejás el secreto antiguo en su sitio.

Qué pasa si no puedes actualizar ya

Si el cluster está en medio de una ventana de mantenimiento que no puedes romper, hay mitigaciones parciales que Dell lista en el advisory pero que no son equivalentes al parche:

• Restringir el ingress del gRPC de authorization: limitar el puerto gRPC (default 50051) a la red interna del cluster con un NetworkPolicy y exponerlo solo detrás de un Ingress con autenticación.
• Forzar re-issue de credenciales de storage backend: aunque el atacante haya leído credenciales vía CVE-2026-63688, rotarlas reduce la ventana de explotación.
• Auditar Custom Resources de CSM: alguien con permisos para crear un CR puede explotar CVE-2026-67269. Aplicá un ValidatingAdmissionPolicy que restrinja quién puede crear ContainerStorageModule en el cluster.

El NetworkPolicy básico para cerrar el gRPC al exterior del cluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: csm-authorization-deny-external
  namespace: csm-authorization
spec:
  podSelector:
    matchLabels:
      app: csm-authorization
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: csm
    - podSelector:
        matchLabels:
          app: csm

Esto no es un sustituto del parche, pero sube el costo del ataque lo suficiente como para que las herramientas automatizadas de reconocimiento no te peguen primero.

Contexto: el patrón “Dell + CVE crítico” en 2026

Este no es el primer episodio grave de Dell en el año. En febrero de 2026, Mandiant y Google Threat Intelligence Group revelaron que UNC6201 (un grupo state-backed atribuido a China) llevaba desde mediados de 2024 explotando CVE-2026-22769 en Dell RecoverPoint for Virtual Machines, una credencial hardcodeada de severidad máxima usada para desplegar malware y ocultar interfaces en hosts VMware ESXi. CISA ordenó a las agencias federales parchear en tres días.

Antes de eso, Lazarus (Corea del Norte) había abusado del driver Dell dbutil en Windows con CVE-2021-21551 para plantar FUDModule, un rootkit pasivo. Y el historial de CSM en particular ya tenía señales preocupantes: karavi-authorization, uno de los componentes parchados ahora, estaba archivado en GitHub desde hacía meses sin un reemplazo claro, y el secreto supersecret figuraba en la documentación oficial pública hasta que se la quitaron silenciosamente, sin advisory.

Lo que este patrón sugiere para ser fiable: cuando un vendor acumula tres o cuatro CVEs de severidad crítica con credenciales hardcodeadas en poco tiempo, vale la pena revisar todas sus integraciones de storage, no solo la que reportó el aviso.

Opinión: ¿vale la pena actualizar ya?

Sí, sin dudarlo. Tres razones para no postergarlo:

1. La superficie de ataque es grande. CSM Authorization está expuesto al gRPC del cluster y los CVEs 10.0 son missing authentication for critical function. Eso es lo más fácil de escanear y explotar: un nmap --script grpc-enum sobre el rango del cluster te dice quién tiene el puerto abierto.
2. El cluster vive en producción 24/7. Los servicios de storage empresarial rara vez son “podemos reiniciar cuando queramos”. Cuanto más tiempo pase entre el aviso y el parche, mayor la ventana de exposición.
3. El update es compatible. No hay breaking changes significativos en CSM 1.18.0 respecto a 1.12.0 más allá de la corrección de seguridad. Es un upgrade de versión que debería entrar en tu ventana de mantenimiento normal.

Si tu cluster todavía corre karavi-authorization y el secreto es supersecret, ese es el primer cambio a hacer hoy, antes de cualquier otra cosa.

Resumen

Dell parchó el jueves 1 de octubre de 2026 un lote de 13 vulnerabilidades en sus Container Storage Modules, dos de ellas con CVSS 10.0 que permiten a un atacante remoto sin autenticarse tomar control administrativo del almacenamiento empresarial conectado a Kubernetes. La versión mínima segura es CSM 1.18.0, que reescribe el Authorization a una versión posterior a la vulnerable 2.4.0 y cierra el reconciler del Operator 1.12.0. Si usas karavi-authorization, rotá el secreto JWT (si es supersecret, lo es), y aplicá el upgrade cuanto antes.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux