Una vulnerabilidad en la función de GitLab "Email work item to this project" puede permitir que atacantes comprometan repositorios privados. Según la investigación de Joe Leon de Aikido Security, si se expone la dirección privada del proyecto, que contiene un token de correo electrónico que no expira, un actor malintencionado podría utilizarlo como base para introducir código en repositorios privados.

La función de GitLab “Enviar elemento de trabajo por correo electrónico a este proyecto” puede convertirse en una primitiva de compromiso del repositorio cuando su dirección privada queda expuesta, según la investigación publicada por el investigador de Aikido Security, Joe Leon, el 23 de septiembre de 2026.

La dirección contiene un token de correo electrónico entrante glimt- de larga duración que, según GitLab, no caduca y debe permanecer en secreto. La documentación de GitLab confirma que cualquier persona que lo posea puede crear incidencias y solicitudes de fusión (merge requests) como si fuera el propietario del token.

El fallo va mucho más allá del spam de incidencias. Aunque la interfaz presenta una dirección específica para cada proyecto, Aikido descubrió que las direcciones generadas para diferentes proyectos integran el mismo token a nivel de cuenta.

Según se informa, un atacante puede sustituir el sufijo -issue por -merge-request, adjuntar un parche de Git e identificar una rama de origen en el asunto del correo electrónico. GitLab entonces aplica el parche a esa rama o la crea utilizando los permisos de la víctima.

En consecuencia, un parche malicioso que modifique el archivo .gitlab-ci.yml puede ejecutar código de CI/CD controlado por el atacante en el proyecto de la víctima. Dependiendo del rol del usuario comprometido y de la configuración del pipeline, esto podría exponer el código fuente, variables de CI/CD, tokens de trabajo u otros secretos.

La filtración de la dirección de un Mantenedor podría incluso permitir realizar commits en ramas protegidas, incluida la rama main, mientras que las acciones aparecerían bajo la identidad de la víctima. Por el contrario, un token de Invitado (Guest) sigue estando limitado por los permisos de ese usuario.

Según la investigación publicada por Aikido Security, la ruta del correo también debilita las suposiciones sobre los controles de red. Aikido señaló que sus investigadores configuraron un proyecto privado para aceptar solo una dirección IP no relacionada; GitLab bloqueó el acceso mediante navegador y la clonación de Git, pero aceptó el parche enviado por correo, logrando un commit en main.

GitLab ahora documenta explícitamente que el correo electrónico entrante no está sujeto a restricciones de IP, lo que significa que las listas blancas no son límites de seguridad completos para estos flujos de trabajo.

La explotación requiere la dirección privada más suficiente información de enrutamiento para identificar un proyecto objetivo, incluyendo su ruta e ID de proyecto. Los repositorios públicos revelan esos detalles, mientras que los ataques contra proyectos privados requerirían generalmente otra filtración de información.

La suplantación del remitente (sender spoofing) no es necesaria porque GitLab no exige actualmente que los mensajes provengan de un correo electrónico verificado en la cuenta del propietario del token. GitLab ha abierto una incidencia para explorar dicha verificación.

GitLab trató el comportamiento reportado como algo "diseñado así" en lugar de una vulnerabilidad convencional, pero fusionó cambios que aclaran las capacidades del token.

La interfaz actualizada y el texto de la documentación ahora mencionan tanto las incidencias como las solicitudes de fusión, enfatizan la confidencialidad y los procedimientos de restablecimiento, y explican la excepción de restricción de IP. Sin embargo, el mecanismo de correo electrónico subyacente sigue estando disponible.

Si eres responsable de la defensa, deberías buscar inmediatamente en repositorios, documentación, tickets, registros y páginas públicas cualquier dirección glimt- y formatos de tokens de correo entrante antiguos o personalizados.

Si sospechas que ha habido una exposición, debes restablecer el token de correo electrónico entrante en la configuración de tokens de acceso personal, lo que invalidará las direcciones de proyecto asociadas.

También deberías revisar los permisos de los usuarios afectados, las reglas de ramas protegidas, los pipelines, las variables, los commits y los eventos de auditoría, tratando cada dirección de correo electrónico de proyecto como una credencial de cuenta y no como una dirección de contacto inofensiva.

Fuentes:
https://cybersecuritynews.com/gitlab-email-private-repository-flaw/