Dos vulnerabilidades con puntuaciones de hasta 9,9 sobre 10 permiten robar credenciales, acceder a repositorios privados y sustituir imágenes utilizadas en aplicaciones y sistemas empresariales.
Una brecha en el lugar donde las empresas almacenan y distribuyen su software puede comprometer mucho más que una cuenta o un servidor. Red Hat ha reconocido dos vulnerabilidades críticas en Quay, su plataforma de registro de imágenes de contenedores, que pueden permitir a los atacantes acceder a repositorios privados, extraer credenciales y sustituir componentes de software por versiones manipuladas.
El alcance es especialmente preocupante porque una de las vulnerabilidades puede explotarse sin disponer de una cuenta, siempre que el servicio afectado sea accesible para clientes no confiables. La segunda permite robar credenciales de cuentas técnicas pertenecientes a otras organizaciones dentro de instalaciones multiusuario.
Los fallos, identificados como CVE-2026-123710 y CVE-2026-110697, han recibido puntuaciones de 9,8 y 9,9 sobre 10, respectivamente, en el sistema CVSS. Red Hat ha publicado versiones corregidas para varias ramas de Quay 3 y recomienda actualizar cuanto antes.
El problema va más allá de la exposición de información: un atacante podría introducir imágenes manipuladas en los procesos de desarrollo y distribución de software. En entornos que utilizan OpenShift y sistemas de integración continua, esto puede comprometer la cadena de suministro de aplicaciones.
Dos vulnerabilidades críticas en Red Hat Quay
Red Hat Quay es una plataforma utilizada para almacenar, administrar y distribuir imágenes de contenedores. Estas imágenes contienen los componentes necesarios para ejecutar aplicaciones en infraestructuras modernas, desde servidores empresariales hasta entornos Kubernetes y OpenShift.
Las organizaciones utilizan registros como Quay para controlar qué equipos pueden descargar, publicar o modificar las imágenes que posteriormente se despliegan en producción.
Precisamente por esa función, una vulnerabilidad en sus mecanismos de autenticación y gestión de credenciales puede tener consecuencias importantes.
Los dos fallos fueron descubiertos por Dave O’Connor, investigador de Red Hat, y se hicieron públicos el 11 de noviembre de 2026.
| Vulnerabilidad | Puntuación CVSS | Consecuencia principal |
|---|---|---|
| CVE-2026-123710 | 9,8/10 | Manipulación de claves de firma y acceso a todos los repositorios |
| CVE-2026-110697 | 9,9/10 | Robo de credenciales técnicas de otros usuarios o espacios de nombres |
Aunque ambas afectan a Quay, sus mecanismos son diferentes. La primera compromete el sistema de claves que autoriza las operaciones sobre los repositorios. La segunda rompe el aislamiento entre organizaciones mediante un fallo en la consulta de cuentas técnicas.
CVE-2026-123710: un atacante puede introducir su propia clave de confianza
La primera vulnerabilidad, CVE-2026-123710, es especialmente grave porque permite manipular el sistema que utiliza Quay para firmar y validar los tokens de acceso a los repositorios.
Quay emplea claves de confianza para generar y verificar los tokens que autorizan operaciones como descargar o publicar imágenes. El problema está en el mecanismo encargado de gestionar la rotación de esas claves.
Según la descripción técnica publicada por Red Hat, el servidor de claves no comprueba correctamente que el token presentado para solicitar una rotación haya sido emitido específicamente con esa finalidad.
Un atacante puede aprovechar esa validación insuficiente para instalar una clave de firma propia dentro del conjunto de claves consideradas fiables por Quay.
La clave puede añadirse sin fecha de caducidad. Una vez aceptada, el sistema reconoce los tokens firmados con ella y permite utilizarlos para acceder a cualquier repositorio de la instalación afectada.
Esto abre la puerta a varias acciones:
- Descargar imágenes privadas de los repositorios.
- Extraer contraseñas, credenciales y otros secretos que puedan estar almacenados dentro de las imágenes.
- Publicar nuevas imágenes o sustituir las existentes.
- Modificar etiquetas de repositorios para que otros sistemas descarguen contenido manipulado.
- Eliminar claves utilizadas por las instancias de Quay y provocar errores de autenticación en operaciones legítimas.
La persistencia es otro elemento preocupante. La clave maliciosa puede sobrevivir a los reinicios del servicio hasta que un administrador la elimine.
Además, cambiar contraseñas o regenerar los tokens de las cuentas técnicas no basta para invalidar una clave que ya ha sido incorporada al sistema de confianza.
Por qué puede explotarse sin una cuenta
La gravedad de este fallo aumenta porque, cuando la configuración permite acceso anónimo, el atacante puede obtener un token de registro sin disponer de credenciales.
El procedimiento descrito por Red Hat se basa en solicitar un token anónimo al servicio /v2/auth y utilizarlo para alcanzar el mecanismo de rotación de claves.
El sistema comprueba que el token esté firmado por una clave reconocida y que cumpla determinados requisitos de audiencia y emisor. Sin embargo, no verifica que se trate de una credencial autorizada específicamente para rotar claves.
La consecuencia es que un cliente no autenticado puede llegar a instalar su propia clave de firma si el endpoint vulnerable está expuesto a usuarios no confiables.
Desactivar el acceso anónimo no constituye una solución completa. Red Hat advierte de que un usuario con una cuenta válida también puede aprovechar el problema.
CVE-2026-110697: robo de credenciales entre organizaciones
La segunda vulnerabilidad, CVE-2026-110697, tiene una puntuación de 9,9 sobre 10 y afecta al aislamiento de los usuarios dentro de instalaciones de Quay que alojan diferentes organizaciones o espacios de nombres.
En este caso, el fallo se encuentra en la función encargada de listar las cuentas técnicas, conocidas como robot accounts.
Estas cuentas se utilizan para que aplicaciones, servidores y procesos automatizados puedan autenticarse ante el registro de contenedores sin depender de las credenciales personales de un empleado.
El problema aparece cuando Quay construye una consulta SQL a partir del nombre de un espacio de nombres sin escapar correctamente determinados caracteres especiales.
En concreto, utiliza una consulta con el operador LIKE, en el que el carácter de guion bajo (_) funciona como comodín y representa cualquier carácter individual.
Un usuario con permiso para crear un espacio de nombres puede aprovechar esa particularidad para construir uno cuyo nombre coincida parcialmente con el de otra organización.
La consulta puede acabar devolviendo las cuentas técnicas de la organización afectada, incluidas sus credenciales descifradas.
El atacante no necesita privilegios elevados ni que la víctima realice ninguna acción.
Una vez obtenidos esos tokens, puede utilizarlos para:
- Consultar imágenes privadas de otra organización.
- Publicar contenido en sus repositorios.
- Sustituir imágenes legítimas por otras manipuladas.
- Interferir en los sistemas automatizados que dependen de esas credenciales.
La eliminación del espacio de nombres creado por el atacante también puede borrar las cuentas técnicas asociadas, lo que podría interrumpir servicios que dependan de ellas.
El riesgo para OpenShift y las cadenas de suministro de software
La segunda vulnerabilidad adquiere especial relevancia en entornos donde Quay está integrado con Red Hat OpenShift.
En estos sistemas, las cuentas técnicas pueden intervenir en procesos de integración y despliegue continuo, conocidos como CI/CD. Estos procesos automatizan la construcción, comprobación y distribución de aplicaciones.
Si un atacante consigue las credenciales de una cuenta técnica, podría introducir imágenes manipuladas en los repositorios y comprometer los procesos que posteriormente las descargan.
El riesgo no se limita, por tanto, a que alguien consulte información privada. También existe la posibilidad de que un componente alterado termine formando parte de una aplicación desplegada en producción.
Este escenario se conoce como un ataque a la cadena de suministro de software: el atacante compromete un elemento utilizado para construir o distribuir aplicaciones y aprovecha la confianza que otros sistemas depositan en él.
Qué versiones de Red Hat Quay están afectadas
Red Hat identifica como vulnerables versiones de las ramas Quay 3 y Quay 5. El aviso de The Hacker News también señala que el problema afecta a instalaciones independientes, despliegues mediante Quay Operator en OpenShift y registros espejo de Red Hat OpenShift.
La compañía advierte de que cualquier instancia accesible para clientes no confiables puede estar expuesta, incluso cuando se trata de un registro interno.
Para las ramas de Quay 3, Red Hat ha publicado las siguientes versiones corregidas:
| Rama | Versión corregida |
|---|---|
| Quay 3.9 | 3.9.28 |
| Quay 3.10 | 3.10.28 |
| Quay 3.12 | 3.12.24 |
| Quay 3.14 | 3.14.10 |
| Quay 3.15 | 3.15.9 |
| Quay 3.16 | 3.16.7 |
| Quay 3.17 | 3.17.7 |
| Quay 3.18 | 3.18.3 |
Red Hat también indica que Quay.io ya ha sido corregido respecto a CVE-2026-110697.
Los administradores deben comprobar la versión concreta de su instalación y consultar los avisos oficiales antes de actualizar. No conviene asumir que una rama no incluida en la lista dispone de una corrección equivalente.
Cómo proteger una instalación vulnerable
Red Hat recomienda instalar las versiones corregidas. En el caso de estas vulnerabilidades, la actualización es la medida necesaria para eliminar el problema de forma definitiva.
Mientras se prepara el despliegue, la compañía plantea distintas medidas de contención.
Medidas frente a CVE-2026-123710
Los administradores deben:
- Restringir el endpoint
/keysen el proxy inverso o balanceador de carga para que solo puedan acceder los componentes internos de confianza. - Revisar los registros de auditoría y localizar eventos
service_key_rotateyservice_key_deletecon el campoexpiration_dateestablecido ennull. - Identificar y eliminar las claves aprobadas que no reconozcan.
- Instalar la versión corregida de Quay lo antes posible.
La compañía advierte de que eliminar una clave sospechosa antes de instalar la corrección no resuelve definitivamente el problema. Mientras el sistema siga vulnerable, un atacante podría introducir otra clave.
Medidas frente a CVE-2026-110697
Para reducir la exposición al segundo fallo, Red Hat recomienda:
- Limitar quién puede crear organizaciones o espacios de nombres que contengan guiones bajos.
- Rotar los tokens de las cuentas técnicas de los espacios de nombres que puedan coincidir con otros mediante ese carácter.
- Vigilar las operaciones de descarga y publicación de imágenes que no se correspondan con el comportamiento habitual de las cuentas técnicas.
- Actualizar Quay a una de las versiones corregidas.
Estas medidas reducen el riesgo, pero no sustituyen la actualización del producto.
Un problema que va más allá de la privacidad: la integridad del software
Las vulnerabilidades de Red Hat Quay muestran por qué los registros de contenedores se han convertido en piezas críticas de la seguridad empresarial.
Una organización puede proteger sus servidores, restringir el acceso a sus aplicaciones y mantener sus sistemas actualizados. Sin embargo, si el repositorio desde el que obtiene las imágenes de software queda comprometido, toda esa cadena de protección puede verse debilitada.
El riesgo es especialmente relevante en empresas que comparten un mismo registro entre departamentos, clientes o equipos de desarrollo. Una brecha en el aislamiento entre espacios de nombres puede convertir una cuenta con permisos limitados en una vía para acceder a recursos de terceros.
También preocupa la posibilidad de introducir imágenes manipuladas. Un repositorio no solo almacena archivos: es una fuente de confianza para los procesos automatizados que construyen y despliegan aplicaciones.
Por eso, las organizaciones deberían revisar no solo las versiones instaladas, sino también los registros de auditoría, las claves autorizadas y las credenciales técnicas que utilizan sus procesos de desarrollo.
La advertencia para las empresas españolas
Las compañías españolas que utilicen Red Hat Quay, especialmente en infraestructuras basadas en OpenShift y Kubernetes, deberían comprobar inmediatamente si sus instalaciones están afectadas.
La revisión debe incluir tanto los registros accesibles desde Internet como aquellos que solo se encuentran disponibles dentro de redes corporativas. Que un registro sea interno no significa que esté fuera de peligro si usuarios o clientes no confiables pueden alcanzar el endpoint vulnerable.
Los responsables de tecnología y ciberseguridad deberían priorizar cuatro actuaciones:
- Inventariar todas las instalaciones de Quay y sus versiones.
- Comprobar si los endpoints de gestión de claves están expuestos.
- Buscar señales de rotación o eliminación de claves no autorizadas y revisar el uso de cuentas técnicas.
- Aplicar las versiones corregidas y evaluar si es necesario renovar credenciales o reconstruir imágenes comprometidas.
Si se detecta una clave desconocida o actividad anómala, la organización debe tratarlo como un posible incidente de seguridad y analizar qué repositorios, credenciales y sistemas consumidores podrían haberse visto afectados.
Red Hat ha publicado las correcciones, pero la protección efectiva depende de que los administradores las desplieguen. En una infraestructura que distribuye componentes a decenas o cientos de aplicaciones, aplazar esa actualización puede convertir un fallo de autenticación en un problema de seguridad para toda la organización.
La pregunta ya no es solo quién puede acceder a un repositorio privado, sino quién garantiza que el software descargado de él sigue siendo legítimo.
Chollones
Chollones
Chollones
Police to be camouflage eau de toilete 40ml vaporizador + champu perfumado 100ml
31,00€
Ver en Chollones 🛒