Los tokens de correo electrónico de GitLab permiten enviar código y ejecutar CI sin autenticación

Investigadores de seguridad de Aikido Security han identificado una vulnerabilidad significativa en la función de correo entrante de GitLab que permite a los atacantes enviar código y ejecutar trabajos de CI/CD utilizando únicamente una dirección de correo electrónico filtrada. Reportado a mediados de 2026, este fallo afecta tanto a GitLab.com como a instancias autoalojadas donde el correo entrante está habilitado, tratando efectivamente un token de correo estático como una credencial de alto privilegio que elude controles de seguridad estándar como la autenticación de dos factores y las listas blancas de IP.

Qué ocurrió

El núcleo del problema radica en cómo GitLab maneja la conversión de correos electrónicos a elementos de trabajo (work items). Cada cuenta de usuario en GitLab tiene asignado un token único y sin caducidad incrustado dentro de una dirección de correo electrónico utilizada para crear issues. Aunque esta dirección parece específica de un solo proyecto, Aikido Security descubrió que el token subyacente se comparte entre todos los proyectos accesibles por ese usuario. En consecuencia, cualquiera que obtenga esta dirección de correo puede interactuar con cualquier proyecto público o privado al que el usuario tenga acceso, independientemente del proyecto que originalmente mostraba la dirección.

La vulnerabilidad escala más allá de la simple creación de issues. Al modificar el sufijo de la dirección de correo de -issue a -merge-request, un atacante puede enviar parches directamente a un repositorio. Si el atacante conoce la ruta del proyecto objetivo y su ID numérico, puede enviar un correo con un parche de código adjunto. GitLab procesa este correo como una solicitud de fusión (merge request), aplicando el parche a la rama especificada. Si el usuario tiene permiso para enviar cambios a esa rama, incluidas ramas protegidas como main, el código se confirma bajo la identidad del usuario. Además, si el parche modifica el archivo .gitlab-ci.yml, GitLab ejecutará los trabajos de CI/CD resultantes con los permisos del usuario, lo que podría exponer secretos o comprometer la infraestructura.

Detalles clave

• Token compartido: El token de correo es idéntico para todos los proyectos a los que un usuario puede acceder, lo que significa que una fuga desde un proyecto compromete el acceso a todos los demás.
• Sin verificación del remitente: GitLab no verifica la dirección de correo del remitente contra el propietario de la cuenta, permitiendo que cualquier buzón actúe como el usuario.
• Elusión de controles de seguridad: Las acciones mediante correo entrante están exentas de restricciones de IP y requisitos de autenticación de dos factores, incluso si se aplican en otros contextos.
• Dependiente de privilegios: El impacto escala según el rol del usuario; las cuentas Guest tienen un impacto limitado, mientras que los Maintainers pueden enviar cambios a ramas protegidas y acceder a secretos de CI.
• Identificación del objetivo: Los atacantes necesitan la ruta del proyecto y el ID numérico además del token, aunque los IDs son fácilmente adivinables y las rutas suelen ser públicas.
• Sin desactivación a nivel de usuario: Los usuarios individuales no pueden desactivar la creación de issues o merge requests basada en correo; solo los administradores de la instancia pueden deshabilitar la función globalmente.

Contexto

La función de correo entrante de GitLab está diseñada para agilizar el flujo de trabajo permitiendo a los usuarios crear issues o merge requests a través de clientes de correo. Esto es particularmente útil para equipos que gestionan la triage mediante interfaces de correo o que quieren reducir la barrera para que contribuidores externos reporten errores. El sistema depende de una dirección de correo única para cada combinación usuario-proyecto, que contiene un token oculto que autentica la acción.

Sin embargo, los tokens de autenticación generalmente requieren políticas estrictas de confidencialidad y rotación. En este caso, el token es estático y nunca caduca. Aunque GitLab lo trata como una credencial estándar, su integración con el sistema de correo crea un punto ciego. Medidas de seguridad tradicionales como la lista blanca de IP, que restringe el acceso a redes conocidas, no se aplican al tráfico de correo entrante. De manera similar, la autenticación de dos factores (2FA), que añade una segunda capa de verificación para los inicios de sesión, se elude porque el sistema de correo confía implícitamente en el token sin desafiar al remitente.

Por qué importa

Para los equipos que ejecutan instancias autoalojadas de GitLab o utilizan GitLab.com, esta vulnerabilidad destaca una brecha crítica en la seguridad de la cadena de suministro. Los desarrolladores a menudo comparten información de contacto en archivos README, guías de contribución o páginas de soporte para facilitar el reporte de errores. Si estos documentos contienen la dirección de correo especial de GitLab, publican inadvertidamente una credencial que otorga acceso de escritura al código. Aikido Security encontró aproximadamente una docena de estas direcciones activas publicadas abiertamente, incluyendo en proyectos de código abierto ampliamente utilizados.

La capacidad de eludir las restricciones de IP es especialmente preocupante para empresas que dependen de la seguridad a nivel de red para proteger sus bases de código. Un atacante fuera de la red corporativa aún puede enviar código malicioso a la rama principal si posee el token de correo. Esto socava la suposición de que las ramas internas están a salvo de amenazas externas. Además, la ejecución de trabajos de CI/CD como el usuario comprometido puede llevar a movimientos laterales adicionales dentro de la infraestructura, especialmente si esos trabajos tienen acceso a claves de despliegue o credenciales de nube.

Qué puedes hacer

• Restablece tu token: Ve a la página de tokens de acceso personal en GitLab y restablece tu token de correo entrante. Esto invalida todas las direcciones de proyecto existentes inmediatamente.
• Audita la documentación pública: Busca en los READMEs de tus proyectos, guías de contribución y páginas de soporte cualquier dirección de correo de GitLab publicada y elimínala.
• Desactiva el correo entrante: Si eres administrador de una instancia autoalojada, considera desactivar la función de correo entrante globalmente si no es esencial para tu flujo de trabajo.
• Monitorea las solicitudes de fusión: Presta mucha atención a las merge requests creadas vía correo, especialmente aquellas dirigidas a ramas protegidas o que modifican archivos de configuración de CI.
• Educa a los miembros del equipo: Informa a los desarrolladores que la dirección de correo mostrada en el botón "Email work item" es una credencial que otorga acceso de escritura al código.