GitLab CVE-2026-97229: RCE CVSS 10 explotada, actualice ya

El reto principal es que esta falla reúne los dos rasgos que más valoran los atacantes, ninguna autenticación y ejecución total de código, y ya se probó contra un objetivo real. Según The Hacker News, la inclusión en la lista de CISA se vincula con un incidente divulgado por Alpine Linux. Un actor desconocido intentó explotar la falla contra la instancia GitLab de Alpine los días 20 y 21 de octubre de 2026, enviando configuraciones de CI manipuladas que hicieron fallar ocho veces los procesos de trabajo de GitLab. En cuatro de esas caídas el exploit falló en el paso siguiente. El atacante también descargó la imagen de contenedor de GitLab de Alpine.

Los intentos posteriores del 25 y 26 de octubre fueron bloqueados. Los responsables de Alpine afirmaron que el ataque estuvo cerca de funcionar, que no encontraron evidencia de que tuviera éxito pero no pueden descartarlo, y que por eso trataron la instancia como comprometida y la reconstruyeron desde cero. También informaron que su repositorio de paquetes y las versiones del 21 de octubre no fueron alterados. No se ha identificado a ningún actor.

Tres lecciones para los equipos empresariales:

• La ventana de parcheo fue real. La corrección se publicó el 12 de octubre y los intentos empezaron ocho días después. La explotación siguió de cerca a la disponibilidad del parche, el patrón habitual en fallas críticas.
• Las caídas son evidencia. Las caídas repetidas de procesos fueron la forma en que Alpine detectó la actividad. Muchas organizaciones no generan alertas por fallas de aplicación en herramientas de desarrollo.
• Reconstruir a veces es la respuesta correcta. Cuando no se puede demostrar que un servidor no fue comprometido, una reconstrucción limpia con secretos rotados es más segura que esperar.

GitLab también indica que los detalles técnicos completos se harán públicos 90 días después de la versión, es decir, no antes del 10 de enero de 2027. Hasta entonces es menos probable que circule código de exploit público, pero el incidente de Alpine muestra que atacantes capaces no esperaron.

La respuesta a CVE-2026-97229 consiste en identificar cada instancia autogestionada de GitLab, actualizar a una versión corregida, buscar señales de explotación y rotar los secretos a los que el servidor podía acceder. Siga estos pasos en orden.

1. Inventaríe cada instancia. Incluya el servidor de producción evidente y los olvidados: servidores de prueba, instancias de unidades de negocio y servidores heredados de adquisiciones. No se puede parchar lo que no se sabe que existe.
2. Verifique la versión. GitLab lista como afectadas todas las versiones desde la 19.2 anteriores a la 19.2.8, la 19.3 anteriores a la 19.3.5 y la 19.4 anteriores a la 19.4.2, tanto CE como EE. Las versiones corregidas son 19.2.8, 19.3.5 y 19.4.2. El aviso de GitLab no menciona soluciones alternativas, así que actualizar es el remedio.
3. Actualice ya y confirme. Programe una ventana de emergencia, actualice y verifique la versión en ejecución. Pruebe sus pipelines, porque una versión de parches de este tamaño incluye muchas otras correcciones. La misma versión resuelve unas dos docenas de vulnerabilidades, entre ellas CVE-2026-92883 (cross-site scripting, CVSS 8.7), CVE-2026-16301 (autorización indebida en pipelines descendentes, CVSS 8.5) y CVE-2026-14814 (CVSS 8.2).
4. Busque explotación. GitLab publicó seis detecciones de amenazas para instancias autogestionadas, que cubren señales como caídas del proceso Onigmo, expresiones regulares hostiles enviadas a la ruta GraphQL de CI lint, rutas no ASCII de tamaño excesivo, rechazos del filtro de expresiones, caídas del proceso de CI lint y ráfagas de errores de cliente en CI lint. Revise sus registros al menos desde el 12 de octubre y preste atención a descargas inesperadas de imágenes de contenedor.
5. Trate los hallazgos sospechosos como un compromiso. Si encuentra indicadores, siga el ejemplo de Alpine: aísle el servidor, reconstrúyalo desde una imagen limpia y restaure los datos desde una copia de seguridad confiable.
6. Rote los secretos. Las variables de CI/CD, claves de despliegue, tokens de registro de runners y credenciales de nube almacenados en GitLab deben rotarse si hay cualquier duda.
7. Reduzca la exposición. Una plataforma de código rara vez necesita estar abierta a todo internet. Colóquela detrás de un acceso privado y segmentado, como una red gestionada multioperador con VPN o acceso de confianza cero, y limite quién llega a CI lint y a los endpoints de la API.

