Si tu empresa ejecuta GitLab en su propio servidor, actualízalo hoy. El 12 de octubre de 2026, GitLab publicó un parche de seguridad crítico que corrige 24 vulnerabilidades. La peor, CVE-2026-97229, recibió la puntuación de gravedad más alta posible: 10 sobre 10. Permite que alguien sin cuenta en tu servidor ejecute su propio código en él. Todo servidor que ejecute las versiones 19.2 anteriores a 19.2.8, 19.3 anteriores a 19.3.5 o 19.4 anteriores a 19.4.2 está afectado. La única solución que indica GitLab es actualizar a 19.4.2, 19.3.5 o 19.2.8. Si usas el servicio en la nube de GitLab.com, no necesitas hacer nada.

¿Qué es GitLab y por qué debería importarle a un empresario?

GitLab es donde tu equipo técnico guarda el código fuente de tus sistemas y aplicaciones, y donde se compilan las nuevas versiones y se envían a tus servidores. Muchas empresas lo ejecutan en un servidor interno en lugar del servicio en la nube, para mantener el código y los datos dentro de la organización. Ese servidor suele contener más de lo que el propietario imagina: el código fuente completo, las contraseñas de las bases de datos, las claves que te conectan con pasarelas de pago y servicios gubernamentales, y el permiso para desplegar en los servidores que usan tus clientes. Quien lo controle puede leer todo eso y puede modificar tu código antes de que llegue a tus clientes.

¿Qué anunció exactamente GitLab?

Según el anuncio oficial del parche de GitLab, la falla está en la parte que procesa expresiones regulares dentro de la configuración de los pipelines de compilación y despliegue (CI/CD). Una expresión regular es un texto breve que describe un patrón de búsqueda. El anuncio indica que la falla podría permitir que un usuario no autenticado ejecute código arbitrario en el servidor de GitLab mediante una expresión regular especialmente diseñada, debido a una validación insuficiente de esas expresiones. Un investigador la reportó a través del programa de recompensas por errores de GitLab en HackerOne.

El anuncio no dice que la falla haya sido explotada. Pero una puntuación de 10 significa que puede explotarse a través de internet, sin contraseña y sin ayuda de ningún empleado. Los atacantes suelen empezar a buscar fallas como esta a los pocos días de que se publica una corrección, porque la propia corrección señala dónde está la debilidad.

¿Qué más incluye el parche?

El mismo parche corrige otras 23 vulnerabilidades, cinco de ellas calificadas como altas:

  • Una inyección de scripts maliciosos (XSS) en el resaltado de sintaxis, con una puntuación de 8.7.
  • Una falla de autorización al crear pipelines, con una puntuación de 8.5.
  • Una expresión regular demasiado permisiva que afecta al acceso a archivos, con una puntuación de 8.2.
  • Una falla de autorización en las políticas de ejecución de pipelines de la edición de pago, con una puntuación de 7.7.
  • Una falla de inyección de prompts en el agente de IA GitLab Duo de la edición de pago, con una puntuación de 7.3.

Así que las versiones anteriores a 19.2, a las que no afecta la falla crítica, no son necesariamente seguras. La política oficial de mantenimiento de GitLab indica que las correcciones de seguridad solo se aplican a la versión actual y a las dos versiones mensuales anteriores. Un servidor con una versión más antigua ya no recibe ninguna corrección de seguridad y necesita una actualización de todos modos.

¿Quién debe actuar?

  • Usuarios de la nube GitLab.com: no hay nada que hacer; GitLab dice que el servicio ya ejecuta la versión parcheada.
  • Clientes de GitLab Dedicated: tampoco tienen nada que hacer, según el anuncio.
  • Cualquiera que ejecute GitLab en su propio servidor: actualice de inmediato. Esa es la recomendación explícita de GitLab para toda instalación autogestionada.
  • Cualquiera que no sepa dónde se ejecuta su GitLab: pregunta hoy a tu equipo o al proveedor que desarrolló tus sistemas. Muchos servidores internos fueron configurados por un proveedor anterior y luego olvidados.

Pasos prácticos para esta semana

  1. Averigua la versión: pide a tu responsable técnico que abra la página de Ayuda en GitLab, lea el número de versión que aparece allí y lo compare con los números anteriores.
  2. Programa la actualización hoy, no a fin de mes: según el anuncio de GitLab, un servidor de un solo nodo queda fuera de servicio durante el parche hasta que terminan las migraciones de la base de datos, mientras que las configuraciones de varios nodos pueden parchearse sin interrupción si se sigue el procedimiento adecuado sin tiempo de inactividad. Una hora de inactividad fuera del horario laboral cuesta mucho menos que un servidor comprometido.
  3. Si estás en 19.3: pasa directamente a 19.3.5, no a 19.3.4. El anuncio señala que 19.3.4 tenía un error que afectaba a las páginas de merge request cuando la integración con Ona estaba activada, corregido en 19.3.5.
  4. Reduce la exposición a internet: si nadie fuera de la empresa necesita acceder a tu servidor de GitLab, haz que solo acepte conexiones desde la red de la empresa o a través de una VPN. Esto no sustituye al parche, pero estrecha la puerta la próxima vez.
  5. Revisa después de parchear: examina los usuarios, claves y tokens de acceso creados recientemente. Si aparece algo que nadie reconoce, cambia las contraseñas y claves almacenadas en el servidor.

Los pasos de actualización para cada método de instalación están en la guía oficial de actualización de GitLab.

La visión de Origami

Usamos GitLab todos los días, ya que nuestros repositorios están allí, así que seguimos sus anuncios de seguridad tan de cerca como nuestras facturas. La lección va más allá de GitLab: todo sistema que ejecutas tú mismo para mantener tus datos en casa conlleva la obligación de parchearlo el mismo día en que llega una corrección. El problema que vemos con más frecuencia no es esa decisión en sí, sino que falta el nombre de quien es responsable de las actualizaciones. Un servidor que un proveedor configuró hace tres años, y del que nadie sabe quién lo mantiene, es lo primero que busca un atacante. Dijimos lo mismo sobre la falla de las tiendas Magento: parchear no basta si se hace tarde. Si necesitas que alguien revise tus servidores o se encargue de sus actualizaciones, ponte en contacto.

Fuentes