Un fichero .org basta para ejecutar código en GitLab desde 2014

Todas las versiones de GitLab publicadas desde 2014 comparten un fallo crítico de ejecución remota de código. El fabricante lo corrigió el 21 de octubre de 2026 con CVE-2026-110264, puntuación CVSS 10,0 y origen en el motor de expresiones regulares Onigmo, y solo afecta a quien se autoaloja GitLab Community Edition o Enterprise Edition. Según GitLab, puede alcanzarse sin autenticación.

Es la segunda vez en nueve días que GitLab corrige un fallo CVSS 10 en el mismo componente. Este blog cubrió el anterior, CVE-2026-97229 en el compilador de regex de CI/CD, el 13 de octubre. Quien instaló aquellas versiones (19.4.2, 19.3.5 y 19.2.8) vuelve a quedar dentro del rango vulnerable y tiene que actualizar de nuevo.

Qué cambia respecto al parche del 12 de octubre

El aviso de GitLab describe el problema como un desbordamiento de entero al compilar una expresión regular manipulada que «could have allowed an unauthenticated user to execute arbitrary code on the GitLab server» (podría haber permitido a un usuario sin autenticar ejecutar código arbitrario en el servidor de GitLab). Agradece el hallazgo al investigador que firma como joaxcar en el programa de recompensas de HackerOne, el mismo que reportó el fallo del 12 de octubre y otros dos del 23 de septiembre en ese motor.

La diferencia con aquel parche es el alcance. El del 12 de octubre llegaba a las ramas 19.2 y posteriores. Este retrocede hasta la 7.0, porque el motor Onigmo acompaña a GitLab desde entonces. Por eso GitLab ha tenido que publicar correcciones para siete ramas distintas y retroportar el arreglo a versiones que ya estaban fuera de su ventana de soporte habitual, algo que el fabricante reserva para fallos de la máxima gravedad.

Hay un matiz que conviene no pasar por alto: un servidor actualizado al parche anterior no está cubierto. Las versiones 19.4.2, 19.3.5 y 19.2.8 corrigen CVE-2026-97229 pero quedan por debajo de las nuevas versiones corregidas, así que siguen expuestas a CVE-2026-110264. La firma Aikido Security lo resumió en X el 21 de octubre con dos pasos: poner el servidor tras un firewall y parchear. En el parche del 21 de octubre, el desbordamiento del compilador de expresiones regulares encabeza la lista de doce correcciones de seguridad, como muestra la tabla del aviso.

El motor Onigmo y la vía del renderizador de ficheros .org

La ficha técnica recoge los datos del CNA de GitLab, porque NVD mantenía el 22 de octubre el CVE en estado «Awaiting Analysis» y no había publicado todavía su propia puntuación.

El aviso del fabricante no explica por dónde se alcanza el motor. Lo detallan las dos notas de detección que GitLab publicó el 20 de octubre en su repositorio TLDR y un análisis técnico de Rapid7 sobre el fallo hermano. La causa raíz está en cómo Onigmo guarda los identificadores de repetición de un patrón: usa un operando de 16 bits con signo pero los cuenta como entero, de modo que un patrón con más de 32.767 repeticiones hace que ese identificador se vuelva negativo y, en tiempo de coincidencia, escriba fuera de su búfer. El commit que lo arregla lo explica sin rodeos.

La vía de entrada que da la puntuación de 10,0 es el renderizador de ficheros con extensión .org. GitLab procesa esos ficheros con la gema org-ruby, que construye una expresión regular a partir de una línea de encabezado del documento sin escapar su contenido. Como un fichero .org de un proyecto público se renderiza al abrirlo en el navegador, un visitante sin cuenta puede hacer que el servidor procese ese contenido. La propia nota de GitLab avisa de una segunda ruta: la vista previa del editor elige el renderizador por la extensión que indique el parámetro, así que un valor terminado en .org fuerza el renderizador de Org aunque el fichero editado sea otro.