Envíe los registros a un SIEM central para que un patrón de caídas en un servidor de desarrollo se convierta en una alerta y no en una nota al pie.

Tratar las plataformas de desarrollo con el mismo rigor que los sistemas de producción protege el software que usted entrega y a los clientes que dependen de él. Responder bien a esta falla aporta beneficios prácticos.

• Menor riesgo de cadena de suministro. Un servidor GitLab limpio, parchado y monitoreado reduce la probabilidad de que un atacante inserte código en sus compilaciones o robe los secretos con que se despliegan.
• Respuesta a incidentes más rápida y económica. Los registros centralizados y un procedimiento de reconstrucción probado convierten un posible compromiso en un ejercicio controlado. La reconstrucción desde cero de Alpine es un buen modelo, porque elimina la duda.
• Mejor postura ante auditorías y contratos. Clientes, aseguradoras y auditores preguntan cada vez más con qué rapidez se corrigen las vulnerabilidades explotadas activamente. Un proceso de parcheo guiado por KEV con fechas documentadas responde esa pregunta.
• Visibilidad de la infraestructura en la sombra. El inventario suele revelar servidores sin gestión. Encontrarlos en una semana tranquila cuesta mucho menos que hacerlo después de una brecha.
• Un manual repetible. Los mismos pasos sirven para la próxima falla crítica en una herramienta de CI/CD, un hipervisor o un equipo de borde, por lo que el esfuerzo se amortiza cada vez.

La fecha límite del 1 de noviembre de CISA aplica a las agencias civiles federales de EE. UU., pero es una referencia sensata para cualquier empresa. Si su GitLab autogestionado sigue hoy en una versión afectada, ya va por detrás del calendario público.

HIT Communications ayuda a las empresas a mantener plataformas críticas parchadas, monitoreadas y recuperables, para que un aviso de proveedor no se convierta en un incidente prolongado. Con más de 30 años de experiencia en América Latina, Estados Unidos y Europa, integramos redes, seguridad y operaciones de TI en un solo equipo.

Nuestros servicios de ciberseguridad incluyen SOC 24/7, SIEM y detección y respuesta gestionadas que ingieren registros de plataformas de desarrollo, firewalls y sistemas de identidad, y alertan tanto por caídas y anomalías como por firmas de ataque conocidas. Nuestros servicios gestionados de TI cubren la planificación de parches, la operación de infraestructura local y en la nube, y los respaldos, de modo que las actualizaciones de emergencia se programen, prueben y documenten en lugar de improvisarse.

Si opera GitLab autogestionado y no está seguro de qué versión tiene, quién puede acceder a él o qué secretos guarda, podemos ayudarle a inventariar las instancias, planificar la actualización con mínima interrupción y activar el monitoreo de las señales que GitLab publicó.

CVE-2026-97229 recuerda que los sistemas que construyen su software merecen la misma protección que los que lo ejecutan. Una falla CVSS 10.0 que no requiere inicio de sesión tiene corrección desde el 12 de octubre, un intento de ataque contra un proyecto muy conocido y una advertencia de CISA cuyo plazo federal ya venció.

Empiece hoy con tres acciones: liste cada instancia autogestionada de GitLab y su versión, actualice a 19.4.2, 19.3.5 o 19.2.8 o posterior, y busque en sus registros las señales de caídas y de CI lint que GitLab publicó. Si desea apoyo con el inventario, la ventana de mantenimiento o el monitoreo continuo, contacte al equipo de HIT Communications.