Una vulnerabilidad en Docker Hub, el registro donde se publican y descargan las imágenes de contenedores, permitía que un usuario publicara, descargara o eliminara imágenes haciéndose pasar por otro. Docker corrigió el fallo el 30 de septiembre y afirma que no ha encontrado pruebas de que alguien lo haya explotado.
El fallo residía en la función que convierte una cuenta personal en una organización, según explicó Docker en un aviso de seguridad el 12 de octubre. La conversión transfería los tokens de acceso personal (PAT) de la cuenta al usuario designado como propietario de la organización. Un PAT se usa en lugar de una contraseña en el registro, y la persona que creó cada token puede seguir usándolo.
El acceso estaba limitado al registro. No alcanzaba la interfaz web de Docker Hub y no podía usarse para cambiar una contraseña, dirección de correo electrónico o configuración de doble factor, ni para tomar el control de una cuenta.
Docker rastrea el fallo como CVE-2026-105445 y lo calificó como crítico. El registro CVE publicado el 13 de octubre le otorga una puntuación CVSS 4.0 de 9.4.
La vulnerabilidad estuvo abierta desde el 26 de agosto de 2024 hasta la corrección, poco más de dos años. Docker aplicó la solución directamente en Docker Hub, por lo que no hay ninguna actualización que instalar.
Docker Hub no puede mover un repositorio de una cuenta a otra. En su lugar, un usuario convierte una cuenta personal en una organización que conserva el mismo nombre, y debe designar una cuenta existente como propietaria.
Cada token de acceso personal actúa como la cuenta que lo posee, con un nivel de permisos elegido al crearlo. Mientras el fallo estuvo presente, la conversión cambiaba el propietario registrado de cada token y dejaba su secreto sin cambios.
Un atacante podía aprovechar esto creando un token en una cuenta que controlaba, convirtiendo esa cuenta en una organización y nombrando a otro usuario como propietario. El token funcionaría entonces en el registro como ese usuario.
Al propietario designado no se le pedía confirmación ni se le notificaba, según Docker y los investigadores que reportaron el fallo. La página de conversión de Docker incluye la frase "El nuevo propietario recibe un correo electrónico de notificación" al menos desde agosto de 2024.
Dentro del nivel de permisos del token, un token transferido podía descargar, publicar o eliminar imágenes en los repositorios del propietario designado y en las organizaciones a las que este tuviera acceso.
Docker calificó el fallo como crítico porque ese acceso "incluye publicar imágenes bajo un nombre legítimo", según la compañía.
En marzo y abril, atacantes utilizaron credenciales de publicador robadas para subir imágenes maliciosas de Trivy y KICS a los repositorios de Docker Hub de los propios publicadores, según Docker.
Peter Molnar y Krisztian Hozak, de mptrdev.com, descubrieron el fallo y lo reportaron a Docker, que afirma haber implementado la corrección menos de cuatro horas después de recibir el informe. Denominaron la vulnerabilidad GhostPat.
En su análisis técnico, ambos explican que reprodujeron el fallo dos veces en cuentas de prueba con consentimiento. Iniciaron sesión en el registro como la cuenta objetivo, crearon y publicaron en un repositorio de su espacio de nombres, publicaron en una organización a la que pertenecía y descargaron sus repositorios privados.
Qué cubrió la revisión de Docker
Docker revisó todas las conversiones de cuenta realizadas mientras el fallo estuvo abierto y las comparó con los registros del registro y los registros de tokens. Buscó cualquier token utilizado bajo más de una identidad y examinó cada publicación hecha con un token transferido, unas 304.000 en total.
"No encontramos evidencia de que la vulnerabilidad fuera explotada", afirmó la compañía.
Todas esas publicaciones fueron a un repositorio perteneciente a la organización convertida o a su propietario designado, según Docker. En la gran mayoría de los casos, ambas cuentas pertenecían a la misma persona o equipo.
Cuando no pudo confirmar que una sola persona controlaba ambas cuentas, Docker analizó las imágenes públicas de mayor riesgo sin ejecutarlas y no encontró malware ni manipulación.
Los registros de Docker muestran cuándo se usa un token, no que exista, por lo que un token transferido que nunca se usó no dejó rastro en los registros. Por ese motivo, Docker trató todos los tokens transferidos por una conversión mientras el fallo estuvo abierto como posiblemente afectados, se hubieran usado o no.
El aviso informa de los resultados para las publicaciones. No dice qué encontró Docker para las descargas o eliminaciones realizadas con tokens transferidos, incluidas las descargas de repositorios privados.
A quién se notificó y qué comprobar
El 2 de octubre, Docker envió correos electrónicos a los usuarios cuyas cuentas habían recibido tokens transferidos y, por separado, a los propietarios de las organizaciones implicadas. Cada correo enumeraba los tokens por descripción y fecha de creación.
El aviso no dice cuántos usuarios o tokens abarca, y califica al grupo solo como un "número limitado" de usuarios.
Quien no recibió el correo no estuvo expuesto y no tiene nada que hacer, según Docker.
El 8 de octubre, Docker desactivó los tokens transferidos que había identificado. No se desactivaron los tokens que sus propietarios pidieron conservar.
Todd Matens, que publica un linter de Docker Compose llamado compose-lint, escribió en una entrada de blog que recibió dos correos el 2 de octubre. Uno fue enviado a él como propietario de una organización y el otro a su cuenta de usuario. Rotó sus dos tokens de CI y verificó las firmas de sus 42 imágenes publicadas, rastreando cada una hasta la ejecución de CI que la construyó.
Docker aconseja a los usuarios revisar sus tokens, revocar cualquiera que no reconozcan o ya no utilicen, y usar tokens de acceso de organización, no el PAT de una persona, para la automatización que pertenece a una organización.
Estos detalles ayudan con esas comprobaciones:
- Abre Configuración de la cuenta, luego Tokens de acceso personal. La lista muestra cuándo se creó cada token y cuándo se usó por última vez.
- Los investigadores describen dos rastros. Uno es un token que no creaste, sea cual sea su nombre, porque quien crea un token elige su descripción. El otro es una organización en el conmutador de cuentas a la que no recuerdas haberte unido.
- Los tokens de acceso de organización requieren una suscripción Docker Team o Docker Business. Los gestiona un propietario de organización, un propietario de empresa o un rol personalizado con ese permiso, y no funcionan con Docker Desktop ni con Image Access Management.
- Los propietarios de organizaciones en esas suscripciones pueden revisar publicaciones anteriores en los registros de actividad, que registran las etiquetas publicadas y pueden mostrar el token que las publicó. Docker Home, donde se ven los registros, los conserva durante 30 días, y las entradas más antiguas están disponibles a través de la API de Docker Hub.
La documentación de Docker describía la transferencia
La propia documentación de Docker describió la transferencia de tokens durante aproximadamente 17 de los casi 25 meses que el fallo estuvo abierto. Un cambio en la documentación el 22 de abril de 2025 añadió una nota a la página de conversión de Docker. Decía que designar a un usuario como propietario de la organización "garantizará que cualquier PAT asociado con la cuenta del usuario se transfiera al propietario de la organización".
Docker eliminó la nota el 30 de septiembre, minutos después de la hora que indica para la corrección. Las fechas provienen del historial público de la documentación de Docker, que The Hacker News revisó.
Docker afirma que ahora exige consentimiento antes de designar a un usuario como propietario de una organización y notifica a ese usuario cuando esto ocurre. También registra cada cambio en la propiedad de los tokens y revisa otras funciones que cambian quién posee una credencial.
Deja una respuesta