GitLab CVE-2026-97229: la falla que ya se está atacando, a quién afecta y qué versión instalar

Qué pasó, en corto

• La falla: CVE-2026-97229, severidad 10 de 10 según GitLab. Afecta a GitLab CE y EE y puede permitir que alguien sin autenticarse ejecute código en el servidor.
• El primer parche: salió el 12 de octubre de 2026 en las versiones 19.4.2, 19.3.5 y 19.2.8.
• El segundo parche: salió el 21 de octubre para la CVE-2026-110264, también de severidad 10, que afecta desde la versión 7.0. Quien se quedó en el parche del 12 de octubre sigue expuesto a esta.
• Ya hay intentos reales: Alpine Linux reportó intentos contra su instancia el 20 y 21 de octubre, y otros bloqueados el 25 y 26. CISA agregó la falla a su catálogo el 29 de octubre.
• GitLab.com y GitLab Dedicated: no tienes que hacer nada. Esto es para instalaciones propias.

Versiones corregidas

Estas son las versiones del 21 de octubre, que cubren las dos fallas. También sirve cualquier versión posterior de la misma rama. Si estás en una rama vieja, sigue las paradas de actualización que exige GitLab y planea la ventana: algunas actualizaciones migran la base de datos y pueden causar caída en instalaciones de un solo nodo.

¿Mi GitLab está expuesto?

Si es propio y no está en una de las versiones de la tabla, hay que actualizar. Lo que cambia es la urgencia:

• Urgencia máxima: accesible desde internet, con proyectos públicos y registro abierto. Rapid7 explica que el ataque que demostró necesita poder subir cambios a un proyecto público, y que el registro abierto prácticamente elimina esa barrera.
• Urgencia alta: accesible desde internet, aunque el registro esté cerrado. Una cuenta de un contratista o un exempleado que siga activa puede ser suficiente.
• Urgencia menor, pero igual hay que actualizar: solo accesible por VPN o red interna. Restringir el acceso reduce la exposición, no elimina la falla.

Cómo revisar, según dónde corre

• Consola web: entra como administrador al Admin area y mira la versión en el panel principal.
• Servidor con paquete oficial (EC2 o VPS): corre sudo gitlab-rake gitlab:env:info y compara con la tabla.
• Contenedores (Docker, ECS, EKS): revisa la etiqueta de la imagen que está corriendo, no la que aparece en tu archivo de despliegue.
• Las que nadie recuerda: servidores de prueba, instalaciones de un equipo o un proveedor, y copias viejas. Busca en cada cuenta y cada región de AWS antes de dar el tema por cerrado.

Qué hacer, en orden

1. 1. Actualizar a una versión de la tabla. GitLab no publicó un workaround para la CVE-2026-97229, así que esta es la solución.
2. 2. Si no puedes actualizar hoy, limita el acceso con el grupo de seguridad a tu VPN u oficina, desactiva el registro abierto y evita que usuarios no confiables creen proyectos públicos o escriban en ellos. Baja el riesgo, pero no lo corrige.
3. 3. Buscar señales de intrusión: procesos hijos raros de Puma, archivos nuevos del usuario git en /tmp y cambios en sus crontabs o llaves SSH. GitLab también publicó detecciones para esta falla.
4. 4. Si encuentras algo, cambia el contenido de gitlab-secrets.json, las variables de CI/CD y los tokens de runners y de acceso, y revisa los pipelines y repositorios en busca de cambios.

Si tu GitLab despliega en AWS

El riesgo no termina en el servidor. Las variables de CI/CD, los tokens de runners y las llaves de despliegue suelen dar acceso a producción. Tres cosas para revisar:

• Llaves de AWS en las variables de CI/CD. Si tuviste el servidor expuesto sin parche, trátalas como comprometidas: cámbialas y revisa su uso en CloudTrail.
• Permisos de esas llaves. Una llave de despliegue no debería poder administrar toda la cuenta.
• Llaves de larga duración. GitLab puede asumir roles de AWS con OIDC y credenciales temporales, sin guardar llaves fijas.

Preguntas frecuentes