En resumen
GitLab le proporciona una dirección de correo electrónico privada para crear incidencias. Si se filtra, cualquier persona que la tenga puede enviar código, ejecutar trabajos de CI/CD y omitir las restricciones de IP en todos sus proyectos públicos y privados. Esto afecta a todas las cuentas de GitLab.com y a los servidores de GitLab autohospedados que permiten a los usuarios crear incidencias por correo electrónico.
Qué debe comprobar
Paso 1: ¿Está la función activada?
- GitLab.com: Sí, para todas las cuentas. No se puede desactivar.
- GitLab autohospedado: Tal vez.
- Abra la lista de elementos de trabajo de uno de sus proyectos y haga clic en ⋮. Si ve "Enviar elemento de trabajo por correo electrónico a este proyecto" o algo similar, está activada.
- GitLab Dedicated: No.
Paso 2: ¿Alguien ha compartido alguna de estas direcciones?
La dirección solo es peligrosa si alguien que no sea su propietario la tiene. Busque `@incoming.gitlab.com` en sus repositorios, documentación, centro de ayuda y wikis (los usuarios autohospedados deben buscar el dominio en su propia dirección). Una coincidencia es peligrosa si la dirección tiene un token antes de `-issue` o `-merge-request`:
- Peligrosa: incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
- Segura: incoming+group-project-12346426-issue-@incoming.gitlab.com
Betterleaks (gratuito y de código abierto) y la detección de secretos de Aikido encuentran estas direcciones en sus repositorios automáticamente, incluidos los formatos anteriores.
Paso 3: Restablecer las direcciones filtradas
El propietario de una dirección de correo electrónico filtrada debe ir a Configuración de usuario > Tokens de acceso personal > Token de correo electrónico entrante y hacer clic en restablecer (enlace directo para GitLab.com). Esto cambia todas las direcciones de correo electrónico de sus proyectos a la vez y las antiguas dejan de funcionar.
Compruebe las confirmaciones recientes, especialmente los cambios en .gitlab-ci.yml, y las ejecuciones recientes de canalizaciones en busca de cualquier acción que el propietario de la dirección de correo electrónico no recuerde haber realizado.
La historia completa
Los proyectos de GitLab tienen un botón etiquetado como «Enviar elemento de trabajo por correo electrónico a este proyecto».
Si haces clic en él, GitLab te muestra una dirección de correo electrónico privada. Envía cualquier mensaje a esa dirección y aparecerá una nueva incidencia en ese proyecto, con tú como autor.
entrante+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
La cadena «glimt-» que aparece en medio de esa dirección es una credencial. Se trata de un token de larga duración vinculado a tu cuenta, y nunca caduca.
Además, hace mucho más que simplemente notificar errores. Cualquier persona que disponga de esa dirección puede enviar código y ejecutar tareas de CI/CD en todos los proyectos a los que tenga acceso tu cuenta.
Probamos esto con un proyecto privado protegido por las restricciones de IP de GitLab, configuradas para aceptar conexiones desde una única dirección que no era la nuestra. GitLab bloqueó nuestro navegador y rechazó el comando «git clone». Aceptó el correo electrónico y la confirmación se publicó en la rama «main».
A simple vista, no parece suponer ningún problema en la interfaz de usuario
La creación de incidencias por correo electrónico es una función habitual de este tipo de productos. Trello, Todoist y Monday.com ofrecen esta función, y todos la gestionan de la misma manera: cada correo enviado a una dirección específica genera una unidad de trabajo en un proyecto. Por eso, los usuarios llegan a GitLab esperando encontrar lo mismo.
Y la interfaz de usuario de GitLab lo confirmó. La ventana modal indicaba a los usuarios que la dirección era exclusivamente suya y que se añadían elementos a este proyecto.
La página «Tokens de acceso personales» (en «Configuración de usuario») descartaba cualquier otra posibilidad. GitLab indicaba que el token de correo electrónico entrante te autentica cuando creas una nueva incidencia por correo electrónico y que «no se puede utilizar para acceder a ningún otro dato».
Ese es el modelo mental que tienen los usuarios de GitLab. Se trata de una dirección de correo electrónico que sirve para crear incidencias dentro de un proyecto concreto, y debe mantenerse privada.
Nota: Después de ponerme en contacto con GitLab, añadieron el texto «y solicitudes de fusión» a ambos elementos de la interfaz de usuario.
¿Mi dirección de correo electrónico es un PAT?
GitLab tiene razón al decir que debes mantenerla en privado, pero está subestimando el riesgo. El token incluido en esta dirección de correo electrónico es, en esencia, un token de acceso personal muy detallado que otorga un acceso considerable a tus proyectos de GitLab.
Acceso para toda la cuenta
Si abres la opción «Enviar el elemento de trabajo por correo electrónico a este proyecto» en cinco proyectos diferentes, GitLab te proporciona cinco direcciones distintas. El token «glimt-» incluido en cada una de ellas es idéntico, incluso en los proyectos privados.
La interfaz de usuario muestra la dirección como si fuera específica de un proyecto, pero la credencial que contiene no lo es. Ese token pertenece a toda tu cuenta y es válido para todos los proyectos a los que tienes acceso, tanto públicos como privados.
No importa quién sea el remitente
GitLab no verifica la identidad del remitente. En principio, comprobar que la dirección de envío coincida con el correo electrónico del propietario del token añadiría una capa de seguridad, pero GitLab no lo hace (aunque ahora se lo están planteando). Cualquier buzón de correo de Internet puede enviar mensajes a esa dirección, y GitLab procesa el mensaje como si procediera del propietario del token. Si tienes la dirección, dispones tanto de autenticación como de autorización.
De los problemas al código
Cambia el sufijo «-issue» de la dirección de correo electrónico por «-merge-request» y GitLab abrirá una solicitud de fusión.
Eso por sí solo no es gran cosa, ya que un atacante no puede dirigir la solicitud de fusión a una bifurcación maliciosa que controle. Sin embargo, los correos electrónicos de las solicitudes de fusión admiten archivos adjuntos .patch de Git, y GitLab aplica esos cambios a la rama de origen. Si el parche afecta al archivo .gitlab-ci.yml y el rol de la víctima lo permite, GitLab ejecuta la tarea del atacante.
El proceso completo, de principio a fin:
- La víctima publica o filtra la dirección de correo electrónico destinada a notificar incidencias del proyecto.
- El atacante cambia -issue@ por -merge-request@.
- El atacante escribe un parche añadiendo un job a .gitlab-ci.yml, sin conocer el repositorio de destino.
- El atacante envía el parche por correo, indicando la rama de origen en el asunto. GitLab realiza un push a esa rama si existe y la crea si no.
- GitLab ejecuta el job en el proyecto de la víctima, con los permisos de esta.
La ejecución de CI/CD es un resultado. El otro es un commit en cualquier rama a la que la víctima pueda hacer push, incluida main, firmado por ella. Cualquiera que compile desde ese repositorio incorporará el código del atacante.
Los correos electrónicos eluden las restricciones de IP
Restringimos un proyecto privado a una única dirección IP que no era la nuestra.
GitLab bloqueó nuestro navegador y rechazó nuestros comandos de clonación de git. Sin embargo, siguió aceptando un correo electrónico de merge request.
Los equipos activan las restricciones de IP creyendo que han establecido un perímetro de seguridad alrededor de un proyecto, a menudo en el borde de una VPN corporativa. El límite se mantiene para HTTP y SSH, pero no para el correo entrante. Un atacante que no pueda acceder al proyecto desde la red puede hacerlo a través de la vía del correo.
Lo que una sola dirección le otorga a un atacante
Una única dirección de correo electrónico filtrada puede comprometer gravemente la cuenta de GitLab de un usuario o de una organización. Confirmamos cada una de estas rutas de ataque en proyectos bajo nuestro control:
- Hacer push de código a una rama protegida en un repositorio privado protegido por una lista blanca de IP.
- Exfiltrar código fuente de proyectos privados protegidos por una lista blanca de IP.
- Leer variables de CI/CD y secretos de proyectos privados.
- Acceder a incidencias confidenciales en proyectos privados (mediante la acción rápida /move).
- Utilizar el CI_JOB_TOKEN disponible en los jobs de CI/CD para profundizar en la cuenta.
Una dirección de correo electrónico entrante de GitLab contiene un token que actúa como un token de acceso personal de grano fino con permisos significativos.
La distinción más importante es que, en lugar de acceder a GitLab mediante API, los usuarios deben enviar datos a través de correos electrónicos. Desde la perspectiva de un defensor, si el resultado puede ser el mismo compromiso de la cuenta, ¿importa si se trata de una petición HTTP o de un correo electrónico?
Restricciones del atacante
Dos factores limitan a un atacante que posee la dirección:
1. El token hereda los permisos de la víctima y nada en la ruta del correo los escala.
Los permisos de la víctima limitan el alcance de los daños. Una dirección de Guest filtrada no tiene prácticamente ningún valor. Una dirección de Maintainer filtrada podría alcanzar ramas protegidas y variables de CI/CD. Nada en la vía del correo establece ese límite, solo el rol de la víctima.
2. El enrutamiento requiere saber a qué proyecto se dirige.
GitLab resuelve el destino a partir de dos valores dentro del correo electrónico entrante: el slug de la ruta del proyecto y el ID del proyecto. Para llegar a un segundo proyecto, un atacante debe proporcionar la ruta y el ID de otro proyecto junto con el token robado. Para los proyectos públicos, GitLab publica ambos valores. Para los proyectos privados, el atacante necesita una filtración de información que nombre el proyecto (el ID se puede adivinar).
Una docena, publicadas a propósito
Todo lo anterior depende de que un atacante consiga una dirección de correo electrónico. Pasamos una tarde buscando en la documentación pública y encontramos fácilmente una docena de correos electrónicos entrantes activos en archivos README, guías de contribución y páginas de soporte. ¡Casi todos se habían publicado deliberadamente, ya que un responsable indicaba a los usuarios dónde enviar los informes de errores! Un par pertenecían a proyectos de código abierto muy populares.
Esto no es un error del usuario. Una dirección de correo electrónico es el único identificador que existe para compartirse. GitLab denomina a esto una dirección de correo electrónico, le da el formato correspondiente y ofrece un botón para copiarla. Nada en ella parece una credencial.
El modal indica que debe mantenerse privada y advierte que cualquiera que posea la dirección puede crear elementos de trabajo en su nombre. Esa advertencia describe el spam, pero no describe envíos de código (pushes) ni ejecuciones de pipelines en todos los proyectos de la cuenta.
Notificamos a las cuentas afectadas antes de la publicación. Desafortunadamente, GitLab no cuenta con ningún mecanismo para revocar estos tokens de forma masiva ni para notificar a los usuarios, por lo que nuestros esfuerzos tuvieron resultados diversos.
Quiénes están afectados
Todas las cuentas de GitLab.com y todas las instancias autogestionadas con el correo electrónico entrante habilitado. GitLab limita la documentación del correo electrónico entrante a Self-Managed y GitLab.com, por lo que GitLab Dedicated no parece estar afectado, aunque no pudimos probarlo directamente.
Ninguno de estos usuarios puede desactivar esta función. No existe ningún ajuste para inhabilitar la creación de incidencias por correo electrónico, ni para inhabilitar la creación de solicitudes de fusión (merge requests) por correo electrónico, ni ninguna forma de exigir que el remitente coincida con una dirección verificada. El token no caduca. El único control que ofrece GitLab es el enlace de restablecimiento en su página de tokens de acceso personal, y restablecerlo invalida todas las direcciones de proyectos que tenga.
Notificación a GitLab
Esto no es una "vulnerabilidad" típica. Es, en parte, el resultado de expectativas de usuario erróneas y, en dos partes, de configuraciones predeterminadas inseguras. Lo informamos a través de HackerOne en mayo de 2026, pero se cerró considerándolo comportamiento previsto (lo cual no fue una sorpresa). En junio de 2026 presentamos una incidencia confidencial en el repositorio de GitLab, la cual recibió una respuesta más detallada.
La postura de GitLab, según la entendemos, es que este es un token como cualquier otro y que cualquier token filtrado conduce a malos resultados. Eso describe cómo se comporta cualquier credencial una vez que un atacante la tiene, y es correcto. Sin embargo, evita abordar lo que hace que este caso sea diferente. GitLab creó una credencial que llega a todos los proyectos de la cuenta y elude las restricciones de IP, para luego presentarla como una dirección de correo electrónico.
En respuesta a nuestro informe, GitLab implementó una actualización con tres cambios:
- Se eliminó el texto "No se puede usar para acceder a ningún otro dato" de la interfaz de usuario.
- Se añadió "y solicitudes de fusión" donde la interfaz de usuario indicaba anteriormente que la dirección solo podía crear elementos de trabajo.
- Se documentó que el correo electrónico entrante no está sujeto a restricciones de IP.
Esta es una respuesta justa a lo que reportamos, pero las actualizaciones aún no transmiten el riesgo completo. Un usuario que lee "solicitudes de fusión" no se entera de que la dirección incluye un token que envía código, ejecuta trabajos de CI/CD y opera desde fuera de una lista blanca de IPs. Ninguno de los apartados indica que el token llegue a todos los proyectos de la cuenta.
GitLab también dejó intacto el mecanismo subyacente. La mayor reducción de la superficie de ataque sería exigir que la dirección del remitente coincida con la de la cuenta de GitLab. De este modo, un atacante necesitaría acceso a la cuenta de correo electrónico de la víctima y no solo a una dirección.
Cómo las detectamos
Añadimos cobertura adicional a Betterleaks para identificar todos los tipos de tokens de correo electrónico entrante de GitLab, incluidos:
- Tokens con el prefijo `glimt-`
- Tokens con prefijos personalizados
- Tokens creados antes de que existiera el prefijo `glimt-`
Betterleaks ahora identifica más formatos de tokens de correo electrónico entrante de GitLab que cualquier otro escáner de secretos, incluido el propio GitLab.
La detección de secretos de Aikido aplica la misma cobertura que Betterleaks en sus repositorios y solicitudes de fusión. Si aparece algún resultado, rote sus credenciales inmediatamente.
Una dirección de correo electrónico filtrada de GitLab presenta otro vector más para que los ciberdelincuentes envíen código malicioso y comprometan la cadena de suministro. Considera utilizar Safe Chain o Device Protection de Aikido para evitar que tú (o tu equipo) instaléis paquetes comprometidos por error. Safe Chain es una CLI de código abierto que integra npm, pip y otros gestores de paquetes para bloquear malware conocido antes de que se instale. Device Protection hace lo mismo para los equipos al bloquear paquetes maliciosos, registrar las instalaciones en toda la organización y aplicar políticas de aprobación. Ninguno de los dos impide que el titular de un token envíe código, pero ayudan a evitar que una dependencia maliciosa añadida a través de un commit comprometido se ejecute en la máquina de un desarrollador o en una compilación.
