Introducción
La integridad de la cadena de suministro de software depende de la confianza absoluta en los mecanismos de autenticación de los registros de contenedores. Cuando Docker Hub, el repositorio central para imágenes de contenedores, introduce una falla que permite a un atacante autenticarse como un usuario legítimo sin conocer sus credenciales, el riesgo trasciende la brecha de datos tradicional. Nos enfrentamos a un escenario de suplantación de identidad a nivel de protocolo, donde la confianza implícita en los tokens de acceso personal (PAT) se convierte en un vector de compromiso directo.
Este incidente, rastreado como CVE-2026-105445, no requiere exploits complejos de memoria ni ingeniería social sofisticada. La vulnerabilidad reside en la lógica de negocio de la plataforma: la reasignación silenciosa de secretos durante un cambio de estado de la cuenta. Para los equipos de DevOps y SRE, esto significa que la rotación regular de tokens y la auditoría de permisos organizacionales deben revisarse inmediatamente, ya que los controles de seguridad convencionales (como 2FA en la web) quedaron neutralizados en la capa de API.
Qué ocurrió
Docker identificó un defecto crítico en la funcionalidad que permite convertir una cuenta personal de Docker Hub en una organización. El flujo de trabajo estándar implicaba que, al realizar esta conversión, los Personal Access Tokens (PAT) asociados a la cuenta original se reasignaban automáticamente al nuevo propietario de la organización. El fallo radicó en que esta transferencia ocurría sin revocar el token anterior, sin generar un nuevo secreto y, lo más crítico, sin solicitar el consentimiento explícito del usuario que se estaba nombrando como propietario.
Un atacante podía crear una cuenta gratuita, generar un PAT válido y luego convertir esa cuenta en una organización, nombrando a una víctima (un usuario existente con permisos elevados) como propietario. Debido a la lógica defectuosa, el PAT original del atacante seguía siendo válido, pero ahora heredaba los permisos del propietario de la organización recién creada. Esto otorgaba al atacante una autenticación válida con el alcance y los privilegios de la víctima, permitiéndole interactuar con el registro como si fuera el titular legítimo de la cuenta, sin necesidad de poseer el usuario o la contraseña reales.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
La clasificación de «crítico» por parte de Docker no es hipérbola; este vector de ataque ataca directamente el corazón del pipeline de CI/CD. Un atacante con acceso autenticado bajo una identidad legítima puede realizar acciones que los firewalls de red y los sistemas de detección de intrusiones (IDS) convencionales no suelen bloquear, ya que el tráfico parece originado desde una sesión autorizada.
Las capacidades del atacante dentro del alcance del token comprometido incluían la extracción de imágenes privadas (robo de propiedad intelectual o secrets embebidos), la modificación de metadatos, la eliminación de imágenes (ataque de denegación de servicio contra despliegues) y, lo más peligroso, la publicación de imágenes maliciosas bajo nombres de repositorios legítimos. Esto habilita ataques de typosquatting dinámico o la sustitución de dependencias base, comprometiendo todos los entornos de producción que consuman esas imágenes actualizadas.
Además, el impacto se extiende a las organizaciones donde la víctima tenía acceso. Un solo PAT comprometido podía actuar como un pivote lateral dentro de múltiples espacios de trabajo organizacionales, escalando el privilegio desde una cuenta personal comprometida hacia recursos empresariales compartidos.
Detalles técnicos
La vulnerabilidad fue introducida el 26 de agosto de 2024, cuando Docker implementó cambios en el proceso de conversión de cuentas. El error específico consistía en que el sistema asociaba el secreto del PAT existente a la nueva entidad organizacional sin ejecutar una invalidación del token antiguo ni generar un nuevo par clave/valor. A diferencia de los tokens OAuth2 tradicionales que tienen tiempos de expiración cortos y scopes granulares, los PATs de Docker Hub suelen ser de larga duración y, si no se gestionan correctamente, pueden tener permisos de escritura (read_write) amplios.
Docker confirmó la vulnerabilidad el 30 de septiembre de 2026, tras recibir un reporte externo. El equipo de ingeniería desplegó un parche en producción en menos de cuatro horas. La solución técnica implicó desactivar la reasignación automática de PATs durante la conversión y exigir una confirmación explícita por parte del usuario nombrado como propietario antes de vincular cualquier acceso.
Es importante notar las limitaciones del ataque: la vulnerabilidad exponía únicamente la capa de API del registro. No otorgaba acceso a la interfaz web de Docker Hub, ni permitía cambiar contraseñas, correos electrónicos o configuraciones de autenticación de dos factores (2FA). Por lo tanto, el compromiso estaba limitado a operaciones programáticas (pull, push, delete) y no a la toma de control total de la cuenta de usuario en la plataforma web.
Docker auditó 304.000 pushes realizados con tokens transferidos tras el incidente y no encontró evidencia de explotación maliciosa activa antes de la corrección. Sin embargo, la ausencia de evidencia en logs no garantiza la inexistencia de intentos exitosos que no dejaran rastro en los servicios de telemetría estándar.
Qué deberían hacer los administradores y equipos técnicos
La acción principal es la auditoría y la rotación proactiva de secretos, independientemente de si recibieron notificación de Docker. Docker notificó a los usuarios afectados el 2 de octubre de 2026 y desactivó los PATs transferidos el 8 de octubre, salvo solicitud expresa de los propietarios para mantenerlos.
docker login
# Verificar tokens actuales
docker system info | grep -i «personal access token»
# En la práctica, se debe revocar desde la UI o CLI y generar uno nuevo
docker logout
Conclusión
La CVE-2026-105445 es un recordatorio de que la seguridad de la cadena de suministro no es solo una cuestión de cifrado o parches de kernel, sino de la lógica de autorización y gestión de identidades. La simplicidad del vector —heredar un token sin rotación— contrasta con el impacto potencial de comprometer la integridad de miles de despliegues.
Aunque Docker respondió con rapidez, el incidente expone la fragilidad de asumir que los cambios de estado de una cuenta no afectan la validez de los secretos asociados. Para los arquitectos de seguridad, esto refuerza la necesidad de tratar los PATs como credenciales de alto valor que requieren rotación periódica y monitoreo activo, independientemente de las garantías del proveedor del registro. La suplantación a nivel de API es silenciosa y efectiva; las defensas deben ser tan granulares como el riesgo.
Fuentes
https://www.bleepingcomputer.com/news/security/docker-hub-flaw-let-attackers-impersonate-users-tamper-with-images/