GitLab corrige una vulnerabilidad crítica de GraphQL que puede modificar o eliminar proyectos

Una vulnerabilidad crítica en las instancias self-managed

GitLab publicó el 17 de agosto de 2026 una actualización de seguridad extraordinaria, cinco días después de la anterior versión ordinaria. El paquete corrige dos vulnerabilidades en las ediciones Community Edition (CE) y Enterprise Edition (EE), con distinto impacto, pero ambas relacionadas con el uso de GraphQL.

La más grave es CVE-2026-19478, clasificada por GitLab como Critical y con una puntuación CVSS 9.4. En determinadas condiciones, un atacante remoto no autenticado podría modificar o eliminar proyectos públicos y datos de usuarios mediante una directiva de GraphQL.

La empresa no ha revelado qué directiva está implicada ni qué condiciones deben cumplirse para que el ataque tenga éxito. Sin embargo, el vector CVSS indica que el ataque puede ejecutarse a través de la red, sin credenciales y sin interacción de la víctima:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

La puntuación refleja sobre todo el impacto en la integridad y la disponibilidad de los datos. El componente de confidencialidad, en cambio, se considera más limitado.

A 18 de agosto de 2026, GitLab no había informado de explotación de la vulnerabilidad. Tampoco constaba código de exploit público en GitHub asociado a CVE-2026-19478. Se desconoce si la vulnerabilidad ha sido incluida en el catálogo Known Exploited Vulnerabilities (KEV) de CISA.

El segundo problema afecta a las mutation de GraphQL mediante GET

El segundo fallo es CVE-2026-19650, clasificado como High y con una puntuación CVSS 7.1:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

La vulnerabilidad consiste en una debilidad de tipo Cross-Site Request Forgery (CSRF) en el gestor de consultas GraphQL multiplex. En determinadas condiciones, una validación insuficiente de las solicitudes podría haber permitido a un usuario no autenticado ejecutar operaciones de modificación, denominadas mutation, mediante solicitudes HTTP GET.

A diferencia del fallo crítico, este escenario requiere interacción del usuario. La víctima tendría que realizar una acción que permitiera procesar en la instancia de GitLab la solicitud preparada por el atacante.

El problema no equivale automáticamente a un acceso completo al servidor. Sin embargo, el riesgo consiste en la ejecución no autorizada de operaciones que modifican datos, con posibles consecuencias para proyectos, configuraciones y recursos gestionados por la plataforma. GitLab no ha publicado detalles suficientes para reconstruir con precisión el flujo del ataque.

Versiones vulnerables y corregidas

Las correcciones se han publicado en las versiones:

• 19.2.4
• 19.1.6
• 19.0.8
• 18.11.11

Son vulnerables:

• todas las versiones 18.2 anteriores a la 18.11.11;
• las versiones 19.0 anteriores a la 19.0.8;
• las versiones 19.1 anteriores a la 19.1.6;
• las versiones 19.2 anteriores a la 19.2.4.

Los operadores que utilizan las ramas de la 18.2 a la 18.10 no recibirán una corrección para esas ramas y deben planificar la actualización a una versión compatible y corregida. Las versiones exactas instaladas pueden comprobarse desde la página de administración de la instancia o mediante las herramientas de gestión del paquete utilizado.

La actualización afecta exclusivamente a las instalaciones self-managed. GitLab.com y GitLab Dedicated ya utilizan versiones corregidas; por tanto, sus clientes no deben aplicar actualizaciones manuales.

La actualización no introduce nuevas migraciones y, en instalaciones multinodo, no debería requerir un periodo de indisponibilidad. No obstante, siguen siendo necesarias las comprobaciones operativas habituales, especialmente en entornos con nodos distribuidos, proxies o componentes GraphQL expuestos mediante infraestructuras personalizadas.

Qué deben hacer los administradores

La mitigación indicada por GitLab consiste en actualizar a una de las cuatro versiones corregidas. No se han comunicado medidas alternativas equivalentes, como desactivar temporalmente una directiva específica de GraphQL o aplicar una regla de WAF capaz de bloquear ambos problemas.

Por tanto, los administradores deberían:

1. comprobar la versión de la instancia self-managed;
2. actualizarla a 19.2.4, 19.1.6, 19.0.8 o 18.11.11;
3. revisar los logs de la aplicación y de acceso en busca de solicitudes GraphQL anómalas;
4. investigar cambios inesperados en proyectos públicos, repositorios, incidencias, configuraciones y datos de usuarios;
5. comprobar si existen solicitudes GET inusuales asociadas a operaciones GraphQL con efectos de modificación.

El brief no indica indicadores de compromiso específicos, nombres de campañas ni patrones de red observados. Por ello, los logs no permiten necesariamente distinguir un intento exitoso de una actividad legítima sin correlacionar URL, identidades, momentos y cambios realizados.

Las organizaciones que no puedan actualizar de inmediato deberían reducir la exposición de la instancia y limitar el acceso externo según sus necesidades operativas. Sin embargo, esta medida no sustituye al parche ni garantiza la protección si la instancia debe seguir siendo accesible desde redes no confiables.

Divulgación técnica prevista para los próximos meses

GitLab ha declarado que publicará los detalles de las vulnerabilidades en su issue tracker 90 días después del lanzamiento de la corrección. Para estos dos problemas, la divulgación técnica está prevista aproximadamente para mediados de noviembre de 2026.

El calendario no es del todo coherente con una comunicación anterior, fechada el 10 de junio de 2026, que indicaba un plazo de 30 días. Hasta que se publiquen los detalles, se desconocen la directiva de GraphQL implicada en el fallo crítico, todos los requisitos para explotarlo y los métodos con los que podría eludirse la validación de las solicitudes GET.

El incidente se produce después de un informe de julio de 2026 sobre otra vulnerabilidad de GitLab. En ese caso, los investigadores publicaron código de exploit funcional contra servidores self-managed. La empresa no respondió de inmediato a una solicitud de comentarios sobre esta nueva actualización.

Para los administradores, la prioridad no cambia: identificar las instancias incluidas en los intervalos vulnerables y actualizarlas rápidamente a una versión corregida, sin esperar a la futura publicación de los detalles técnicos.