GitLab ha publicado parches para CVE-2026-110264, un fallo de gravedad máxima (CVSS 10.0) que permite a un atacante sin credenciales ejecutar código en servidores GitLab autoalojados. No afecta a GitLab.com. Si tu empresa o tu proveedor tiene un GitLab propio, actualiza hoy a una versión corregida, aunque ya aplicaras el parche del 12 de octubre.
Lo esencial
- CVE-2026-110264, CVSS 10.0. Es un desbordamiento de enteros en el compilador de expresiones regulares de GitLab. Según GitLab, en determinadas condiciones permite a un usuario no autenticado ejecutar código arbitrario en el servidor. Los parches salieron el 21 de octubre (BleepingComputer).
- Versiones corregidas de GitLab CE y EE: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13.
- Alcance: según The Hacker News, afecta a todas las versiones autoalojadas desde la 7.0, de 2014.
- El parche del 12 de octubre no basta. Corregía CVE-2026-97229 (también CVSS 10.0) y solo cubría la 19.2 y posteriores. Quien actualizó entonces sigue siendo vulnerable.
- Sin ataques conocidos. GitLab no ha detectado explotación y la CISA no lo incluía en su catálogo KEV a 22 de octubre. El INCIBE-CERT y el CCN-CERT lo publicaron el 22 de octubre.
¿Me afecta si uso GitLab.com o GitLab Dedicated?
No. GitLab.com ya ejecuta la versión parcheada. Los tenants de GitLab Dedicated con 19.3.5-internal0 o 19.4.2-internal0, o posteriores, ya incluyen la corrección. El problema está en las instalaciones propias de GitLab CE o EE: las que tienes en tu servidor, en tu nube o en la de un proveedor que te lo gestiona.
Ya parcheé el 12 de octubre, ¿no estoy cubierto?
No. Aquel parche corregía otro fallo de la misma familia, en el mismo motor de expresiones regulares. Este es nuevo. Según The Hacker News, es el cuarto fallo de ejecución de código en ese motor que reporta el mismo investigador (alias joaxcar) en un mes. Tienes que volver a actualizar.
Tampoco hay atajo. GitLab no ha explicado qué condiciones hacen falta para explotarlo y no ofrece ninguna mitigación provisional. Solo actualizar protege con certeza.
¿Y si mi versión es muy antigua?
La política habitual de GitLab solo cubre la versión actual y las dos anteriores (19.5, 19.4 y 19.3). Esta vez hay parches hasta la rama 18.11. Si estás en una versión más antigua que cualquiera de las ramas corregidas, no tienes parche: debes saltar a una versión soportada.
Qué hacer hoy
- Averigua si tienes un GitLab propio. Pregunta a tu equipo técnico o a tu proveedor de TI. Piensa en código, CI/CD y repositorios de clientes.
- Comprueba la versión que ejecuta cada instancia.
- Restringe el acceso mientras preparas la actualización: solo por VPN o con una lista de IP permitidas. No hay mitigación oficial, así que reducir quién llega al servidor es lo único que tienes.
- Actualiza a 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13, según tu rama. Si estás por debajo, salta a una versión soportada.
- Revisa los registros en busca de actividad extraña. Si tienes dudas, rota los tokens y secretos de CI/CD.
- Si el GitLab lo gestiona un tercero (agencia, consultora o hosting), pídele por escrito confirmación de que está parcheado.
Qué significa para una pyme
Un servidor GitLab no es una herramienta más. Guarda tu código, los de tus clientes y, sobre todo, los secretos de CI/CD: credenciales de nube, claves de despliegue, accesos a producción. Quien ejecuta código ahí tiene una puerta a casi todo lo demás.
Que no haya ataques conocidos no es motivo para esperar. Un fallo de CVSS 10.0, sin credenciales y sin mitigación provisional, es justo el tipo de fallo que se explota en cuanto alguien publica los detalles.
La lección de fondo es otra. Cuatro fallos de ejecución de código en el mismo motor en un mes indican que vendrán más. Parchear una vez y olvidarse no sirve. Si tienes un GitLab propio, necesitas a alguien que vigile los avisos y actualice en días, no en semanas. Y conviene preguntarse dos cosas: ¿de verdad tiene que estar expuesto a internet? ¿Compensa mantenerlo frente a GitLab.com o GitLab Dedicated, donde esta vez no has tenido que hacer nada? Si no tienes claro quién responde a esas preguntas en tu empresa, es un buen momento para ordenarlo con apoyo en ciberseguridad.
Preguntas frecuentes
¿Hay alguna configuración que me proteja sin actualizar?
No. GitLab no ofrece mitigación provisional. Limitar el acceso por VPN o lista de IP reduce la exposición mientras actualizas, pero solo el parche protege con certeza.
¿Se está explotando ya?
GitLab no ha detectado ataques y la CISA no lo incluía en su catálogo de vulnerabilidades explotadas a 22 de octubre.
¿Tengo que hacer algo si uso GitLab.com?
No. GitLab.com ya está parcheado, igual que GitLab Dedicated en las versiones indicadas.
