La protección por IP no bastará: GitLab permitirá que código ajeno llegue a «main» por correo electrónico

La función habitual para enviar incidencias por correo resultó estar mucho más cerca de una cuenta completa de lo que parece por la interfaz. Joe Leon de Aikido Security demostró que la dirección privada de correo de GitLab contiene un token permanente con el que se puede enviar código a los repositorios y ejecutar tareas de compilación y despliegue CI/CD en nombre del propietario.

GitLab asigna al usuario una dirección personal para crear incidencias por correo electrónico. Dentro de la dirección hay una cadena con el prefijo glimt- que la plataforma utiliza como incoming email token. La documentación de GitLab indica que dicho token no caduca y debe mantenerse en secreto, ya que quien lo posea puede crear incidencias y solicitudes de fusión en nombre del propietario.

Leon descubrió que la dirección parecía vinculada a un proyecto concreto, pero el token integrado funciona más ampliamente. Al activar la función de correo en distintos proyectos de la cuenta cambian las partes de la dirección relacionadas con el proyecto, mientras que el propio token glimt- permanece igual. Sus permisos se extienden a los proyectos a los que ya tiene acceso la cuenta del usuario.

Para pasar de crear una incidencia a modificar código basta con sustituir en la dirección el sufijo issue por merge-request. GitLab acepta en ese correo archivos .patch y aplica los cambios a la rama de origen. El nombre de la rama se transmite en el asunto del correo. Si la rama existe y el titular del token tiene permiso para enviar cambios, GitLab añade un commit en su nombre.

En una prueba controlada Aikido puso en el asunto main y adjuntó un archivo .patch preparado. El commit llegó a la rama principal de un proyecto privado. Si los cambios afectan a .gitlab-ci.yml y los permisos del usuario permiten ejecutar el trabajo, de la misma manera se puede ejecutar código CI/CD y luego intentar leer variables disponibles, secretos o usar CI_JOB_TOKEN.

La vía del correo también elude la barrera de red en la que pueden confiar los administradores. En el proyecto de prueba se permitió el acceso únicamente desde una dirección IP externa: la interfaz web y git clone desde la máquina de Leon dejaron de funcionar, sin embargo GitLab aceptó el correo. La documentación de la plataforma indica explícitamente que el correo entrante no está sujeto a restricciones por IP.

El escenario no eleva privilegios por sí solo. Las posibilidades dependen del rol del propietario de la dirección filtrada: el token de un usuario Guest es casi inútil para modificar código, mientras que la dirección de un Maintainer puede dar acceso a ramas protegidas y datos sensibles de CI/CD. Para atacar otro proyecto privado también hace falta conocer su ruta e identificador.

Aikido encontró en documentación pública y en README alrededor de una docena de direcciones entrantes activas, algunas de las cuales los desarrolladores publicaron deliberadamente como contactos para reportes de errores. Antes de publicar el artículo, el equipo avisó a los propietarios. No hay datos de ataques reales mediante este mecanismo; la demostración se realizó únicamente en proyectos bajo control de Aikido.

El problema se notificó a través de HackerOne en mayo de 2026, pero el informe se cerró como comportamiento previsto. Tras una nueva notificación en junio, GitLab ajustó la interfaz y la documentación: eliminó la afirmación sobre la imposibilidad de acceder a otros datos, añadió la mención a las solicitudes de fusión y describió la excepción para el filtrado por IP. El mecanismo de envío de código por correo se mantuvo igual.

El hallazgo no tiene CVE, ni corrección independiente ni boletín de seguridad. Según la evaluación de Aikido, el escenario afecta a todas las cuentas de GitLab.com y a instalaciones autoalojadas con el correo entrante habilitado; el equipo de GitLab Dedicated no lo verificó. Si la dirección pudo filtrarse, Aikido recomienda restablecer el incoming email token y buscar tales direcciones en los repositorios como secretos habituales.

El riesgo es especialmente notable junto con otros problemas en torno a GitLab: en septiembre los atacantes ya atacaron servidores mediante una vulnerabilidad crítica CVE-2026-85706. El trabajo de Aikido describe otra clase de amenaza, en la que no se requiere un fallo de software para realizar acciones peligrosas si la propia información de la cuenta de correo ha salido a la luz.