GitLab clasifica el fallo de dos maneras a la vez. El registro CVE lo etiqueta como desbordamiento de entero (CWE-190), mientras que sus notas de detección lo describen como escritura fuera de límites (CWE-787) y control indebido de la generación de código (CWE-94). Ninguna fuente pública ha publicado un exploit funcional confirmado para esta vía a 22 de octubre, aunque sí existe una prueba de concepto de Rapid7 para el fallo previo de CI/CD.

El arreglo llega por debajo, en el intérprete de Ruby que GitLab empaqueta, no en el código de la plataforma. El 14 de octubre, el commit «Add Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0» de omnibus-gitlab retroportó a tres ramas de Ruby el parche original de Onigmo, aceptado en la rama principal de Ruby el 29 de abril de 2026. A partir del arreglo, el compilador rechaza esos patrones con un error en lugar de desbordar. Como el fallo vive en una dependencia que GitLab arrastra desde hace años y el arreglo solo existía en la rama de desarrollo de Ruby, hubo que llevarlo a mano a las versiones que GitLab todavía usa. La consecuencia práctica para quien administra su instancia es simple: no hay configuración que mitigue el fallo, solo el parche, y GitLab no ha ofrecido ninguna solución temporal. El mensaje del commit resume el mecanismo y por qué el arreglo tuvo que aplicarse a mano en tres ramas de Ruby.

Quién está expuesto y qué dicen las cifras

El fallo afecta solo a quien se autoaloja GitLab. GitLab.com ya ejecuta la versión corregida y los clientes de GitLab Dedicated en 19.3.5-internal0, 19.4.2-internal0 o posteriores tampoco tienen que actuar. GitLab declara más de 30 millones de usuarios registrados y presencia en más de la mitad de las empresas del Fortune 100, así que el parque autoalojado es grande.

Shadowserver rastreaba el 22 de octubre más de 2.700 instancias de GitLab CE expuestas a Internet, según BleepingComputer. El recuento no distingue cuántas son señuelos ni cuántas ya están parcheadas, y en su mapa por países Estados Unidos encabeza la lista con 1.702. Ninguna fuente ofrece un recuento específico de España en el momento de escribir esta noticia.

El ángulo español lo aporta INCIBE-CERT, que calificó el fallo de importancia crítica el 22 de octubre, y CERT-EU, que ese mismo día pidió actualizar los activos expuestos a Internet cuanto antes y ejecutar una revisión en busca de sistemas comprometidos. Para localizar las instancias en la propia red, la consola de runZero inventaría los servidores GitLab con una consulta sobre el producto y sus rangos de versión.

Cómo detectar intentos contra el renderizador

Como el fallo es tan difícil de rastrear a ojo, las dos reglas de GitLab son el mejor punto de partida. Están escritas en formato Sigma contra los registros de la propia aplicación y cubren dos señales distintas: una ráfaga de errores al renderizar ficheros .org y una caída nativa del proceso.

La primera cuenta las ráfagas de tiempos de espera al renderizar ficheros .org en el registro de excepciones. Según la nota de GitLab, cinco o más desde un mismo cliente en treinta minutos apuntan a una campaña de renderizado. Para una instancia sin SIEM, GitLab propone este filtro directo sobre los registros:

EXC=/var/log/gitlab/gitlab-rails/exceptions_json.log
# Tiempos de espera al renderizar .org, agrupados por cliente
grep '"exception.class":"Timeout::Error"' "$EXC"* \
  | grep '"extra.class_name":"OtherMarkup"' \
  | grep -E '"extra.file_name":"[^"]*\.org"' \
  | grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn

La segunda busca caídas nativas del proceso cuyo rastreo pasa por la gema org-ruby o por el motor Onigmo. GitLab advierte de que es una señal corroborante, no concluyente: un intento con éxito suele ser silencioso y no provoca una caída fiable, así que su ausencia nunca descarta un ataque. Para esa pista, GitLab revisa el registro de error del trabajador:

