Si corrés GitLab autoalojado, hay dos números y conviene no confundirlos.
El primero: la falla que CISA catalogó ayer como explotada, CVE-2026-97229, se corrige en 19.2.8, 19.3.5 o 19.4.2. Tiene CVSS 10,0 y permite a un usuario sin autenticarse ejecutar código en el servidor de GitLab.
El segundo, que es el que se pasa por alto: hay otra falla de la misma familia, también 10,0, la CVE-2026-110264, que pide versiones posteriores —19.2.9, 19.3.6 o 19.4.3— y que afecta un rango mucho más ancho, desde la 7.0. Actualizar a la 19.4.2 cierra la explotada y deja esa abierta.
Y una buena noticia para la mayoría: esto es un problema de instalaciones propias. GitLab dice que GitLab.com ya corría la versión parchada y que su infraestructura administrada, incluida GitLab Dedicated, sigue parchada. Si usás GitLab en la nube de GitLab, no tenés nada que hacer.
Cuatro CVE de la misma familia, cuatro versiones correctoras distintas
Las cuatro salen del mismo lugar y el mapeo lo publica Ruby, no GitLab. Lo que conviene mirar es la columna de versiones: ninguna de las cuatro se cierra con la misma. Un equipo que actualizó a la 19.4.1 en septiembre cubrió dos; el que ahora vaya a la 19.4.2 por el plazo de CISA cubre la tercera; y la cuarta pide 19.4.3.
Es la tercera vez esta semana que aparece el mismo patrón: ya lo vi en los tres parches sucesivos del orquestador de Arista y en la compilación posterior que pedía la falla de 2,7 de VMware ESX. No es casualidad del mes: es lo que pasa cuando varias fallas de un mismo componente se arreglan en tandas distintas.
Por qué CVE-2026-97229 es la única de las cuatro que no pide cuenta
Acá la explicación es prolija y vale decirla, porque responde la pregunta de por qué entre cuatro fallas casi idénticas el atacante eligió una.
Las dos de septiembre, CVE-2026-89078 y CVE-2026-93577, publicadas hace 36 días, puntúan 9,9 y las descripciones de GitLab dicen que podían permitir a un usuario autenticado llegar al defecto. La de ayer, CVE-2026-97229, puntúa 10,0 y dice "usuario no autenticado". Esa diferencia de una décima en el puntaje es, en la práctica, la diferencia entre necesitar una cuenta y no necesitarla.
El vector lo confirma: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. PR:N, sin privilegios, y S:C, alcance cambiado. Es el máximo que la escala 3.1 permite.
Y el camino de entrada explica el resto: la falla se alcanza por una expresión regular dentro de una configuración de CI/CD. En una instancia donde cualquiera puede registrarse, o donde hay proyectos públicos que aceptan contribuciones, una configuración de CI/CD es contenido que llega de afuera.
La falla no es de GitLab: es de Onigmo, el motor de regex de Ruby
Esto es lo que vuelve al caso más interesante que un parche más. El 23 de octubre, hace 7 días, Ruby publicó un post que mapea las cuatro CVE de GitLab contra defectos concretos de Onigmo, su motor de expresiones regulares, y ahí se ve que CVE-2026-93577 y CVE-2026-97229 son el mismo defecto: un desbordamiento de entero en el tamaño del patrón compilado, corregido por el cambio #19020. Dos identificadores distintos para un solo error, porque GitLab lo alcanzaba desde dos lugares distintos de su propio código.
Las versiones de Ruby que traen todas las correcciones son 4.0.9, 3.4.12 y 3.3.13. Y hay un detalle de política que vale notar: la rama 3.3 está en mantenimiento solo de seguridad, y Ruby dice que incluyó estas correcciones como excepción porque GitLab les asignó CVE. O sea que la política de versiones del proyecto de arriba se flexibilizó porque un proyecto de abajo decidió emitir identificadores.
Es el cuarto caso esta semana en que la falla está una capa más abajo de la aplicación: ya pasó con el intérprete de PHP y con el decodificador de Brotli dentro de Node.js y .NET.
Ruby decidió no pedir CVE propios, y eso tiene consecuencias
Hay una frase del post de Ruby que conviene leer dos veces: "No hemos solicitado identificadores CVE en Ruby para estas correcciones, al menos por ahora". El proyecto dice que va a discutir si pedirlos.
El resultado es raro de mirar: el mismo defecto es un 10,0 catalogado como explotado en el registro de GitLab y no tiene ningún CVE en el proyecto donde vive el código. No hay nada impropio —asignar un CVE es una decisión del que lo emite, y Ruby publicó el arreglo y lo documentó— pero sí tiene una consecuencia práctica concreta: si tu herramienta de inventario busca CVE de Ruby, no va a encontrar nada, porque no existen. La señal está en las CVE de GitLab y en el post de Ruby, no en la ficha de Ruby.
Es el otro lado del problema que medí el lunes sobre quién calcula los puntajes: ahí la pregunta era quién pone el número; acá es quién decide que haya ficha.
Si tenés una aplicación en Ruby y no GitLab, ¿te toca?
Para quien tiene una aplicación propia en Ruby, el post da una regla de exposición clara, y es la misma estructura que vimos ayer con Brotli: tener el componente no es estar expuesto.
Estás afectado si tu aplicación compila una expresión regular a partir de una cadena que controla el atacante: con Regexp.new, Regexp.union o Regexp.compile, o interpolando entrada dentro de un literal. Y la frase que cierra el tema, textual: "Las aplicaciones que solo usan expresiones regulares escritas por sus propios desarrolladores no están afectadas".
Lo valioso son las dos defensas que el post descarta de entrada, porque son las dos que uno probaría primero:
Regexp.timeoutno protege contra estos errores. No es un problema de tiempo de ejecución, así que el reloj no ayuda.- Limitar el largo del patrón no es confiable, porque algunos de estos defectos se disparan con patrones cortos.
Si no podés actualizar, la indicación es la única que queda: no compilar expresiones regulares a partir de entrada no confiable.
¿A quién afecta CVE-2026-97229?
Si tenés GitLab autoalojado, te toca, y el rango incluye las ramas 19.2, 19.3 y 19.4 por debajo de las versiones de arriba. Es el caso central.
Si tu instancia permite registro abierto o tiene proyectos públicos, estás peor, porque la falla se alcanza por una configuración de CI/CD y eso es contenido que puede llegar de afuera sin cuenta.
Si usás GitLab.com o GitLab Dedicated, no tenés acción: GitLab dice que ya corrían la versión parchada.
Si tenés otra aplicación en Ruby, mirá la regla de la sección anterior antes de mover nada. Probablemente no te toque.
Si tercerizás el GitLab, la pregunta útil es la versión exacta, no "¿están al día?", y conviene pedir las cuatro: si está en 19.4.2 falta la 19.4.3. El formato para pedirlo por escrito está en cómo responder un cuestionario de seguridad de un cliente.
Vale recordar que GitLab ya estuvo en este catálogo antes: tiene 6 entradas repartidas en 5 años, la primera de 2021 y marcada como usada en ransomware, y la anterior a esta fue en septiembre, cubierta en parchear GitLab no alcanza.
¿Quién puede ignorar el plazo del 1 de noviembre?
El plazo del 1 de noviembre —3 días desde el alta— obliga a las agencias federales civiles de Estados Unidos y no a una PyME de la región.
Lo que sí aplica, sin plazo, es que la versión correctora salió el 12 de octubre, hace 18 días, y que CISA considera esta falla explotada. La ficha del CVE se publicó el 13 de octubre y el alta en el catálogo llegó 16 días más tarde.
Quien no tenga GitLab autoalojado puede cerrar la página, con el asterisco de la regla de Ruby si desarrolla en ese lenguaje. Y quien ya esté en 19.4.3 o posterior está cubierto de las cuatro.
Lo que no corresponde concluir es que haya que apurar solo la 19.4.2. Si vas a abrir una ventana de mantenimiento, la versión que conviene apuntar es la que cierra la familia completa, no la que cierra la que tiene plazo.
¿Cómo sé en qué versión está mi GitLab?
Tres formas, de la más rápida a la más completa:
- En la interfaz, el panel de administración muestra la versión en la página principal, y avisa si hay una posterior disponible.
- Por URL,
/helpmuestra la versión de la instancia a cualquier usuario con sesión. - En el servidor,
gitlab-rake gitlab:env:infodevuelve la versión junto con la del Ruby que está usando, que en este caso importa por separado.
Para detectar intentos, GitLab publicó junto al parche seis reglas de detección de amenazas para instancias autoalojadas. No las reproduzco acá porque son del fabricante y conviene tomarlas de la fuente, pero vale saber que existen y que vienen en el mismo anuncio del parche. Lo que las hace útiles es que miran conducta y no firmas, que es la diferencia desarrollada en cuándo se justifica un EDR en una PyME.
¿Qué hago si tengo GitLab autoalojado en una versión afectada?
En este orden:
- Apuntá a 19.2.9, 19.3.6 o 19.4.3, no a la 19.4.2. Cierra la explotada y también la otra de 10,0 de la misma familia.
- Si no podés llegar a esa y el plazo te apura, la 19.4.2 cierra la catalogada y deja pendiente la 110264. Es una decisión válida mientras quede anotada, no olvidada.
- Revisá si tu instancia permite registro abierto, y si no lo necesitás, cerralo. Reduce quién puede llegar a una configuración de CI/CD.
- Mirá también la versión de Ruby que reporta
gitlab:env:info. GitLab empaqueta su propio Ruby, así que normalmente se resuelve con la actualización de GitLab, pero si tenés otras aplicaciones Ruby en la misma máquina, esas van por separado. - Usá las reglas de detección del anuncio del parche para revisar si hubo intentos antes de que actualizaras.
- Si encontrás indicios, tratá el servidor como comprometido. Un GitLab guarda código, credenciales de despliegue y tokens de CI/CD: lo que se pierde ahí no es solo el servidor. El encuadre general está en la guía de ciberseguridad para PyMEs de LATAM.
Una aclaración sobre las fuentes. Lo que sí pude leer: el anuncio del parche crítico de GitLab 19.4.2, 19.3.5 y 19.2.8, del 12 de octubre de 2026, de donde salen el rango afectado, las versiones correctoras, el puntaje 10,0 con su vector, el dato de que GitLab.com ya estaba parchada, la existencia de las seis reglas de detección y el crédito del reporte; el post de Ruby del 23 de octubre que mapea las cuatro CVE contra los defectos de Onigmo, de donde salen el mapeo, los números de cambio, las versiones de Ruby, la excepción de la rama 3.3, la regla de exposición y las dos defensas que descarta; las fichas de la API de NVD de las cuatro CVE, de donde salen los puntajes, los estados y los rangos; y el feed JSON del catálogo KEV. Un detalle del camino: la nota del catálogo enlaza el post de Ruby con una dirección que devuelve 404; la correcta termina en regexp-fixes-for-gitlab-cves. Lo que no enlazo: los dos informes de HackerOne que referencia la ficha de NVD, porque son reportes de recompensa y pueden traer detalle de explotación. Lo que no describo: qué forma tiene la expresión regular que dispara el defecto.
La otra alta del catálogo de ayer fue CVE-2026-76418, en el servicio de VPN SSL de acceso remoto de Cisco Secure Firewall ASA y FTD: un atacante remoto sin autenticar puede hacer que el equipo se reinicie, con denegación de servicio, y según Cisco la condición es que haya autenticación secundaria configurada en un grupo de túnel. Puntúa 8,6 y tiene el mismo plazo del 1 de noviembre. No la cubro acá para no mezclar dos historias.
Preguntas frecuentes sobre CVE-2026-97229 en GitLab
¿Alcanza con actualizar a 19.4.2?
Cierra la falla que CISA catalogó como explotada, pero no la familia. CVE-2026-110264, del mismo grupo de defectos de Onigmo y también con CVSS 10,0, pide 19.2.9, 19.3.6 o 19.4.3. Si vas a abrir una ventana de mantenimiento, conviene apuntar a esas versiones y resolver las dos de una vez. Si el plazo te obliga a ir a la 19.4.2 primero, que quede anotado que falta un paso.
Uso GitLab.com. ¿Tengo que hacer algo?
No. El anuncio del parche dice que GitLab.com ya corría la versión parchada y que la infraestructura administrada por GitLab, incluida GitLab Dedicated, sigue parchada. Esta es una falla que le toca a quien corre su propia instancia.
Tengo una aplicación en Ruby que no es GitLab. ¿Me afecta?
Solo si compilás expresiones regulares a partir de texto que controla un atacante: con Regexp.new, Regexp.union o Regexp.compile, o interpolando entrada dentro de un literal. Ruby lo dice textual: "Las aplicaciones que solo usan expresiones regulares escritas por sus propios desarrolladores no están afectadas". Si estás en el primer caso, pasá a Ruby 4.0.9, 3.4.12 o 3.3.13, y tené en cuenta que Regexp.timeout no protege contra estos errores y que limitar el largo del patrón tampoco es confiable.
¿Por qué la de 10,0 se explotó y las de 9,9 no?
Por la única diferencia real entre ellas: la cuenta. Las dos de septiembre, de 9,9, podían ser alcanzadas por un usuario autenticado, según las descripciones de GitLab. La de 10,0 dice "usuario no autenticado", y su vector lo confirma con PR:N. En una instancia con registro abierto o con proyectos públicos, no necesitar cuenta es lo que convierte un defecto en algo usable a escala. La décima de diferencia en el puntaje esconde ese cambio de naturaleza.
Si el defecto es de Ruby, ¿por qué no hay un CVE de Ruby?
Porque Ruby decidió no pedirlos. El post dice textualmente que "no hemos solicitado identificadores CVE en Ruby para estas correcciones, al menos por ahora", y que van a discutir si hacerlo. No hay nada irregular en eso: emitir un CVE es una decisión de quien lo emite, y Ruby publicó y documentó los arreglos. Pero tiene una consecuencia práctica: si tu inventario busca CVE de Ruby, no va a encontrar estos, porque la señal está en las CVE de GitLab y en el post de Ruby.