Bajada
La comunidad de Kubernetes publicó CVE-2026-3865 para el CSI Driver de SMB, una falla de path traversal en el parámetro subDir que puede derivar en borrado o modificación de directorios fuera del alcance esperado del volumen. Aunque el vector exige privilegios, el impacto es operativo en clústeres multiusuario y en entornos donde la gestión de PersistentVolumes no está suficientemente restringida.
Introducción
Durante abril de 2026, el comité de seguridad de Kubernetes incorporó un nuevo caso a su feed oficial de CVEs: CVE-2026-3865, asociado al CSI Driver para SMB (smb.csi.k8s.io). A primera vista no parece un bug “de internet” porque no es un RCE sin autenticación; sin embargo, sí es un problema relevante para equipos de plataforma y SRE porque toca un punto sensible: la frontera entre permisos de Kubernetes y operaciones reales sobre storage compartido.
En muchas organizaciones, los controladores CSI son piezas críticas para estado persistente, backups, flujos de datos y aplicaciones legacy. Cuando un componente de esa capa permite traversal de rutas durante operaciones de limpieza, el riesgo no se limita al pod que originó el volumen: puede comprometer integridad de datos compartidos y provocar incidentes silenciosos de disponibilidad.
Qué ocurrió
El aviso oficial describe una validación insuficiente del campo subDir dentro de identificadores de volumen (volumeHandle) en el CSI Driver SMB. Un usuario con capacidad de crear PersistentVolumes que apunten al driver puede construir secuencias como ../ dentro de ese valor. En determinadas rutas de borrado o limpieza del volumen, el controlador puede operar fuera del subdirectorio esperado dentro del recurso SMB.
La consecuencia práctica es seria: eliminación o modificación de carpetas no previstas en el servidor SMB. Por eso, aunque la severidad CVSS publicada es media (6.5), el impacto operativo puede escalar rápido en clústeres donde varios equipos comparten exports SMB y la gobernanza de almacenamiento está distribuida.
El comité de seguridad de Kubernetes indica que el problema afecta versiones anteriores a v1.20.1 del driver, y que la corrección está disponible a partir de esa versión. También recomienda limitar quién puede crear PersistentVolumes y revisar logs del controlador para detectar rutas anómalas durante tareas de cleanup.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps y plataforma, este CVE es un recordatorio de que los permisos de aprovisionamiento de storage son equivalentes a permisos de impacto sobre infraestructura de datos. En términos prácticos:
– Si un tenant interno puede crear PVs arbitrarios sobre smb.csi.k8s.io, existe margen para abuso de limpieza fuera de scope.
– En clústeres multi-tenant, el daño puede afectar workloads de otros equipos sin tocar directamente sus namespaces.
– En pipelines de infraestructura como código, una plantilla mal validada podría introducir handles peligrosos y activar borrados no intencionales al destruir recursos.
Para seguridad, el patrón es conocido: traversal en una ruta de operación administrativa. No siempre termina en exfiltración, pero sí en pérdida de integridad y disponibilidad, dos dimensiones críticas para continuidad operacional y cumplimiento.
Detalles técnicos
La documentación del driver SMB define que volumeHandle combina servidor, subdirectorio y share en un formato delimitado por #. Ese diseño es práctico para trazabilidad, pero exige sanitización estricta del subDir antes de usarlo en acciones de filesystem remoto. El fallo reportado aparece precisamente cuando esa validación no bloquea secuencias de escape de ruta.
El caso es comparable a otros CVE recientes del ecosistema CSI (como el de NFS reportado semanas atrás), lo que sugiere que los controladores de almacenamiento deben tratar entradas de rutas con el mismo nivel de desconfianza que un parser de requests HTTP. Si el cleanup de volúmenes confía en identificadores manipulables, el problema deja de ser “solo storage” y pasa a ser una superficie de ataque lateral.
Indicadores útiles para investigación interna:
– PersistentVolumes con volumeHandle que incluyan patrones ../ o variantes equivalentes.
– Eventos de borrado de volumen seguidos por pérdida de directorios no mapeados al PVC esperado.
– Logs del controlador SMB con rutas normalizadas que escapan del prefijo previsto.
Qué deberían hacer los administradores o equipos técnicos
1. Confirmar versión del driver SMB
Inventariar despliegues de smb.csi.k8s.io y validar que estén en v1.20.1 o superior. Si hay clústeres de laboratorio o edge con versiones anteriores, priorizar actualización.
2. Restringir creación de PVs
Aplicar RBAC de mínimo privilegio para que solo roles de plataforma puedan crear o aprobar PVs sobre drivers externos. Evitar delegar esta capacidad a usuarios de aplicación salvo casos muy controlados.
3. Auditar volumeHandle y StorageClass
Revisar manifiestos activos e históricos para detectar subDir con secuencias de traversal. Incorporar validaciones en admission policies (OPA/Gatekeeper/Kyverno) para bloquear patrones inseguros.
4. Revisar permisos en el servidor SMB
Asegurar que el path usado por el driver tenga aislamiento real por share/subdirectorio y permisos mínimos. Si todo el entorno depende de una export plana con escritura amplia, el riesgo residual crece incluso tras parchear.
5. Fortalecer detección y respuesta
Agregar alertas sobre operaciones de borrado inesperadas en el backend SMB y correlacionarlas con eventos de Kubernetes (creación/eliminación de PV/PVC). Este cruce reduce tiempo de detección ante abuso interno o errores de automatización.
Conclusión
CVE-2026-3865 no es un titular ruidoso, pero sí un evento importante para operación real de Kubernetes con storage compartido. La combinación de path traversal en subDir, privilegios de aprovisionamiento y tareas automáticas de cleanup abre una ventana de daño que muchas plataformas subestiman.
La lectura correcta para equipos técnicos no es “parchar y seguir”, sino usar este caso para reforzar tres controles estructurales: gobernanza de quién crea volúmenes, validación preventiva de parámetros de storage y observabilidad específica en operaciones de borrado. Esa tríada reduce tanto el riesgo de explotación como los incidentes por error humano.
Fuentes
https://github.com/kubernetes/kubernetes/issues/138319
https://kubernetes.io/docs/reference/issues-security/official-cve-feed/