GitLab parchea una falla CVSS 10.0 en su motor de regex

GitLab lanzó un parche crítico con 12 vulnerabilidades

Doce vulnerabilidades, una de ellas con CVSS 10.0 —el puntaje máximo de la escala—, quedaron corregidas en el parche que GitLab publicó el 21 de octubre de 2026 para sus ediciones Community (CE) y Enterprise (EE). Para un founder que corre una instancia self-managed, la lectura es directa: la falla más grave permite que un atacante sin autenticarse ejecute código arbitrario en el servidor donde viven tu código fuente, tus pipelines de CI/CD y tus credenciales de deploy.

El parche llega en las versiones 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13, y GitLab recomienda que todas las instalaciones self-managed se actualicen de inmediato. Si usas GitLab.com, no tienes nada que hacer: ya corre la versión parchada. Los tenants de GitLab Dedicated en 19.3.5-internal0 y 19.4.2-internal0 o posteriores también incluyen los arreglos.

¿Qué permite CVE-2026-110264, la falla de CVSS 10.0?

Es un desbordamiento de entero (integer overflow) en el compilador de expresiones regulares de GitLab. Con una expresión regular especialmente construida dentro de la configuración de CI/CD, un usuario no autenticado podía conseguir ejecución de código arbitrario en el servidor, según el aviso oficial de la compañía.

El vector de CVSS —CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H— describe el peor escenario posible: explotable de forma remota, con complejidad baja, sin privilegios, sin interacción del usuario, cruzando límites de seguridad y con impacto alto en confidencialidad, integridad y disponibilidad.

El rango de versiones afectadas es enorme: todo desde la 7.0 anterior a 18.11.13, las 19.0 antes de 19.0.10, 19.1 antes de 19.1.9, 19.2 antes de 19.2.9, 19.3 antes de 19.3.6, 19.4 antes de 19.4.3 y 19.5 antes de 19.5.1. GitLab incluso hizo backport del arreglo hasta la rama 18.11, algo poco habitual y una señal clara de la gravedad.

La vulnerabilidad la reportó el investigador joaxcar a través del programa de bug bounty en HackerOne. Además, GitLab liberó dos detecciones de amenaza para que las instancias self-managed puedan revisar si hubo intentos de explotación.

Las otras 11 vulnerabilidades del parche

No todo es la CVSS 10.0. El release incluye once fallas más, ordenadas aquí por severidad:

• CVE-2026-15723 (CVSS 8.2) — Con OmniAuth SAML y el auto-linking de LDAP activados a la vez, un usuario autenticado podía tomar el control de una cuenta respaldada por LDAP sin ninguna interacción de la víctima.
• CVE-2026-112212 (CVSS 7.5) — Envenenamiento de caché en los endpoints de descubrimiento OAuth/OIDC: un usuario no autenticado podía redirigir ciertos flujos a un servidor bajo su control.
• CVE-2026-12664 (CVSS 6.8) — Un token con alcance read_api permitía leer la dirección de email entrante de un proyecto y crear work items saltándose las restricciones del token.
• CVE-2026-16255 (CVSS 5.9) — Con el bloqueo de membresía SAML/LDAP a nivel de instancia activado, un usuario autenticado podía conceder o aceptar membresías fuera del control del proveedor de identidad. Solo afecta a GitLab EE.
• CVE-2026-105777 (CVSS 4.3) — Exposición de credenciales internas del servidor por un filtrado insuficiente de los headers de respuesta.
• CVE-2026-13319 (CVSS 4.3) — Falta de control de autorización en la API de milestones de grupo: se podían leer títulos, descripciones y rutas completas de proyectos privados ajenos sin pertenecer a ellos.
• CVE-2026-112378 (CVSS 4.3) — Validación insuficiente del lado del servidor en la elegibilidad de facturación de las funciones de IA: un usuario autenticado podía acceder a features de pago sin suscripción válida. Solo EE.
• CVE-2026-105711 (CVSS 3.5) — Una clave de caché compartida entre usuarios dejaba leer el título de un issue confidencial desde un merge request de un proyecto público.
• CVE-2026-14288 (CVSS 3.1) — Bypass de una política de aprobación obligatoria en una rama protegida durante la sincronización de reglas de aprobación. Solo EE.
• CVE-2026-112326 (CVSS 3.1) — Un usuario con permisos de solo lectura podía borrar de forma permanente registros de vulnerabilidades existentes. Solo EE.
• CVE-2026-103515 (CVSS 2.7) — Un Owner de grupo podía reactivar la salida de datos hacia Amazon Q en un grupo bloqueado por el administrador. Solo EE.

¿Por qué el compilador de regex volvió a fallar en el mismo mes?

