En GitLab Community Edition y Enterprise Edition se ha descubierto la vulnerabilidad crítica CVE-2026-19478 con una puntuación CVSS 9.4, que permite a un atacante no autenticado modificar y eliminar proyectos de GitLab de acceso público sin necesidad de credenciales ni interacción del usuario. Los parches ya se han publicado, y las organizaciones con instancias de GitLab autoalojadas y accesibles desde Internet deben actualizar de inmediato. La empresa watchTowr informa de indicios de explotación de la vulnerabilidad, aunque estos datos aún no han sido confirmados por fuentes independientes.
Detalles técnicos de la vulnerabilidad
CVE-2026-19478 se clasifica como una vulnerabilidad de code injection. Según se informa, la explotación es posible a través de una directiva GraphQL, un mecanismo que utiliza GitLab para procesar solicitudes API. El peligro clave radica en que para el ataque no se requiere autenticación ni una configuración específica de la instancia objetivo.
Versiones afectadas de GitLab CE y EE:
- 18.2 — hasta 18.11.11
- 19.0 — hasta 19.0.8
- 19.1 — hasta 19.1.6
- 19.2 — hasta 19.2.4
Las correcciones están disponibles en las versiones 18.11.11, 19.0.8, 19.1.6 y 19.2.4.
Según los investigadores de watchTowr, las consecuencias de la explotación van más allá de la simple modificación de proyectos públicos. De acuerdo con su publicación, un atacante podría, en teoría:
- Eliminar repositorios completos
- Falsificar registros de merges (merge records), creando la apariencia de correcciones aplicadas que en realidad no existen
- Bloquear a los mantenedores de los proyectos
Es importante tener en cuenta que estos escenarios ampliados de impacto se basan en los datos de una única fuente de investigación y aún no han sido confirmados por el boletín oficial de GitLab ni por otras organizaciones independientes.
Estado de explotación
La empresa watchTowr declaró que pudo reproducir la vulnerabilidad en cuestión de minutos tras su divulgación pública y detectó indicios de explotación en su red de trampas (honeypot). Sin embargo, en el momento de la publicación la vulnerabilidad no figura en el catálogo CISA KEV, y las afirmaciones sobre explotación activa no han sido confirmadas ni por el proveedor ni por otras fuentes de referencia. El estado de explotación debe considerarse como no confirmado: esto no reduce la criticidad de la vulnerabilidad en sí, pero influye en la evaluación de la amenaza inmediata.
El investigador de watchTowr Jake Knott relacionó la rapidez con la que se pasó de la divulgación a la explotación con el uso de herramientas de inteligencia artificial por parte de los atacantes, lo que, en su opinión, reduce la ventana temporal de respuesta. Independientemente de que se confirme o no el papel de la IA en este caso concreto, la tendencia a acortar el tiempo entre la divulgación y los primeros ataques es una realidad objetiva de los últimos años.
Evaluación del impacto
Las organizaciones más expuestas al riesgo son aquellas que utilizan instancias de GitLab autoalojadas con acceso desde Internet y repositorios públicos. Teniendo en cuenta que GitLab se utiliza ampliamente para almacenar código fuente, gestionar pipelines CI/CD y coordinar el desarrollo, la compromisión de los repositorios puede conducir a:
- La introducción de código malicioso en la cadena de suministro de software
- La pérdida irreversible de datos en caso de eliminación de repositorios
- La pérdida de confianza en el historial de cambios mediante registros de merges falsificados
- La interrupción de los flujos de trabajo cuando se bloquea a los mantenedores
El escenario de falsificación de registros de merges es especialmente peligroso: en teoría, un atacante podría crear la apariencia de que una vulnerabilidad en el proyecto ya ha sido corregida, mientras que el código malicioso permanece en su lugar.
Recomendaciones para la respuesta
La prioridad es actualizar de inmediato a una de las versiones corregidas: 18.11.11, 19.0.8, 19.1.6 o 19.2.4.
Si no es posible actualizar de inmediato, se recomiendan las siguientes medidas temporales:
- Restringir el acceso no autenticado al endpoint
/api/graphqla nivel del servidor web o del proxy inverso - Deshabilitar por completo el acceso público a los repositorios hasta aplicar el parche
- Analizar los registros del servidor web en busca de solicitudes que contengan la cadena
@gl_introduced; según los investigadores, esto puede indicar intentos de explotación o de reconocimiento
Las organizaciones que detecten solicitudes sospechosas hacia el GraphQL API deben realizar una auditoría de integridad de los repositorios afectados: comprobar el historial de commits, los registros de merges y el estado de las cuentas de los mantenedores.
Teniendo en cuenta la puntuación CVSS 9.4 y el hecho de que la explotación no requiere autenticación, la actualización de las instancias de GitLab autoalojadas a las versiones 18.11.11, 19.0.8, 19.1.6 o 19.2.4 debe realizarse fuera del ciclo habitual de parches, en cuestión de horas y no de días. Las organizaciones que no puedan actualizar de inmediato deberían, como mínimo, cerrar el acceso no autenticado a /api/graphql y revisar los registros en busca de indicadores de reconocimiento.
