GitLab: CVE-2026-19478 explotada activamente pocos días después de su divulgación

La vulnerabilidad CVE-2026-19478 de GitLab se ha observado en ataques reales pocos días después de su divulgación pública. La detección se produjo el 21 de agosto de 2026 y corresponde a watchTowr, que identificó intentos contra su propia red de honeypots.

La empresa afirmó haber reproducido el problema pocos minutos después de su divulgación. El fallo permite que un atacante remoto no autenticado actúe sobre proyectos de GitLab accesibles públicamente, sin credenciales ni interacción de los usuarios.

Inyección de código a través de GraphQL

La vulnerabilidad afecta a una directiva de GraphQL y se clasifica como code injection, con referencia a CWE-94. En determinadas condiciones, una solicitud especialmente diseñada puede permitir modificar o eliminar proyectos y datos asociados.

La descripción publicada por NVD confirma que el ataque puede ejecutarse de forma remota contra proyectos públicos y datos de los usuarios. No se requieren privilegios previos y la complejidad del ataque se considera baja.

La puntuación CVSS v3 es de 9.4:

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

La confidencialidad presenta un impacto bajo, pero la integridad y la disponibilidad pueden verse gravemente comprometidas. En la práctica, el atacante podría alterar contenidos y configuraciones, o dejar indisponibles componentes esenciales de los proyectos.

Repositorios eliminados y merges falsificados

Según watchTowr, las consecuencias no se limitan a la modificación de datos aislados. Una explotación exitosa puede incluir:

• eliminación de repositorios completos;
• alteración de los datos de los proyectos;
• falsificación de registros de merge;
• expulsión o bloqueo de maintainers;
• aparente integración de una corrección que nunca se aplicó realmente.

La falsificación de los registros de merge es especialmente delicada, ya que puede comprometer la confianza en los procesos de desarrollo. Un proyecto podría mostrar un cambio como ya integrado, aunque el código corregido no se haya aplicado ni verificado de forma efectiva.

El problema afecta principalmente a las instancias expuestas a Internet con repositorios públicos y funcionalidades de GraphQL accesibles desde el exterior. No se ha identificado a ningún grupo criminal como responsable de los ataques observados.

Versiones de GitLab afectadas

Son vulnerables tanto GitLab Community Edition (CE) como Enterprise Edition (EE).

Las versiones afectadas son:

• rama 18.2, en versiones anteriores a 18.11.11;
• rama 19.0, en versiones anteriores a 19.0.8;
• rama 19.1, en versiones anteriores a 19.1.6;
• rama 19.2, en versiones anteriores a 19.2.4.

GitLab corrigió el fallo en las versiones:

• 18.11.11;
• 19.0.8;
• 19.1.6;
• 19.2.4.

Los administradores deben comprobar la rama utilizada y aplicar la versión correspondiente, sin limitarse a revisar únicamente el número principal de la versión. Una instancia actualizada a una versión anterior a la corrección sigue estando expuesta.

La rapidez de la explotación reduce el margen operativo

La secuencia observada por watchTowr muestra un intervalo muy breve entre la divulgación y la actividad de explotación. Jake Knott, principal security researcher de la empresa, relacionó esta rapidez con el uso de herramientas y procesos habilitados por la inteligencia artificial.

Se trata de una observación sobre la aceleración de las actividades ofensivas, no de una atribución a un actor concreto. Sin embargo, la conclusión operativa es clara: tras la publicación de los detalles técnicos, el tiempo disponible para actualizar los sistemas puede ser muy limitado.

Según la información disponible, la vulnerabilidad no figura en el catálogo CISA KEV. Por tanto, no existe una fecha límite asociada de CISA. No obstante, su ausencia del catálogo no reduce la prioridad de la intervención: watchTowr observó directamente explotación in-the-wild.

Actualizar GitLab y revisar los registros

La medida principal consiste en actualizar las instancias CE o EE a las versiones corregidas: 18.11.11, 19.0.8, 19.1.6 o 19.2.4, según la rama instalada.

Si no es posible actualizar de inmediato, GitLab recomienda aplicar una de las siguientes mitigaciones:

• limitar el acceso no autenticado al endpoint /api/graphql;
• eliminar por completo el acceso a los repositorios públicos.

Estas medidas reducen la superficie expuesta, pero no sustituyen la corrección del software. Después de actualizar, conviene comprobar que las restricciones temporales solo se hayan retirado cuando el riesgo haya quedado realmente controlado.

Las organizaciones que aún no hayan aplicado los parches deberían examinar los registros web en busca de solicitudes que contengan:

@gl_introduced

La revisión también debe incluir indicadores de escaneo, probing e intentos de explotación. Es necesario contrastar los cambios recientes en repositorios, datos de proyectos, registros de merge y permisos de los maintainers.

Las alteraciones no autorizadas, los repositorios desaparecidos, los maintainers eliminados o los merges inesperados requieren revisar las cuentas implicadas, los registros de la aplicación y las copias de seguridad. Ante cambios sospechosos, no basta con restaurar el repositorio: también deben comprobarse los metadatos, las autorizaciones y el historial de operaciones.