Docker ha corregido un fallo en Docker Hub que permitía que, al convertir una cuenta personal en una organización, los tokens de acceso personal (PAT) quedaran asociados a otro usuario y pudieran utilizarse en el registro como si fueran del destino. La compañía publicó un aviso de seguridad el 12 de octubre y detalla que la corrección se desplegó el 30 de septiembre.
Qué ocurrió y cómo funcionaba la vulnerabilidad
El problema estaba en el flujo que transforma una cuenta personal en una organización manteniendo el mismo nombre y asignando un propietario existente. Durante esa conversión, el sistema cambiaba el propietario registrado de los PAT sin alterar el secreto del token. Como resultado, un token creado por un usuario A podía empezar a funcionar en el registro con la identidad de un usuario B cuando A convertía su cuenta en organización y nombraba a B como propietario.
Un PAT (personal access token) actúa en el registro en lugar de una contraseña y tiene permisos fijados al crearlo (por ejemplo, push, pull o delete sobre repositorios). La accesibilidad se limitó al registro de imágenes: según Docker, no afectó a la interfaz web de Docker Hub ni permitía cambiar contraseñas, correos, ajustes de doble factor o tomar control completo de la cuenta fuera del registro.
Alcance temporal y evaluación de riesgos
Docker indica que la vulnerabilidad estuvo abierta desde el 26 de agosto de 2024 hasta la corrección el 30 de septiembre de 2026, algo más de dos años. La compañía asignó la referencia CVE-2026-105445 y un puntaje CVSS 4.0 de 9.4, que califica la falla como crítica por la posibilidad de publicar imágenes bajo identidades legítimas.
Los investigadores Peter Molnar y Krisztian Hozak de mptrdev.com descubrieron y reportaron el fallo; Docker afirma que desplegó la corrección menos de cuatro horas después de recibir el informe. En su comprobación, los investigadores reprodujeron la falla en cuentas de prueba consentidas y demostraron que un token transferido podía hacer push, pull y acceder a repositorios privados en el espacio de nombres del usuario nombrado como propietario.
Respuesta de Docker y medidas aplicadas
Tras investigar, Docker revisó todas las conversiones de cuentas realizadas mientras el fallo estuvo activo, cruzó registros del registro y registros de tokens y examinó los pushes realizados con tokens transferidos —unos 304.000, según el aviso—. La empresa afirma no haber encontrado evidencia de explotación maliciosa.
Docker trató como potencialmente afectados todos los tokens transferidos por conversiones durante ese periodo, incluso si no aparecían en los logs (porque los logs registran usos y no la mera existencia de un token). El 2 de octubre Docker envió correos a los usuarios que habían recibido tokens transferidos y a los propietarios de las organizaciones implicadas, listando los tokens por descripción y fecha de creación. El 8 de octubre desactivó los tokens transferidos que había identificado, excepto aquellos que sus propietarios habían pedido conservar.
Qué deben hacer los administradores y propietarios de imágenes
Docker recomienda revisar los tokens personales, revocar los que no se reconozcan o no se usen, y usar tokens de acceso de organización para automatizaciones que pertenezcan a un equipo en lugar de PATs de una sola persona. Si un usuario recibió el aviso por correo el 2 de octubre, debe seguir las instrucciones de Docker y rotar cualquier token que considere comprometido; quienes no recibieron el correo, según Docker, no estuvieron expuestos.
Implicaciones prácticas
Para administradores de repositorios y responsables de CI/CD, el riesgo principal era la publicación de imágenes maliciosas bajo nombres legítimos o la modificación de repositorios mediante tokens transferidos. La medida más práctica es auditar y rotar tokens usados en pipelines, usar tokens de organización para integración continua y limitar permisos de los tokens al mínimo necesario (principio de mínimos privilegios).
Nota técnica: la corrección se aplicó por parte de Docker Hub en el servicio; no hay una actualización de cliente o servidor que instalar. Docker también cambió el proceso para requerir consentimiento al nombrar a un usuario como propietario y activa notificaciones y registro de cambios de propiedad de tokens.
Lee también:
- AlmaLinux Atomic actualiza su herramienta de construcción a la familia bootc y ofrece ISOs en live y para aarch64
- ISPC 1.32 añade soporte para AVX10.2 y APX, y mejora compatibilidad con CPUs AMD
Fuente: The Hacker News