PUMA=/var/log/gitlab/puma/puma_stderr.log
# Caídas [BUG] cuyo rastreo cita org-ruby o el motor Onigmo
grep -B1 -A20 '\[BUG\]' "$PUMA"* \
  | grep -E 'org-ruby|headline\.rb|regexp_matcher\.rb|onig_compile|compile_tree|match_at'

Si aparece una coincidencia, GitLab recomienda tratarla como un intento de ejecución remota: identificar el proyecto y el fichero .org señalado en extra.file_name, conservar el informe de la caída y los registros, y revisar procesos hijos inesperados de los servicios de GitLab, ficheros nuevos del usuario git en rutas temporales y conexiones salientes anómalas. Quien centralice estos registros puede apoyarse en nuestras notas sobre las reglas Sigma y sobre la gestión de logs en ciberseguridad.

Qué hacer si administras GitLab autoalojado

1. Comprueba la versión de cada instancia y actualiza a la 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13, según tu rama, o a una posterior. Si instalaste el parche del 12 de octubre, sigues expuesto: actualiza igual.
2. Planifica la ventana de mantenimiento. Las versiones 19.4.3 y 19.3.6 incluyen migraciones de base de datos, así que una instancia de un solo nodo tendrá parada hasta que terminen, mientras que una instalación multinodo puede actualizarse sin parada con los procedimientos de GitLab. Actualiza los GitLab Runner por separado.
3. Hasta que puedas aplicar el parche, reduce la visibilidad pública donde sea posible, porque la vía de entrada sin autenticar necesita un fichero .org que GitLab renderice en un proyecto público, y restringe el acceso al servidor por red, como recordó Aikido.
4. Activa las dos reglas de detección de GitLab y asegúrate de que tu canal de registros recoge exceptions_json.log y puma_stderr.log, que muchas instancias no envían por defecto.
5. Si encuentras indicios de ejecución, trata la instancia como comprometida: rota los secretos de gitlab-secrets.json, todas las variables de CI/CD, los tokens de los runner y los tokens de acceso. Una buena gestión de identidades y accesos en la nube limita el daño de cada secreto robado.
6. Notifica el incidente a INCIBE-CERT si eres empresa o ciudadano, o al CCN-CERT si perteneces al sector público.

Lo que este segundo parche deja sobre la mesa

Dos fallos CVSS 10 en el mismo motor en nueve días, los dos del mismo investigador, dibujan un patrón. El de octubre es el cuarto fallo de ejecución de código que joaxcar reporta en el tratamiento de expresiones regulares de GitLab en poco más de un mes, y el primero que cruza la frontera de la autenticación y alcanza versiones anteriores a la 19.2. Cuando alguien encuentra una veta así, lo esperable es que sigan saliendo piezas, y conviene parchear sin esperar a la siguiente.

Lo que no dice el aviso oficial es hasta qué punto la vía sin autenticar depende de que la instancia tenga proyectos públicos. Una instalación interna, sin registro abierto y sin proyectos públicos, reduce mucho la superficie, pero no la elimina: la nota de GitLab describe también la vía de la vista previa del editor, que necesita una cuenta pero sigue llegando al mismo motor. Nuestra lectura es que ninguna instancia con repositorios o CI/CD debería quedarse sin parchear mientras se mide ese matiz, sobre todo cuando GitLab concentra el código, las variables y los tokens con los que una organización despliega su software.

La semana encadena ejemplos de plataformas de desarrollo y acceso que se corrigen a contrarreloj, desde el parche de emergencia de PHP por los fallos PHP2Shell hasta el fallo crítico de Drupal explotable sin autenticación. GitLab no es un equipo de borde, pero hospeda las llaves del software que se despliega después, y esa es la razón para tratar su parche con la misma urgencia que la de un firewall expuesto.