GitLab ofrece una funcionalidad conocida como «Email work item to this project» que asigna a cada usuario una dirección de correo privada para abrir incidencias directamente desde su bandeja. Esa dirección contiene un token de correo entrante que, según la documentación oficial, nunca expira y debe mantenerse confidencial.
Lo crítico es que el token no está ligado a un proyecto concreto; el mismo valor se reutiliza en todas las direcciones generadas para los distintos proyectos del usuario. Por ello, cualquier persona que conozca esa dirección puede actuar con los mismos permisos que el titular, sin necesidad de validar la procedencia del mensaje.
Uso del token para crear merge requests y ejecutar código
Los investigadores de Aikido Security liderados por Joe Leon descubrieron que basta con modificar la terminación «-issue» de la dirección por «-merge-request». Al adjuntar un parche git y especificar la rama destino en el asunto del correo, GitLab interpreta el mensaje como una solicitud de fusión y lo aplica directamente en la rama indicada, creando la rama si no existía.
El cambio queda registrado como un commit bajo el nombre del usuario cuyo token se utilizó. Si la rama permite escrituras, incluso la rama main puede verse afectada. Además, al modificar el archivo .gitlab-ci.yml dentro del parche, el atacante puede disparar pipelines de CI/CD que se ejecutan con los privilegios del propietario del token.
Alcance del daño según el rol del usuario
El impacto depende del nivel de acceso del titular del token. Un usuario con rol de Guest apenas puede generar incidencias, mientras que un Maintainer puede:
- Crear o actualizar ramas protegidas.
- Acceder a variables y secretos configurados en los pipelines.
- Ejecutar trabajos que potencialmente revelen código fuente o credenciales.
Para que un atacante direccione el mensaje al proyecto correcto, necesita conocer la ruta del proyecto y su identificador numérico. Esa información es pública en los repositorios abiertos; en los privados, basta con otro filtrado de datos, ya que los IDs son predecibles.
Limitaciones y medidas de mitigación
GitLab no verifica la dirección del remitente ni aplica restricciones de IP a los correos entrantes, lo que permite que la explotación se realice desde cualquier origen, incluso cuando el proyecto está restringido a listas de IP. Asimismo, el proceso funciona sin requerir autenticación de dos factores (2FA).
Para contener la vulnerabilidad, los usuarios pueden reiniciar el token de correo entrante desde la sección de tokens de acceso personal; la acción invalida todas las direcciones previamente emitidas. En entornos autogestionados, los administradores pueden desactivar la funcionalidad de correo entrante a nivel de instancia, aunque no ofrece una opción individual para cada cuenta.
GitLab ha actualizado la descripción de la funcionalidad, indicando explícitamente que la dirección permite crear tanto incidencias como merge requests y recordando la necesidad de mantener el token confidencial. La empresa también abrió un ticket interno para evaluar la verificación del remitente, pero aún no hay una solución implementada.
