Qué corrige GitLab

El aviso de INCIBE del 24 de septiembre reúne once vulnerabilidades en GitLab CE y EE: dos críticas, dos altas, cinco medias y dos bajas. Las críticas CVE-2026-89078 y CVE-2026-93577 afectan al procesamiento de expresiones regulares. Un usuario autenticado podría introducir una configuración CI/CD manipulada y conseguir ejecución de código en el servidor.

La fuente no recoge explotación confirmada de estos dos fallos. Eso no demuestra que todas las instalaciones estén libres de incidentes.

Quién debe actuar y a qué versión actualizar

Las correcciones indicadas son 19.2.7, 19.3.3 y 19.4.1, o posteriores de la rama correspondiente. Los intervalos afectados cambian según la vulnerabilidad; no hay una única matriz válida para los once fallos.

INCIBE señala que el servicio GitLab ya utiliza una versión corregida y que los clientes de GitLab Dedicated no necesitan actuar. La revisión de versiones corresponde especialmente a instalaciones autogestionadas.

Análisis de Defensops: el riesgo está también en la cadena de entrega

Nuestra lectura operativa es que el servidor de desarrollo debe tratarse como infraestructura sensible, no como una herramienta aislada del negocio. Para planificar la revisión, conviene identificar qué proyectos generan entregas, dónde se guardan credenciales de despliegue y qué permisos tienen los usuarios que pueden modificar canalizaciones.

Recomendamos comprobar cuatro aspectos durante el cambio:

  1. Inventario completo. Instancias principales, entornos de pruebas y servidores olvidados deben tener un propietario y una versión comprobada, no inferida de una etiqueta de despliegue.
  2. Actualización validada. Preparar una copia recuperable y seguir la ruta compatible con la instalación. Tras el cambio, ejecutar una canalización representativa y comprobar acceso y funcionamiento.
  3. Permisos y secretos. Revisar quién modifica CI/CD y qué credenciales quedan accesibles para cada proyecto. Reducir permisos innecesarios complementa el parche; no lo sustituye.
  4. Revisión histórica proporcionada. Examinar cambios inesperados en configuraciones y actividad del servidor, correlacionándolos con tickets y autores legítimos antes de atribuirles carácter malicioso.

Un pipeline fallido o una expresión regular compleja no constituyen por sí mismos una intrusión. Si hay actividad no explicada, conservar el contexto del proyecto, usuario y ejecución ayuda a decidir si procede una investigación más profunda.

El cierre del cambio debería incluir la versión resultante y las pruebas realizadas. Haber aprobado una solicitud de actualización no equivale a demostrar que la instancia quedó corregida.

Fuente y actualización

Aviso de INCIBE del 24 de septiembre de 2026. Ampliación editorial: 27 de septiembre de 2026. Las recomendaciones operativas son análisis propio de Defensops.