GitLab corrige tres vulnerabilidades de denegación de servicio autenticadas — CVE-2026-1660, CVE-2025-3922 y CVE-2025-0186

El 22 de abril de 2026, GitLab publicó un parche de seguridad que cierra tres vectores de denegación de servicio presentes en GitLab CE y EE: CVE-2026-1660, CVE-2025-3922 y CVE-2025-0186. Las tres vulnerabilidades comparten clasificación CWE-770 — asignación de recursos sin límites ni throttling — y las tres tienen la misma firma de ataque: un usuario autenticado, sin privilegios elevados, puede agotar los recursos del servidor y dejar la plataforma inoperable para el resto de usuarios de la instancia.

Lo que distingue a este grupo de parches es que el mismo patrón se repite en tres áreas completamente distintas de GitLab: la importación de issues, la API GraphQL y el endpoint de discusiones. No estamos ante un bug puntual sino ante una debilidad estructural que se manifestó de forma independiente en varios componentes. Eso sugiere que la validación de recursos en las capas internas de la plataforma no estaba aplicada de forma sistemática.

El riesgo recae íntegramente sobre instalaciones autogestionadas. GitLab.com ya ejecutaba versiones corregidas antes de la divulgación pública. Si tu organización opera un GitLab propio — algo frecuente en empresas que manejan código propietario, trabajan en entornos regulados, o simplemente prefieren mantener el control de su infraestructura de desarrollo — y no has actualizado a 18.9.6, 18.10.4 o 18.11.1, tienes tres caminos abiertos para que alguien con credenciales válidas tumbe la plataforma entera.

El parche del 22 de abril y su contexto

GitLab publica sus correcciones de seguridad en lotes coordinados en lugar de publicar cada fix de forma individual. Esta práctica reduce el ruido para los equipos que gestionan las actualizaciones, pero también significa que un solo boletín puede contener múltiples vulnerabilidades que afectan distintas partes del sistema. El parche de abril de 2026 es un ejemplo claro: tres CVEs, tres endpoints distintos, todos corregidos simultáneamente.

El denominador común es CWE-770. Esta debilidad describe software que asigna recursos — memoria, hilos, conexiones a base de datos, tiempo de procesamiento — en respuesta a peticiones de usuarios sin aplicar límites efectivos. El problema se vuelve especialmente grave en aplicaciones autenticadas porque existe la tendencia natural a asumir que un usuario que ha hecho login no va a abusar del sistema.

El vector CVSS 3.1 es idéntico en las tres vulnerabilidades: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. Desglosado:

• Acceso por red (AV:N): explotable remotamente desde cualquier conexión.
• Complejidad baja (AC:L): no requiere condiciones especiales ni sincronización.
• Privilegios bajos (PR:L): basta con una cuenta autenticada estándar.
• Sin interacción de usuario (UI:N): el ataque se puede automatizar completamente.
• Impacto alto en disponibilidad (A:H): el servicio puede quedar completamente inoperable.

La puntuación Media de 6.5 refleja el requisito de autenticación. Sin ese requisito, las tres vulnerabilidades estarían en rango Alto. En la práctica, un DoS autenticado sigue siendo crítico en entornos multitenant, en organizaciones donde la creación de cuentas está abierta a todos los empleados, o en cualquier escenario donde una sola credencial comprometida pueda convertirse en arma.

CVE-2026-1660 — DoS a través de la importación de issues

CVE-2026-1660 afecta a la funcionalidad de importación de issues de GitLab. Cuando un usuario importa issues — una operación legítima usada habitualmente en migraciones de proyecto — el servidor procesa los datos entrantes sin aplicar restricciones adecuadas sobre los recursos que puede consumir esa operación. Un atacante autenticado puede diseñar peticiones de importación que fuercen una asignación de recursos sin límite, degradando o interrumpiendo la disponibilidad para todos los demás usuarios de la instancia.

