CISA confirma ataques a la falla CVE-2026-97229 de GitLab: actualizar puede no alcanzar
La CISA, la agencia de ciberseguridad del gobierno de Estados Unidos, sumó el 29 de octubre de 2026 la falla CVE-2026-97229 de GitLab a su catálogo de vulnerabilidades explotadas (KEV), «sobre la base de evidencia de explotación activa». Es crítica: GitLab le asigna un CVSS de 10,0, el máximo de la escala. Según GitLab, en ciertas condiciones permite que alguien sin iniciar sesión ejecute código en el servidor con una expresión regular armada a propósito dentro de una configuración de CI/CD (los archivos que definen los pipelines). GitLab la corrigió el 12 de octubre en las versiones 19.4.2, 19.3.5 y 19.2.8 de Community Edition y Enterprise Edition.
A quién le importa: a quien administra su propio GitLab (lo que GitLab llama self-managed), sea una empresa, una agencia de desarrollo o un equipo con un servidor propio. Según GitLab, la falla afecta a las ramas 19.2, 19.3 y 19.4 sin el parche. Si usás GitLab.com, no tenés que hacer nada: GitLab dice que ya corre la versión corregida, y lo mismo vale para GitLab Dedicated.
Qué hacer hoy: actualizar a la versión de parche más nueva de tu rama. Y ojo con la trampa que contó Alpine Linux: si tu GitLab corre con un Ruby propio (instalado desde el código fuente o en una imagen de contenedor armada por vos), actualizar GitLab no alcanza. El error de fondo está en el motor de expresiones regulares de Ruby, y GitLab lo corrige con un parche al Ruby que viene en sus paquetes e imágenes oficiales. Con otro Ruby necesitás, además, Ruby 3.3.13, 3.4.12, 4.0.9 o posterior.
Qué hacer contra GitLab CVE-2026-97229, según cómo tengas GitLab
| Tu caso | Qué hacer |
|---|---|
| GitLab.com | Nada. GitLab dice que ya corre la versión corregida. |
| GitLab Dedicated | Nada. Según GitLab, todas sus instancias se corrigieron antes de publicar el parche. |
| Servidor propio con los paquetes o las imágenes oficiales de GitLab | Actualizar. Contra esta falla, como mínimo 19.4.2, 19.3.5 o 19.2.8; lo recomendable es la versión de parche más nueva de tu rama (abajo, por qué). |
| Servidor propio en una rama anterior a la 19.2 | Actualizar igual. Según GitLab, a esas versiones no las alcanza esta falla pero sí la CVE-2026-110264 (abajo): como mínimo 19.1.9, 19.0.10 o 18.11.13. |
| Servidor propio con tu propio Ruby (instalación desde el código fuente o imagen armada por vos) | Actualizar GitLab y además Ruby, a 3.3.13, 3.4.12, 4.0.9 o posterior. |
| Una aplicación Ruby propia que compila expresiones regulares que escribe el usuario | Actualizar Ruby a esas mismas versiones. Si solo usa expresiones regulares escritas por sus desarrolladores, según Ruby no está afectada. |
Fuentes: GitLab (notas de parche del 12 y del 21 de octubre de 2026), Ruby (23 de octubre) y Alpine Linux.
Por qué conviene ir a la última versión y no al mínimo: el 21 de octubre GitLab publicó otro parche crítico (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13) por la CVE-2026-110264, otro desbordamiento en el compilador de expresiones regulares, también con CVSS de 10,0. Esa no figura en el KEV, pero según GitLab afecta a muchas más versiones: desde la 7.0. O sea que tener un GitLab viejo, anterior a la 19.2, no te deja a salvo de la familia. Las más nuevas que encontramos en la documentación de GitLab el 30 de octubre son 19.5.3, 19.4.5, 19.3.7 y 19.2.10, y para las ramas viejas, 19.1.10, 19.0.11 y 18.11.14.
Para quien quiera revisar si ya intentaron atacarlo, GitLab publicó seis detecciones para instancias propias junto con el parche, enlazadas desde su nota de seguridad. Una de ellas busca caídas de los procesos de trabajo del motor de expresiones regulares. La escala del problema la da otro dato: según BleepingComputer, la organización Shadowserver ve casi 2.800 instancias de GitLab Community Edition expuestas en internet, aunque no informa cuántas ya se actualizaron.
Lo que le pasó a Alpine Linux
Alpine Linux, una distribución liviana muy usada en contenedores, contó en su sitio que un atacante intentó explotar esta falla contra su GitLab, donde mantiene aports, el repositorio del que salen sus paquetes. Según su informe, el 20 de octubre una cuenta recién registrada empezó a sondear y entre el 20 y el 21 mandó configuraciones de CI/CD armadas a propósito. Su instancia corría la 19.3.4, que no tenía el arreglo: el 13 de octubre habían instalado esa versión por error, en lugar de la 19.3.5. Los procesos de GitLab se cayeron 8 veces, y en 4 de esas caídas el atacante avanzó una parte del exploit y falló en el paso siguiente. También se bajó la imagen de contenedor del GitLab de Alpine, lo que para Alpine sugiere que estaba ajustando el ataque a esa versión exacta.
Lo más útil para cualquier administrador vino después. El 22 de octubre Alpine actualizó a la 19.3.6, que ya tenía el arreglo, y siguió vulnerable. Su conclusión, en una línea: «Nuestra actualización no corrigió la vulnerabilidad» (traducido del inglés). Su imagen usaba el Ruby estándar, y el arreglo no está en el código de GitLab sino en un parche a Ruby que GitLab aplica solo en sus paquetes oficiales. Lo descubrieron el 26 de octubre; el 27 cerraron el GitLab a todos salvo a sus desarrolladores y servidores de compilación, y lo reconstruyeron desde cero.
Alpine dice que no encontró evidencia de que el atacante haya ejecutado código, pero que no lo puede descartar, porque un ataque exitoso no deja caídas ni rastros en los registros web y algunos registros de esos días ya no existen. Por eso trató la instancia como comprometida: reseteó todas las contraseñas y reemplazó las claves secretas de GitLab. Según las verificaciones que hizo el 24 de octubre, no encontró señales de que sus paquetes o las versiones publicadas el 21 de octubre hayan sido alterados; como la instancia siguió vulnerable hasta el 27, está extendiendo esos controles hasta esa fecha. Las claves que firman los paquetes nunca estuvieron en ese servidor. El 29 de octubre lo reabrió con la 19.3.7, y el 30 avisó que volvió a estar abierto para todos.
Si tenés cuenta en gitlab.alpinelinux.org, Alpine pide crear una contraseña nueva con «Forgot your password?» y, si usabas la misma en otro lado, cambiarla también ahí: dice que vio intentos automáticos de inicio de sesión con contraseñas filtradas de otros sitios. Y si usás su imagen alpinelinux/gitlab, hay que volver a bajar la 19.3.6: solo la publicada el 27 de octubre trae Ruby 3.3.13.
The Hacker News vincula el alta en el KEV con este incidente. La CISA no lo dijo: su aviso no detalla qué ataques vio ni si alguno tuvo éxito.
El fondo: un error en el motor de expresiones regulares de Ruby
Las expresiones regulares ya tenían fama de ilegibles; ahora además fueron una puerta de entrada. GitLab compila con Ruby las expresiones regulares que escriben sus usuarios, por ejemplo en la configuración de CI. El problema está en Onigmo, el motor de expresiones regulares que viene dentro de Ruby: un patrón armado a propósito puede corromper la memoria mientras Ruby lo compila. El 23 de octubre Ruby publicó las versiones 4.0.9, 3.4.12 y 3.3.13, que corrigen los errores detrás de cuatro CVE de GitLab: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 y CVE-2026-110264.
Según Ruby, el riesgo aparece solo cuando una aplicación compila una expresión regular a partir de un texto que controla un atacante. Dos aclaraciones suyas importan para quien programa en Ruby: el límite de tiempo de las expresiones regulares (Regexp.timeout) no protege contra estos errores, y limitar el largo de los patrones tampoco, porque algunos se disparan con patrones cortos. Si no podés actualizar, Ruby recomienda no compilar expresiones regulares que vengan de entradas no confiables. Ruby no pidió CVE propios por ahora y sugiere usar los de GitLab para rastrear estos problemas, por ejemplo en un escáner de seguridad. La propia ficha del KEV advierte que otros productos pueden estar afectados por el mismo error de Ruby.
Para las agencias civiles del Poder Ejecutivo federal de Estados Unidos, la CISA fijó como fecha límite el 1 de noviembre de 2026. Esa obligación no alcanza a nadie más, pero es un buen termómetro: cuando la CISA da tres días, el parche no es para la semana que viene.
Fuentes
- CISA, «CISA Adds Two Known Exploited Vulnerabilities to Catalog», 29 de octubre de 2026 (en inglés), y la ficha de CVE-2026-97229 en el catálogo KEV. El alta por explotación activa, la fecha límite federal y la advertencia sobre otros productos.
- GitLab, «GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8», 12 de octubre de 2026 (en inglés). La falla, las versiones afectadas y corregidas, el CVSS y las detecciones.
- GitLab, «GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13», 21 de octubre de 2026, y notas de la 19.5.3 (en inglés). CVE-2026-110264 y las versiones más recientes.
- Ruby, «Regexp compilation fixes related to GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264», 23 de octubre de 2026 (en inglés). El error en Onigmo, a quién afecta y qué versiones lo corrigen.
- Alpine Linux, «GitLab security incident: attempted exploitation of CVE-2026-97229», 28 de octubre de 2026, actualizado el 30 (en inglés). El intento de ataque, por qué la actualización no alcanzó y qué deben hacer sus usuarios.
- Sergiu Gatlan, «CISA says max severity GitLab flaw now exploited in the wild», BleepingComputer, 30 de octubre de 2026 (en inglés). El dato de Shadowserver.
- «CISA Adds Actively Exploited GitLab RCE and Cisco Firewall DoS Flaws to KEV», The Hacker News, 30 de octubre de 2026 (en inglés). El vínculo con el incidente de Alpine.
