Red Hat detectó dos fallos críticos en Quay que permiten a atacantes leer, modificar o eliminar imágenes de contenedores privadas y robar credenciales de cuentas robot. Estas vulnerabilidades afectan a casi todas las versiones y pueden comprometer pipelines de CI/CD en OpenShift. Se recomienda bloquear el endpoint /keys y actualizar inmediatamente a las versiones corregidas.





Un fallo crítico en Red Hat Quay permite que un atacante que pueda acceder a un registro de Quay lea y sobrescriba imágenes de contenedores privadas en cualquier repositorio.

Quay permite el acceso anónimo por defecto y, mientras esté activado, el atacante no necesita ninguna cuenta. Cuando está desactivado, cualquier persona con una cuenta válida puede seguir explotando el fallo, según informó Red Hat ayer. La empresa ha publicado versiones corregidas para ocho ramas de Quay 3.

El fallo está registrado como CVE-2026-123710 (puntuación CVSS: 9.8).

Quay utiliza claves en las que confía para firmar los tokens de acceso que permiten subir y bajar imágenes. El fallo permite a un atacante añadir su propia clave a las claves en las que Quay confía, sin fecha de expiración. Entonces, Quay acepta tokens firmados con esa clave para cualquier repositorio.

Con esos tokens, un atacante puede recuperar imágenes privadas y cualquier secreto o credencial almacenada en ellas. El atacante también puede subir o sobrescribir imágenes, y el cambio se propaga a todos los sistemas que descarguen esas imágenes posteriormente.

La clave implantada sobrevive a los reinicios hasta que alguien la elimine. También puede usarse para borrar las claves que utilizan las instancias de Quay en ejecución, por lo que las subidas y bajadas normales empezarán a fallar con errores de autenticación.

El servidor de claves de Quay comprueba que una solicitud para reemplazar una clave lleve un token firmado por una clave confiable, con la audiencia y el emisor esperados. Sin embargo, no comprueba si el token fue emitido para la rotación de claves. Un token anónimo del endpoint /v2/auth de Quay pasa la validación: Quay lo firma con una clave confiable y el llamador elige su audiencia.

Un segundo fallo crítico

Se reveló al mismo tiempo un segundo fallo crítico, CVE-2026-110697 (puntuación CVSS: 9.9). Este permite que un usuario de Quay que pueda crear un espacio de nombres (namespace) robe tokens de cuentas de robot de otros inquilinos y los use para leer, subir o sobrescribir las imágenes de dichos inquilinos.

Este fallo se encuentra en el código que enumera las cuentas de robot. Construye un patrón SQL LIKE a partir del nombre del espacio de nombres sin escapar los caracteres comodín, y en SQL LIKE, un guion bajo coincide con cualquier carácter individual.

Por lo tanto, un espacio de nombres con un guion bajo en el lugar adecuado puede coincidir con el espacio de nombres de otro inquilino y devolver sus cuentas de robot, con sus tokens descifrados. El atacante no necesita privilegios elevados y la víctima no tiene que hacer nada.

Eliminar el espacio de nombres del atacante también borra las cuentas de robot correspondientes, lo que puede interrumpir los sistemas que dependen de ellas. En los casos donde Quay es el registro integrado para OpenShift, las credenciales de robot robadas pueden usarse para inyectar imágenes maliciosas en los flujos de CI/CD, afirma la compañía.

Dave O'Connor, de Red Hat, encontró ambos fallos. La lógica detrás de CVE-2026-123710 ha estado en Quay desde su primer commit público, según el informe de errores de ese fallo.

Red Hat indica que todas las versiones de Quay 3 y Quay 5 están afectadas por ambos fallos. Para CVE-2026-123710, su guía menciona que están afectadas las instalaciones independientes, Quay desplegado mediante el Quay Operator en OpenShift y el registro espejo para Red Hat OpenShift.

Cualquier instancia de Quay a la que puedan llegar clientes no confiables está expuesta, incluidos los registros internos, dice la empresa.

Al consultarlo hoy, la entrada CVE de CVE-2026-123710 todavía mostraba todos los paquetes de Quay como afectados, sin solución, a pesar de que cada aviso menciona el fallo.

La empresa recomienda estos pasos:

1. En el proxy o equilibrador de carga, bloquea el endpoint /keys para todo excepto para los componentes internos confiables.
2. Busca en los registros de auditoría eventos de service_key_rotate y service_key_delete donde expiration_date sea nulo.
3. Elimina cualquier clave de servicio aprobada que no reconozcas.
4. Instala la versión corregida. Hasta que esté funcionando, un atacante puede añadir una nueva clave de la misma manera, por lo que borrar una no es permanente.

"Desactivar el acceso anónimo no te protege", afirma la empresa en su artículo de remediación de claves. Una clave implantada también sigue funcionando después de restablecer contraseñas y cambiar el token del robot.

Para CVE-2026-110697, la página de CVE de la empresa menciona las mismas ocho versiones como corregidas, indica que actualizar es la única solución completa y dice que Quay.io ya está corregido. Pero ninguno de los ocho avisos enumera el CVE-2026-110697.

Hasta que se implemente una actualización, la empresa sugiere limitar quién puede crear organizaciones o espacios de nombres que contengan un guion bajo, rotar los tokens de robot para cualquier espacio de nombres que coincida con uno con guion bajo, y vigilar las descargas o subidas que no se ajusten al uso normal del robot. Estos pasos reducen la exposición, pero el fallo persiste.

La corrección upstream añade la comprobación de rotación que faltaba, requiere que las claves añadidas a través del servidor de claves tengan una fecha de expiración y evita que los llamadores elijan la audiencia de un token. El mismo cambio también corrige la búsqueda de cuentas de robot.

Fuente:
THN