La vulnerabilidad afecta a GitLab CE/EE desde la versión 12.3 hasta 18.9.5, las versiones 18.10.0 a 18.10.3, y la versión 18.11.0. El rango tan amplio de versiones afectadas — que se remonta a 12.3 — evidencia cuánto tiempo lleva esta superficie de ataque sin control en el código.

Cómo se ve el ataque en un entorno real

Un atacante con cuenta válida en GitLab crea un proyecto e inicia operaciones de importación masivas o mal formadas de forma repetida. Como el servidor no aplica throttling en la capa de procesamiento, cada petición consume CPU y memoria de forma desproporcionada respecto a lo que requeriría una migración legítima. El escenario más dañino en un entorno empresarial: una instancia de GitLab que aloja pipelines de CI/CD activos. El atacante sincroniza las peticiones de importación con los momentos de mayor carga. El resultado son fallos en cascada de las builds porque la API de GitLab deja de responder — no porque el código falle, sino porque el servicio está sin recursos.

La corrección está disponible en 18.9.6, 18.10.4 y 18.11.1. No existe un workaround de configuración que cierre esta vulnerabilidad por completo. Como medida temporal, restringir los permisos de importación de issues a roles de administrador reduce el número de cuentas que pueden explotarla.

CVE-2025-3922 — Agotamiento de recursos en la API GraphQL

CVE-2025-3922 reside en la capa GraphQL de GitLab. GraphQL es especialmente susceptible a ataques de agotamiento de recursos porque, por diseño, los clientes controlan la profundidad de las consultas, la selección de campos y el volumen de datos solicitados. Sin límites explícitos sobre la complejidad o el coste de ejecución de una consulta, una sola petición puede desencadenar decenas de resoluciones en la base de datos.

