GitLab expone token de correo que permite crear commits y lanzar CI como cualquier usuario

GitLab asigna a cada cuenta una dirección de correo para crear incidencias por email, del tipo project-id+token-issue@yourcompany.gitlab.com. El token que aparece en medio del email está ligado al usuario y, según la documentación, nunca expira. Aikido Security descubrió que el mismo token se reutiliza en todas las direcciones de proyecto del mismo usuario, lo que convierte a esa dirección en una credencial que permite cualquier acción que el titular pueda realizar.

Con el sufijo -merge-request en lugar de -issue, GitLab interpreta el mensaje como una solicitud de merge. Si el asunto del email incluye el nombre de una rama destino y el cuerpo lleva un parche, GitLab crea o actualiza la rama, aplica el parche y genera el commit con el autor original. Cuando la rama es main y el usuario tiene permisos de maintainer, el atacante puede modificar directamente la rama principal. Además, si el parche altera el archivo .gitlab-ci.yml y el rol lo permite, GitLab ejecuta el pipeline bajo la identidad del usuario, sin pasar por autenticación de dos factores.

El alcance del ataque depende del nivel de permisos del token comprometido. Un token de un usuario con rol de Guest es poco útil, mientras que uno de un Maintainer permite acceso a ramas protegidas y a secretos de CI/CD. Para explotar el vector, el atacante necesita también la ruta y el ID numérico del proyecto; ambos datos son públicos en proyectos abiertos y pueden adivinarse en proyectos privados.

GitLab no verifica la procedencia del email, por lo que la restricción de IP configurada en la instancia no bloquea este flujo. La documentación oficial indica que el correo entrante está exento de restricciones de IP y de 2FA, lo que permite que el ataque se realice desde cualquier origen.

Qué hacer

• Restablecer el token de correo entrante desde la página de tokens de acceso personal; la operación invalida todas las direcciones existentes y obliga a redistribuir la nueva dirección.
• Revisar documentación, READMEs y guías de contribución en busca de direcciones publicadas inadvertidamente.
• En instancias autogestionadas, los administradores pueden desactivar el correo entrante a nivel global, aunque GitLab no ofrece una opción por usuario.
• Monitorizar los logs de correo entrante y los eventos de merge request por email para detectar actividad sospechosa.

GitLab ha actualizado la descripción del token en la UI, indicando que la dirección puede crear incidencias y merge requests, pero la vulnerabilidad persiste: el token sigue sin expirar y no hay mecanismo para validar el remitente. La compañía ha abierto un issue interno para evaluar la aceptación de emails solo de direcciones verificadas, pero aún no hay implementación.

Esta revelación subraya la necesidad de tratar cualquier token estático como una credencial crítica y de revisar las configuraciones predeterminadas que, aunque convenientes, pueden abrir puertas inesperadas a la cadena de suministro.