Un fallo de diseño en la funcionalidad de correo electrónico de GitLab está permitiendo a atacantes comprometer repositorios privados con solo modificar una dirección de correo electrónico expuesta en documentación pública. Investigadores de seguridad han demostrado que los tokens incrustados en estas direcciones, diseñados para crear issues por correo, pueden ser reutilizados para abrir merge requests y empujar código directamente a ramas protegidas, eludiendo restricciones de IP y de verificación del remitente.
El mecanismo detrás del ataque: del correo a la fusión de código
GitLab incluye una funcionalidad llamada «Email work item to this project» que permite a los desarrolladores crear issues o tareas en un proyecto enviando un correo electrónico a una dirección especialmente generada. Cada dirección contiene un token persistente identificado por el prefijo glimt-, que actúa como una credencial vinculada a la cuenta del desarrollador. Cuando un cliente externo envía un mensaje a esa dirección, GitLab lo parsea y lo convierte en un issue o tarea dentro del proyecto.
La vulnerabilidad descubierta por los investigadores de la empresa de seguridad Aikido radica en que estas direcciones pueden modificarse trivialmente. Cambiando el sufijo -issue por -merge-request en cualquier dirección de este tipo, GitLab interpreta el mensaje como una solicitud de merge, abriendo un merge request en el proyecto. El sistema no verifica que el remitente del correo coincida con el propietario del token, ni siquiera comprueba la dirección de origen. Cualquier buzón de internet puede enviar a esa dirección, y GitLab procesa el mensaje como si fuera el propietario del token.
¿Qué es exactamente el token ‘glimt-‘ y por qué es crítico?
El token glimt- es una cadena única generada automáticamente por GitLab para cada proyecto que tiene habilitada la recepción de work items por correo. Este token permanece constante para todas las direcciones generadas para ese proyecto, y sirve como credencial de acceso. Al estar incrustado en la dirección de correo, cualquier persona que conozca esa dirección puede utilizarla para interactuar con el proyecto como si fuera el desarrollador original. GitLab advierte explícitamente en su documentación que estas direcciones son privadas y que «cualquiera que las conozca puede crear issues o merge requests como si fuera usted».
Hallazgos de Aikido: una docena de direcciones expuestas en una tarde
En una sola tarde de investigación, los analistas de Aikido localizaron una docena de direcciones de correo electrónico activas de GitLab expuestas en archivos README públicos, guías de contribución y páginas de soporte. Estas direcciones habían sido incluidas deliberadamente por los mantenedores de los proyectos para facilitar el envío de informes de errores. En varios casos, los proyectos afectados eran repositorios de código abierto muy populares, lo que crea un riesgo significativo en la cadena de suministro de software para grandes bases de usuarios.
Los investigadores subrayan que, además de la restricción de permisos (que no puede eludirse), un atacante necesita conocer el path y el ID del proyecto objetivo. En proyectos públicos, esta información está disponible abiertamente. En proyectos privados, el ID puede ser obtenido mediante fuerza bruta, aunque el path requeriría una filtración previa. La combinación de una dirección de correo expuesta con la posibilidad de obtener el path y el ID hace que el ataque sea factible incluso contra repositorios privados.
¿Cómo puede un atacante explotar una dirección expuesta?
El ataque se desarrolla en varios pasos:
- Obtener la dirección de correo de GitLab expuesta en documentación pública (READMES, guías de contribución, páginas de soporte).
- Identificar el sufijo -issue o -work-item en la dirección.
- Modificar el sufijo a -merge-request.
- Enviar un correo con el contenido deseado (código malicioso, cambios en ramas protegidas, etc.) a la dirección modificada.
- GitLab procesa el mensaje como si proviniera del propietario del token y abre un merge request.
Los investigadores de Aikido confirmaron que este ataque elude por completo las restricciones de dirección IP configuradas en el proyecto. El nivel de acceso resultante depende enteramente de los permisos del usuario cuyo token está vinculado a la dirección. En escenarios donde el desarrollador tiene permisos de mantenedor o superior, un atacante podría:
- Empujar código a ramas protegidas de repositorios privados.
- Robar el código fuente completo del proyecto.
- Extraer secretos almacenados en variables de CI/CD.
- Acceder a issues confidenciales y otra información sensible.
La respuesta de GitLab: de ‘comportamiento intencionado’ a actualizaciones parciales
Aikido reportó la vulnerabilidad a GitLab a través de la plataforma HackerOne en mayo de 2024. GitLab cerró el reporte inicial calificándolo como «comportamiento intencionado», argumentando que la funcionalidad está documentada y que la exposición de las direcciones es responsabilidad del usuario. Sin embargo, tras una segunda notificación en junio, GitLab realizó varias actualizaciones: modificó la interfaz de usuario para mencionar también los merge requests, eliminó afirmaciones incorrectas sobre el acceso a datos del token, y documentó explícitamente que el correo entrante elude las restricciones de IP.
A pesar de estas mejoras, GitLab no ha modificado el comportamiento fundamental del sistema. La compañía ha abierto un work item interno (número 617883) para considerar la posibilidad de verificar que la dirección de envío coincida con el correo del propietario del token, pero hasta la fecha no se ha implementado ningún cambio sustancial.
¿Por qué GitLab considera esto un comportamiento intencionado?
La postura de GitLab se basa en que la documentación ya advertía a los usuarios que no compartieran estas direcciones. Sin embargo, los investigadores de Aikido señalan que la facilidad con la que se puede modificar el sufijo para pasar de issues a merge requests no estaba claramente documentada, y que muchos mantenedores de proyectos desconocen que exponer la dirección para issues abre automáticamente la posibilidad de merge requests. La falta de verificación del remitente agrava el problema, ya que cualquier atacante que encuentre la dirección puede abusar de ella sin necesidad de suplantar el correo del propietario.
Implicaciones para la cadena de suministro de software
El hallazgo tiene consecuencias directas para la seguridad del ecosistema open source. Los proyectos populares que exponen estas direcciones en su documentación ponen en riesgo a todos los usuarios que dependen de ellos. Un atacante podría inyectar código malicioso en un proyecto de código abierto ampliamente utilizado, propagando malware a través de actualizaciones legítimas. Este tipo de ataque a la cadena de suministro ha sido responsable de incidentes de alto perfil en el pasado, como el compromiso de SolarWinds o la inyección de backdoors en bibliotecas de JavaScript.
La naturaleza persistente del token (no caduca a menos que se reinicie manualmente) hace que el riesgo sea continuo. Incluso si un mantenedor elimina la dirección expuesta de la documentación, el token sigue siendo válido y puede ser utilizado por cualquiera que lo haya capturado durante el período de exposición.
Recomendaciones prácticas para desarrolladores y administradores
Los mantenedores de proyectos deben dejar de incluir direcciones de correo de GitLab en documentación pública, incluso si solo pretenden recibir informes de errores. Existen alternativas más seguras, como formularios web, issues tracker integrados o servicios de terceros especializados. Para aquellos que ya hayan expuesto direcciones en el pasado, es imprescindible reiniciar el token inmediatamente. GitLab proporciona una opción para regenerar el token en la configuración del proyecto, lo que invalida todas las direcciones existentes.
Los administradores de instancias de GitLab (tanto self-managed como SaaS) deberían revisar si la funcionalidad de correo entrante está habilitada por defecto y considerar deshabilitarla para proyectos que no la necesiten explícitamente. También pueden implementar políticas de seguridad que exijan la verificación del remitente o la restricción por IP a nivel de servidor de correo, aunque GitLab ya ha confirmado que sus propias restricciones de IP no se aplican a este canal.
¿Qué deben hacer los equipos de seguridad?
Los equipos de seguridad deberían auditar sus repositorios y documentación pública en busca de direcciones de correo que contengan el patrón glimt-. Herramientas de escaneo automatizado pueden detectar estas cadenas en archivos README, guías de contribución, páginas wiki y cualquier otro documento accesible públicamente. Además, es recomendable revisar los logs de merge requests en busca de solicitudes inusuales que puedan haberse originado a través del canal de correo.
En un nivel más amplio, este incidente subraya la necesidad de que las plataformas de desarrollo adopten un enfoque de seguridad por diseño, donde las funcionalidades que otorgan acceso privilegiado requieran autenticación adicional por defecto, en lugar de confiar en que los usuarios no compartirán información sensible.
El equilibrio entre funcionalidad y seguridad en las herramientas de desarrollo
La característica de crear work items por correo electrónico tiene un claro valor de productividad: permite a desarrolladores y contribuyentes externos enviar tareas sin necesidad de acceder a la interfaz web de GitLab. Sin embargo, cuando esa misma dirección puede ser reutilizada para abrir merge requests sin verificación del remitente, el equilibrio se inclina peligrosamente hacia el riesgo. La decisión de GitLab de considerar esto como comportamiento intencionado refleja una filosofía en la que la funcionalidad prima sobre la seguridad, dejando la responsabilidad en manos del usuario final.
Los investigadores de Aikido resumen la cuestión de forma contundente: «En principio, comprobar que la dirección de envío coincide con el correo del propietario del token añadiría una capa de defensa, pero GitLab no hace esto». Hasta que la plataforma implemente esa verificación o un mecanismo equivalente, la responsabilidad recae exclusivamente en los mantenedores y administradores. En un ecosistema donde los ataques a la cadena de suministro son cada vez más sofisticados, exponer estas direcciones es un riesgo evitable que ningún proyecto debería asumir.
