Ilustración editorial generada con IA por Defensops. No es una fotografía del incidente ni de los equipos afectados. Representa Ilustración de un token por correo que genera cambios de código y tareas CI/CD.

Síntesis y análisis propios a partir de la cobertura de The Hacker News; las afirmaciones del medio se atribuyen a su fuente.

Qué se ha confirmado

The Hacker News recoge que Aikido Security trató la dirección privada de GitLab para crear incidencias por correo como una credencial: contiene un token de cuenta que no caduca.

Aikido observó que las direcciones de distintos proyectos de un mismo usuario comparten el token y que GitLab acepta mensajes de cualquier buzón como si procedieran de ese usuario.

La demostración convirtió una dirección para incidencias en otra para solicitudes de fusión, adjuntó un parche y logró que GitLab aplicara el cambio como commit en una rama sobre la que el usuario podía escribir.

Si el rol del usuario permite cambiar el archivo de configuración de CI/CD, el parche puede iniciar trabajos con sus permisos; el alcance depende del rol y de conocer la ruta y el identificador del proyecto.

En una prueba de Aikido con un proyecto privado restringido a una dirección IP, GitLab bloqueó el navegador y la clonación pero aceptó el mensaje de fusión y registró el commit en main.

Según la publicación, el correo entrante también funciona sin autenticación de dos factores; la característica existe en GitLab.com y en instalaciones autogestionadas con correo entrante habilitado.

GitLab modificó la descripción visible de la función tras el reporte, pero el comportamiento descrito continúa; la restricción a remitentes verificados solo está en estudio.

Análisis de Defensops

El riesgo principal no es un correo falsificado aislado, sino la exposición de un token que parece ser solo una dirección de soporte. Su reutilización entre proyectos rompe la intuición de que publicar una dirección de un proyecto limita el daño a ese proyecto. La capacidad real sigue sujeta al rol de la cuenta y a la identificación del proyecto objetivo.

La vía de correo tiene un perímetro distinto al de la interfaz web. La prueba citada muestra que una restricción por IP y el uso de 2FA no bloquean necesariamente estas acciones, por lo que una revisión que se limite a inicios de sesión interactivos podría no detectar el origen de un commit. Los cambios en ramas y los trabajos de CI/CD deben analizarse según el canal que los creó.

La fuente no describe una campaña de explotación real. Aikido afirma haber encontrado direcciones expuestas en páginas públicas, pero eso no demuestra que hayan sido usadas por atacantes. GitLab considera el token una credencial; la medida inmediata es tratar la dirección como secreta y rotarla si se ha difundido.

Prioridades de revisión

Buscar direcciones de correo de creación de incidencias de GitLab publicadas en README, guías de contribución, páginas de soporte y registros accesibles; priorizar las asociadas a cuentas con permisos de escritura o mantenimiento.

Si una dirección se publicó o se sospecha filtrada, restablecer el token de correo entrante desde el perfil del usuario y actualizar los flujos legítimos que dependan de las direcciones anteriores.

Revisar commits y trabajos CI/CD creados por correo en los proyectos accesibles a cuentas afectadas, especialmente cambios en .gitlab-ci.yml y ramas protegidas.

En instalaciones autogestionadas donde no se necesite la función, evaluar la desactivación del correo entrante a nivel de instancia; documentar los usos que se perderían.

Hasta que haya cambios de producto, no asumir que la lista de IP permitidas o la autenticación de dos factores de la interfaz web protegen esta vía de correo.

Qué no se ha confirmado

La publicación no documenta explotación maliciosa de las direcciones encontradas por Aikido.

Aikido no pudo probar directamente GitLab Dedicated y solo indica que no parece afectado.

GitLab aún no ha implantado la propuesta de aceptar correo solo de direcciones verificadas.

Fuente

The Hacker News. Fecha indicada: 2026-09-23.