El mismo componente ya había dado dolores de cabeza días antes. Help Net Security reportó el 13 de octubre de 2026 que GitLab parcheó una falla de severidad máxima (CVE-2026-97229), también un integer overflow en el compilador de expresiones regulares del CI/CD y también con CVSS 10.0, en las versiones 19.4.2, 19.3.5 y 19.2.8 publicadas el 12 de octubre de 2026. El aviso nuevo usa otro identificador (CVE-2026-110264) y cubre ramas más antiguas; para un administrador la conclusión práctica es la misma: subir a la última versión disponible de su rama.

En ese reporte, Rapid7 reprodujo ejecución de código en una imagen oficial de GitLab CE 19.4.1 sin parchear, y el mismo input no funcionó contra la 19.4.2, según Help Net Security. Los investigadores matizaron la explotación: el atacante debía poder hacer commit de un archivo .gitlab-ci.yml malicioso en un proyecto público y usar una ruta de repositorio con caracteres UTF-8. En instancias self-managed que permiten crear proyectos públicos, una cuenta común alcanza para cumplir ese requisito. Hasta ese momento no había explotación confirmada en el mundo real.

El historial del sector no invita a la calma. BleepingComputer recuerda que CISA marcó cinco fallas de GitLab como explotadas en ataques desde noviembre de 2021, una de ellas usada por bandas de ransomware. The Hacker News reportó que otro fallo de severidad máxima (CVE-2026-85706, CVSS 10.0) registró sondeos en el mundo real horas después de su divulgación pública. Y según BleepingComputer, GitLab afirma tener más de 30 millones de usuarios registrados y que más del 50% de las empresas Fortune 100 usan su plataforma, incluidas Nvidia, T-Mobile, Lockheed Martin, Airbus y Goldman Sachs. Ese perfil de instalaciones es lo que convierte una CVSS 10.0 en una urgencia de fin de semana.

¿Qué significa esto para tu startup?

En equipos chicos, una instancia self-managed de GitLab suele ser un VPS o un contenedor que nadie mira demasiado, con los secretos de producción en variables de entorno del CI/CD y tokens de deploy con permisos sobre tu nube y tus registros de contenedores. En ese contexto, una ejecución remota de código no es un bug más: es acceso al pipeline, y el pipeline tiene las llaves de todo lo demás.

Hay un segundo ángulo, menos técnico y más comercial. Si vendes a clientes enterprise o estás levantando capital, los cuestionarios de seguridad y las due diligence de SOC 2 o ISO 27001 van a preguntar cómo gestionas parches críticos. Una falla de severidad máxima sin aplicar, con más de una semana de antigüedad, tiene una respuesta incómoda.

Acciones concretas para esta semana

• Verifica tu versión exacta y qué parche te corresponde. No asumas que estás al día solo porque el pipeline funciona.
• Planifica la ventana de actualización. Las versiones 19.3.6 y 19.4.3 incluyen migraciones regulares, y 19.4.3 además tiene migraciones post-deploy. En una instalación single-node esto implica downtime, porque las migraciones deben completarse antes de que GitLab arranque; en multi-node, con un procedimiento de zero-downtime, se puede aplicar sin caída.
• Rota credenciales si no puedes descartar exposición: tokens de CI/CD, deploy keys, variables protegidas y credenciales de runners son el primer lugar donde buscar si alguien llegó a ejecutar código.
• Usa las dos detecciones de amenaza que GitLab publicó para instancias self-managed y revisa tus logs.
• Si estás en una rama vieja, el backport llega hasta la 18.11.13: quedarse atrás ya no es una opción razonable.

El detalle que suele pasar desatendido: los 90 días

GitLab publica los detalles técnicos de cada vulnerabilidad en su issue tracker 90 días después del release que las corrigió. Eso significa que durante tres meses el exploit completo no es público, pero también que un administrador que espere el detalle técnico para decidir ya llegó tarde. Los parches programados salen dos veces al mes, el segundo y cuarto miércoles; este fue un parche crítico ad-hoc, fuera de ese calendario, precisamente por la severidad.

En las notas del release también hay un cambio práctico para equipos con artefactos grandes: el timeout de subida en staging y producción sube de 35 a 60 minutos.

La lección para un founder no es sobre GitLab en particular. Es que la infraestructura propia de desarrollo —el servidor donde vive tu código— concentra los secretos más valiosos de la empresa y suele ser la que menos atención operativa recibe. Un calendario fijo de parches, con responsable asignado y ventana reservada, cuesta mucho menos que una brecha.

Fuentes

• 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
• GitLab admins urged to patch critical RCE flaw (CVE-2026-97229)
• GitLab Patches CVSS 10.0 Flaw That Could Let Unauthenticated Users Run Server Code
• GitLab patches a max-severity regex flaw alongside five high-severity bugs
• GitLab warns of max severity code execution vulnerability