Las versiones afectadas abarcan GitLab CE/EE desde 12.4 hasta 18.9.5, las versiones 18.10.0 a 18.10.3, y la versión 18.11.0. La vulnerabilidad fue reportada a través del programa de bug bounty de GitLab en HackerOne (reporte #3098035) y está asociada al work item interno #537422.

Por qué el DoS en GraphQL es un problema arquitectónico

Las APIs REST tienen una limitación natural: cada endpoint hace una cosa concreta con entradas acotadas. La flexibilidad de GraphQL es también su superficie de ataque. Una consulta con anidamiento profundo o que solicita conjuntos masivos de resultados obliga al servidor a resolver cada nodo del grafo, multiplicando el consumo de recursos con cada nivel adicional. El rate limiting HTTP estándar no ayuda aquí: una sola petición puede desencadenar miles de ejecuciones de resolvers y consumir recursos equivalentes a cientos de llamadas API normales.

Esta categoría de ataque aparece sistemáticamente en la literatura de seguridad GraphQL bajo nombres como "query complexity attack" o "alias batching attack." La implementación de GitLab carecía de análisis de coste de consultas suficiente para impedir que usuarios autenticados construyeran deliberadamente este tipo de peticiones.

Consideración de escala para instancias grandes

Para equipos que operan despliegues de GitLab de gran escala — cientos de proyectos, pipelines activos, integraciones que consumen la API GraphQL — el perfil de impacto de esta vulnerabilidad es elevado. Una sola cuenta de servicio comprometida con acceso estándar a la API puede degradar la plataforma completa. El ataque no requiere interacción humana una vez automatizado, lo que facilita que sea sostenido en el tiempo.

CVE-2025-0186 — DoS en el endpoint de discusiones

CVE-2025-0186 tiene la fecha de reserva más antigua de las tres: 3 de enero de 2025. Afecta al endpoint de discusiones de GitLab CE/EE, que gestiona comentarios y hilos de revisión en merge requests, issues y revisiones de commits — una de las superficies más activas en cualquier flujo de trabajo colaborativo con GitLab. Un usuario autenticado puede enviar peticiones especialmente diseñadas a este endpoint para agotar los recursos del servidor, de nuevo a través del patrón CWE-770.

El rango de versiones afectadas comienza en 10.6, lo que convierte a esta en la más amplia de las tres en términos de cobertura histórica. La corrección llega en el mismo lote: 18.9.6, 18.10.4 y 18.11.1. La vulnerabilidad fue reportada por el investigador de seguridad pwnie a través de HackerOne (reporte #2915694).

La ventana de 15 meses entre reserva y parche

Reserva en enero de 2025, parche público en abril de 2026: 15 meses de diferencia. Esto no implica necesariamente una respuesta lenta por parte de GitLab — la reserva de un CVE inicia un proceso de divulgación coordinada, no una publicación inmediata. GitLab agrupa las correcciones en ciclos de lanzamiento de seguridad. Lo que sí implica para los equipos de operaciones es que, si algún actor de amenazas conocía esta vulnerabilidad antes de la divulgación pública, tuvo una ventana de explotación prolongada.

Auditar los logs en busca de actividad inusual en el endpoint de discusiones — volúmenes elevados de peticiones, tiempos de procesamiento anómalos, actividad desde cuentas que habitualmente no generan discusiones — es un ejercicio valioso especialmente para quienes tardaron en aplicar el parche.

Análisis comparativo de los tres CVEs

El vector CVSS uniforme y la clasificación CWE idéntica en tres funcionalidades sin relación directa entre sí apuntan a una brecha sistémica: las superficies API autenticadas de GitLab carecían de presupuesto de recursos consistente. El parche de abril de 2026 cierra estas brechas de forma simultánea.

El error de desarrollo que está detrás de CWE-770

Las vulnerabilidades de agotamiento de recursos en sistemas autenticados casi siempre se originan en el mismo razonamiento defectuoso: los usuarios de confianza no van a abusar del sistema. Este razonamiento conduce a arquitecturas donde los controles de autenticación están presentes pero las restricciones de recursos por operación están ausentes. Añadir análisis de coste a cada endpoint de API es complejo, requiere entender los perfiles de ejecución y complica el testing. Por eso se pospone, y la exposición se acumula silenciosamente.

El modelo correcto es: autenticar primero, luego asignar presupuesto de recursos de forma independiente a la identidad. El rate limiting a nivel HTTP ayuda, pero no aborda el consumo de recursos dentro de una sola petición. Una consulta GraphQL masiva o un trabajo de importación de gran tamaño pueden agotar los recursos del servidor incluso cuando las tasas globales de peticiones parecen completamente normales.

Control de throttling: cómo cambia el resultado

El diagrama muestra la diferencia estructural. A la izquierda, cada petición autenticada llega a la capa de procesamiento sin control: el consumo de recursos crece hasta que el servicio colapsa y los usuarios legítimos quedan bloqueados como daño colateral. A la derecha, un analizador de coste evalúa cada petición antes de que llegue a la capa de ejecución, rechazando operaciones sobredimensionadas con un 429 independientemente de quién las envíe.

Cómo aplicar el parche en tu instancia autogestionada

La actualización es la única remediación completa para las tres vulnerabilidades. No existen workarounds de configuración que las cierren por completo:

1. Confirma tu versión actual: sudo gitlab-rake gitlab:env:info o visita Área de administración → Versión de GitLab.
2. Si estás en 12.3–18.9.5: actualiza a 18.9.6.
3. Si estás en 18.10.0–18.10.3: actualiza a 18.10.4.
4. Si estás en 18.11.0: actualiza a 18.11.1.
5. Para instalaciones Omnibus: sudo apt-get install gitlab-ee=18.9.6-ee.0 (ajusta edición y versión según corresponda).
6. Tras la actualización, verifica en el Área de administración y ejecuta sudo gitlab-ctl status para confirmar que todos los servicios están operativos.

Como medida temporal mientras se coordina la actualización, considera añadir una capa de NGINX o HAProxy frente a la API de GitLab que aplique límites de tamaño de cuerpo de petición y rate limiting por IP sobre los endpoints /api/graphql, los endpoints de importación y los relacionados con discusiones. No cierra las vulnerabilidades completamente, pero reduce significativamente la ventana viable de ataque.

Preguntas frecuentes

¿Estas vulnerabilidades permiten robar datos o ejecutar código remoto?

No. Las tres CVEs están clasificadas como ataques exclusivamente de disponibilidad. El vector CVSS muestra impacto nulo en confidencialidad (C:N) e integridad (I:N). Un atacante puede degradar o interrumpir el servicio, pero no puede leer datos ni ejecutar código arbitrario a través de estas vulnerabilidades.

¿GitLab.com está afectado?

No. La plataforma SaaS de GitLab fue actualizada a versiones corregidas antes de la divulgación pública del 22 de abril de 2026. Estas vulnerabilidades afectan exclusivamente a instalaciones autogestionadas que ejecutan versiones sin parche.

¿El ataque puede ejecutarse de forma anónima?

No. Las tres CVEs requieren una sesión autenticada válida (PR:L en la escala CVSS — privilegios bajos). Las peticiones anónimas a los endpoints vulnerables son rechazadas antes de alcanzar el código susceptible de explotación.

Tardamos en parchear CVE-2025-0186 — ¿debemos auditar los logs?

Sí. Dado que fue reservada en enero de 2025, esta vulnerabilidad tuvo una ventana de exposición prolongada. Busca volúmenes inusuales de peticiones al endpoint de discusiones, trabajos de importación de issues con tiempos de procesamiento anómalos, o consultas GraphQL con duraciones de ejecución desproporcionadas.

¿Afectan a los GitLab Runners o a los pipelines de CI/CD directamente?

De forma indirecta. Estas vulnerabilidades apuntan a la capa del servidor de GitLab — la API y la capa de aplicación. Los Runners en sí mismos no están afectados. Sin embargo, como los Runners dependen de la API del servidor para recibir trabajos, reportar resultados y comunicar estado, un DoS contra el servidor causará que los pipelines se queden colgados o reporten fallos que no tienen relación con el código que se está construyendo.

Conclusión

CVE-2026-1660, CVE-2025-3922 y CVE-2025-0186 sostienen el mismo argumento desde tres ángulos distintos: la autenticación no es un límite de control de recursos. Saber quién hizo una petición no restringe lo que esa petición puede consumir. El parche de seguridad de GitLab de abril de 2026 cierra tres superficies de ataque distintas que compartían esta brecha — importación de issues, consultas GraphQL e hilos de discusión — en una sola actualización coordinada.

El parche está disponible, la ruta de actualización está documentada y el riesgo de no actuar es concreto: pérdida total de disponibilidad con solo un login válido como requisito. Actualiza tus instancias autogestionadas. Y si estás construyendo tus propias APIs, audita tus endpoints autenticados en busca de asignación de recursos sin restricciones — CWE-770 se subestima sistemáticamente hasta que algo cae en el peor momento posible.

Referencias

• CVE-2026-1660 — Detalle NVD: nvd.nist.gov/vuln/detail/CVE-2026-1660
• CVE-2026-1660 — ThreatINT: cve.threatint.eu/CVE/CVE-2026-1660
• CVE-2025-3922 — Detalle NVD: nvd.nist.gov/vuln/detail/CVE-2025-3922
• CVE-2025-3922 — Tenable: tenable.com/cve/CVE-2025-3922
• CVE-2025-0186 — Detalle NVD: nvd.nist.gov/vuln/detail/CVE-2025-0186
• CVE-2025-0186 — Registro CVE.org: cve.org/CVERecord?id=CVE-2025-0186
• GitLab Security Release abril 2026 — GBHackers: gbhackers.com/gitlab-fixes-flaws/
• CWE-770: Asignación de Recursos Sin Límites ni Throttling: cwe.mitre.org/data/definitions/770.html