Un fallo crítico en Red Hat Quay permite que cualquier persona que pueda acceder al servidor de claves de un registro tome el control de la firma de sus tokens. El error está registrado como CVE-2026-123710 y tiene una puntuación CVSS de 9.8, según el aviso de Red Hat y la National Vulnerability Database. Red Hat lo publicó el 11 de noviembre de 2026.

Quay es un registro de contenedores empresarial que almacena y sirve imágenes. La debilidad reside en su servidor de claves de servicio. Cuando alguien solicita rotar una clave de firma, el servidor solo comprueba que el JWT esté firmado por una clave aprobada y que tenga la audiencia y el emisor correctos. Nunca comprueba si el token estaba destinado a la rotación de claves.

Vulnerabilidad de Red Hat Quay

Un token anónimo del punto final /v2/auth pasa esa comprobación. El informe de Bugzilla de Red Hat indica que la audiencia proviene directamente de un parámetro de servicio proporcionado por el cliente, por lo que el atacante tiene el control. Esto se aplica cuando la opción FEATURE_ANONYMOUS_ACCESS está activada.

Con ese token, el atacante envía su propia clave al punto final /keys. La nueva clave copia la aprobación de la clave que firmó la solicitud y puede guardarse sin fecha de caducidad. Quay entonces confía en ella inmediatamente.

A partir de ahí, el atacante puede firmar tokens de registro que funcionen en cualquier repositorio. Esto otorga acceso de lectura y escritura a imágenes privadas y les permite intercambiar etiquetas de repositorio. Las imágenes privadas suelen contener secretos, por lo que una filtración puede ir mucho más allá del registro.

Las etiquetas reemplazadas son igual de arriesgadas, ya que los sistemas de construcción podrían descargar la imagen envenenada más tarde. El mismo patrón ha afectado a otros registros, como el fallo del registro de contenedores de Gitea que expuso imágenes privadas.

Red Hat indica que las imágenes de Quay 3 y Quay 5 están afectadas, y la entrada de la NVD muestra los mismos productos. Solo están expuestas las implementaciones donde /keys sea accesible para clientes no confiables. La nota de Bugzilla dice que la lógica ha estado presente desde el primer commit público.

El primer paso que debes dar es limitar /keys en el proxy o equilibrador de carga para que solo los componentes internos confiables puedan acceder a él. A continuación, revisa los registros de auditoría en busca de eventos service_key_rotate y service_key_delete con una expiration_date nula. Elimina cualquier clave de servicio aprobada que no reconozcas.

Borrar una clave maliciosa no solucionará el problema por mucho tiempo. La solicitud anónima puede simplemente instalar una nueva hasta que se ejecute una versión corregida. Tu equipo debe mantener el bloqueo de /keys y estar atento al aviso de Red Hat para una versión parcheada. El aviso aún no menciona ninguna versión corregida.

Los registros están en el centro de la entrega de software, por lo que una clave de firma robada pone en riesgo cada imagen. Si dependes de Quay, también puedes leer nuestra guía sobre las mejores herramientas de seguridad para registros de contenedores para obtener más ideas sobre protección.

Red Hat acredita a su propio investigador, Dave O'Connor, el hallazgo del error. Nadie ha reportado ataques reales y un rastreador señala que no se ha indexado ningún código de exploit público. Aun así, los pasos son sencillos y el daño es grande, así que trata esto como algo urgente.