CVE-2026-97229 es una vulnerabilidad crítica de GitLab que puede permitir la ejecución remota de código sin autenticación mediante una expresión regular manipulada en la configuración de CI/CD. Los administradores de instancias autogestionadas que ejecuten las versiones afectadas 19.2, 19.3 o 19.4 de GitLab deben instalar, respectivamente, las versiones 19.2.8, 19.3.5 o 19.4.2. GitLab.com ya había sido parcheado cuando GitLab divulgó el fallo el 12 de octubre de 2026.
¿Qué es CVE-2026-97229?
CVE-2026-97229 es una vulnerabilidad de desbordamiento de enteros o wraparound, clasificada como CWE-190, en el procesamiento de expresiones regulares de GitLab CI/CD. GitLab informó el 12 de octubre de 2026 de que una expresión regular especialmente manipulada podía, en determinadas condiciones, permitir que un atacante sin autenticación ejecutara código arbitrario en el servidor de GitLab.
La vulnerabilidad tiene una puntuación CVSS v3.1 de 10,0 Crítica, según el registro CVE publicado el 13 de octubre de 2026. Su vector describe un ataque accesible a través de la red, con baja complejidad, sin privilegios necesarios ni interacción del usuario, con cambio de alcance y un impacto alto en la confidencialidad, la integridad y la disponibilidad.
La ejecución remota de código es una clase de vulnerabilidad que permite a un atacante ejecutar comandos o software en un sistema objetivo desde otro dispositivo. En un servidor de GitLab, el alcance potencial del impacto va más allá de la aplicación web: los repositorios, las variables de CI/CD, las credenciales de los runners, los tokens de implementación, los registros de paquetes y los entornos de producción conectados pueden requerir una revisión tras una posible intrusión.
La puntuación de 10,0 describe la gravedad técnica, no demuestra que se hayan producido ataques. Esa distinción es importante. La puntuación máxima justifica aplicar parches de emergencia, pero no justificaría afirmar que se ha producido una brecha sin pruebas que lo respalden.
¿Qué versiones de GitLab están afectadas por CVE-2026-97229?
CVE-2026-97229 afecta a GitLab Community Edition y Enterprise Edition 19.2.x anteriores a 19.2.8, 19.3.x anteriores a 19.3.5 y 19.4.x anteriores a 19.4.2, según el aviso de GitLab del 12 de octubre de 2026. Las ramas anteriores no figuraban como afectadas por esta vulnerabilidad concreta.
| Rama de la versión | Versiones afectadas | Primera versión corregida | Respuesta necesaria |
|---|---|---|---|
| GitLab 19.2 | 19.2.x anteriores a 19.2.8 | 19.2.8 | Actualice de inmediato |
| GitLab 19.3 | 19.3.x anteriores a 19.3.5 | 19.3.5 | Actualice de inmediato |
| GitLab 19.4 | 19.4.x anteriores a 19.4.2 | 19.4.2 | Actualice de inmediato |
| Ramas anteriores | No figuran como afectadas por este CVE | No aplicable | Seguir la política habitual de versiones compatibles |
No te detengas en 19.3.4. GitLab indicó el 13 de octubre de 2026 que 19.3.4 contenía un error de integración con Ona que afectaba a las páginas de solicitudes de fusión, por lo que la versión corregida designada para esa rama es la 19.3.5. Un espejo de paquetes o una regla de automatización fijada una versión por detrás te dejaría en la compilación incorrecta.
GitLab también indica que un aviso se aplica a todos los tipos de implementación cuando no identifica un tipo de instalación concreto, como un paquete de Linux, una instalación desde el código fuente o una implementación mediante Helm. Por tanto, los administradores deben evitar suponer que los contenedores o las instalaciones de Kubernetes quedan fuera del aviso.
GitLab.com ya había recibido la corrección cuando apareció el aviso el 12 de octubre de 2026. A los clientes de GitLab Dedicated se les comunicó que no era necesario realizar ninguna acción. El trabajo urgente de corrección corresponde a las organizaciones que operan instancias autogestionadas.
¿Cómo se comprueba la versión instalada de GitLab?
Según la documentación de GitLab consultada el 13 de octubre de 2026, los administradores de GitLab pueden identificar la versión de una instancia autenticada abriendo Ayuda y, después, Ayuda en la interfaz de GitLab. Las instalaciones mediante paquetes de Linux también registran las versiones de los componentes instalados en /opt/gitlab/version-manifest.txt, lo que puede facilitar las comprobaciones del inventario cuando la interfaz no está disponible.
Haz un inventario de todas las instancias, no solo del nombre de host de producción conocido por el equipo de seguridad. Los sistemas de desarrollo, los nodos de recuperación ante desastres, los entornos de preproducción, los servidores de prueba expuestos a Internet y las implementaciones regionales olvidadas pueden contener el mismo código vulnerable de CI/CD y recibir menos supervisión.
Registra la edición, la versión completa, el método de implementación, la exposición pública, el responsable y el estado de actualización de cada servidor. Compara el número completo del parche con las versiones corregidas de GitLab; ver “19.4” por sí solo no basta para determinar que el sistema es seguro.
Los equipos que anteriormente respondieron a GitLab CVE-2026-85706 deben realizar igualmente un inventario nuevo. Las pruebas de corrección de un fallo de GitLab no demuestran que las versiones posteriores con parches se hayan instalado en todos los entornos.
¿Cómo deben aplicar los administradores el parche para CVE-2026-97229?
Los administradores deben actualizar cada instancia autogestionada de GitLab afectada a la versión corregida correspondiente a su rama actual: 19.2.8, 19.3.5 o 19.4.2. El aviso de lanzamiento de GitLab del 12 de octubre de 2026 indica que los parches incluyen migraciones de base de datos, por lo que la planificación del mantenimiento debe tener en cuenta la topología de la implementación y el trabajo de migración.
Utiliza el procedimiento de actualización compatible de GitLab para tu método de instalación y conserva una copia de seguridad recuperable antes de modificar el sistema. Lee las notas de la versión, confirma que hay espacio de almacenamiento disponible, comprueba el estado de la base de datos y prueba la misma ruta de actualización en un entorno de no producción representativo cuando las limitaciones operativas lo permitan.
La siguiente secuencia de respuesta mantiene la aplicación de parches, la validación y la conservación de pruebas en un orden práctico:
- Haz un inventario de todos los servidores autogestionados de GitLab e identifica su versión completa instalada.
- Restringe el acceso público evitable mientras preparas la actualización, sin considerar la reducción de la exposición como un sustituto del parche.
- Realiza copias de seguridad de la configuración, los repositorios, los secretos y las bases de datos mediante el proceso de recuperación probado de la organización.
- Instala GitLab 19.2.8, 19.3.5 o 19.4.2 para la rama afectada correspondiente.
- Completa las migraciones de base de datos y posteriores a la implementación necesarias y, a continuación, comprueba su estado.
- Confirma la versión mostrada, prueba el acceso a los repositorios y ejecuta una canalización de CI/CD controlada.
- Revisa la actividad reciente de las canalizaciones y del servidor, conservando los registros sospechosos antes de que la retención rutinaria los elimine.
GitLab informó en 2026 de que las actualizaciones de un solo nodo que implican estas migraciones provocan una interrupción, mientras que las actualizaciones de varios nodos realizadas correctamente pueden evitarla. La versión 19.3.5 también incluye migraciones posteriores a la implementación. En términos sencillos, descargar el paquete es solo una parte del trabajo; después debes verificar el estado de la aplicación y de las migraciones.
Un cálculo de tiempo útil es sencillo. Si una organización posee 24 instancias y necesita 15 minutos para inventariar y validar cada una, la gestión secuencial consume 360 minutos, es decir, 6 horas, antes de resolver problemas. Si cuatro administradores trabajan en paralelo, esa ventana nominal de validación se reduce a 90 minutos, suponiendo cargas de trabajo equivalentes y que no fallen las actualizaciones.
Sinceramente, posponer un parche de servidor de gravedad máxima para conservar una ventana de mantenimiento rutinaria tiene poco sentido cuando es posible ejecutar código sin autenticación. Para una disciplina de triaje más amplia, el mismo enfoque de priorización de activos utilizado para versiones de parches de gran volumen puede ayudar a separar los servidores de GitLab expuestos públicamente de los sistemas internos de menor riesgo.
¿Se ha explotado CVE-2026-97229 en la naturaleza?
Ninguna fuente autorizada revisada había confirmado una explotación activa de CVE-2026-97229 a fecha del 13 de octubre de 2026. Tenable clasificó la vulnerabilidad como «en seguimiento» mientras buscaba pruebas de concepto o información sobre explotación; el estado de seguimiento no demuestra que los atacantes hayan explotado el fallo en entornos reales.
El aviso de GitLab confirma la existencia de la vulnerabilidad, las versiones afectadas, la posible ejecución de código sin autenticación y las correcciones disponibles. No demuestra que se haya atacado un servidor concreto. Los administradores deben mantener separadas esas afirmaciones en los informes de incidentes, las actualizaciones para la dirección y las comunicaciones con los clientes.
No se encontraron indicadores de compromiso proporcionados por el proveedor ni firmas de búsqueda específicas para CVE en las fuentes revisadas el 13 de octubre de 2026. Hasta que aparezca información más concluyente, examine cambios inesperados en la configuración de CI/CD, ejecuciones anómalas de canalizaciones, bloqueos de workers, procesos de servidor desconocidos, mecanismos de persistencia creados recientemente y conexiones salientes inusuales.
Revise los registros de acceso y los eventos de auditoría relacionados con la creación o modificación sospechosa de canalizaciones, pero no espere que una sola línea del registro resuelva la cuestión. Si el compromiso del host es plausible, conserve las pruebas volátiles, aísle el servidor según exija su plan de respuesta a incidentes, rote las credenciales expuestas e investigue los runners conectados y los destinos de despliegue. La lógica de respuesta se parece a la búsqueda de persistencia descrita en la guía de aplicación de parches y búsqueda de JFrog Artifactory.
Un análisis de vulnerabilidades limpio después de actualizar demuestra que la versión detectada ha cambiado; no demuestra que el servidor nunca se comprometiera antes de aplicar el parche. Ese caso límite, que a menudo se pasa por alto, es la razón por la que la corrección y la búsqueda de amenazas deben llevarse a cabo como líneas de trabajo relacionadas, pero independientes.
¿Cómo puede reducir la exposición de GitLab después de aplicar el parche?
GitLab recomienda desactivar la creación innecesaria de cuentas y restringir la visibilidad Pública para reducir la exposición evitable, según sus directrices de administración disponibles en 2026. Estos controles de refuerzo pueden limitar las vías de acceso, pero ninguno corrige CVE-2026-97229 ni sustituye a la instalación de GitLab 19.2.8, 19.3.5 o 19.4.2.
Limite el acceso de red a las interfaces administrativas cuando los requisitos empresariales lo permitan, revise quién puede modificar la configuración de CI/CD y proteja las variables de alto valor con el alcance y los controles de entorno adecuados. También debe examinar el registro de runners, los tokens obsoletos, la conectividad saliente y las integraciones que pueden convertir el compromiso de un host de GitLab en acceso a otros sistemas.
La visibilidad pública de los proyectos y el registro abierto pueden ser decisiones de producto legítimas. No los desactive a ciegas. Documente el motivo empresarial, aplique una supervisión compensatoria y asegúrese de que el responsable de la decisión entiende que una plataforma de desarrollo accesible públicamente atrae más escaneos y abusos.
La confianza en CI/CD también depende de lo que las herramientas automatizadas introducen en los repositorios y los archivos de compilación. Los equipos que adopten sistemas de generación de código deben tener en cuenta los riesgos de dependencias creados por la programación asistida por IA como parte de su revisión posterior a la aplicación del parche.
Preguntas frecuentes
¿Afecta CVE-2026-97229 a GitLab.com?
GitLab.com ya tenía aplicado el parche cuando GitLab publicó su aviso el 12 de octubre de 2026. A los clientes de GitLab Dedicated se les comunicó que no era necesario realizar ninguna acción.
¿Está GitLab 19.3.4 a salvo de esta vulnerabilidad?
GitLab 19.3.4 no es la versión designada como corregida para CVE-2026-97229. GitLab indica a los administradores de la rama 19.3 que instalen la versión 19.3.5, que también evita un error de integración con Ona que afectaba a las páginas de solicitudes de fusión en 19.3.4.
¿Puede un cortafuegos sustituir a la actualización de seguridad de GitLab?
Un cortafuegos puede reducir la exposición, pero no puede corregir el procesamiento vulnerable de expresiones regulares de CI/CD en GitLab. Las instalaciones autogestionadas afectadas siguen requiriendo la versión corregida adecuada de octubre de 2026.
¿Demuestra una puntuación CVSS de 10,0 que ha habido explotación?
Una puntuación CVSS v3.1 de 10,0 describe la gravedad técnica y el impacto potencial de la vulnerabilidad. La puntuación de 2026 no demuestra que CVE-2026-97229 se haya explotado contra sistemas reales.