En resumen
GitLab te proporciona una dirección de correo electrónico privada para crear incidencias. Si se filtra, cualquier persona que la tenga podrá enviar código, ejecutar tareas de CI/CD y eludir las restricciones de IP en todos tus proyectos, tanto públicos como privados. Esto afecta a todas las cuentas de GitLab.com y a los servidores GitLab autohospedados que permiten a los usuarios crear incidencias por correo electrónico.
Lo que debes comprobar
Paso 1: ¿Está activada la función?
- GitLab.com: Sí, para todas las cuentas. No se puede desactivar.
- GitLab autohospedado: Quizás.
- Abre la lista de elementos de trabajo de uno de tus proyectos y haz clic en ⋮. Si ves «Enviar por correo electrónico un elemento de trabajo a este proyecto» o algo similar, significa que la función está activada.
- GitLab Dedicated: No.
Paso 2: ¿Alguien ha compartido alguna de estas direcciones?
La dirección solo es peligrosa si la tiene alguien que no sea su propietario. Busca `@incoming.gitlab.com` en tus repositorios, documentación, centro de ayuda y wikis (los usuarios con servidores propios 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`:
- Peligro: se aproxima un project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
- Bandeja de entrada: group-project-12346426-issue-@incoming.gitlab.com
Betterleaks (gratuito, de código abierto) y « detección de secretos » de Aikido detectan automáticamente estas direcciones en tus repositorios, incluidos los formatos más antiguos.
Paso 3: Restablecer las direcciones filtradas
El propietario de una dirección de correo electrónico que se haya filtrado debe ir a «Configuración de usuario» > «Tokens de acceso personales» > «Token de correo electrónico entrante» y hacer clic en «Restablecer» (enlace directo para GitLab.com). De este modo, se modificarán todas sus direcciones de correo electrónico de los proyectos a la vez y las antiguas dejarán de funcionar.
Revisa las últimas confirmaciones, sobre todo los cambios en el archivo .gitlab-ci.yml, y las últimas ejecuciones del pipeline para ver si hay algo que el titular de la dirección de correo electrónico no recuerde haber hecho.
La historia completa
Los proyectos de GitLab tienen un botón que dice «Enviar por correo electrónico el elemento de trabajo 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 sustituye -issue@ por -merge-request@.
- El atacante escribe un parche que añade una tarea al archivo .gitlab-ci.yml, sin conocer el repositorio de destino.
- El atacante envía el parche por correo electrónico, indicando la rama de origen en el asunto del mensaje. GitLab realiza un «push» a esa rama si existe y la crea si no existe.
- GitLab ejecuta la tarea en el proyecto de la víctima, en nombre de esta.
La ejecución de CI/CD es uno de los resultados. El otro es una confirmación en cualquier rama a la que la víctima pueda enviar cambios, incluida la rama principal, creada por ella misma. Cualquiera que compile a partir de ese repositorio incorporará el código del atacante.
Los correos electrónicos eluden las restricciones de IP
Restringimos el acceso a un proyecto privado a una única dirección IP que no era la nuestra.
GitLab bloqueó nuestro navegador y rechazó nuestros comandos «git clone». Sin embargo, sí aceptó un correo electrónico de solicitud de fusión.
Los equipos activan restricciones de IP creyendo que han establecido un perímetro de seguridad alrededor de un proyecto, a menudo en el límite de la VPN corporativa. Este perímetro es válido para HTTP y SSH, pero no para el correo electrónico entrante. Un atacante que no pueda acceder al proyecto desde la red puede hacerlo a través del canal de correo electrónico.
¿Qué información obtiene un atacante con una sola dirección?
La filtración de una sola dirección de correo electrónico puede poner en grave peligro la cuenta de GitLab de un usuario o una organización. Hemos comprobado cada una de estas vías de ataque en proyectos que controlamos:
- Subir código a una rama protegida en un repositorio privado protegido por una lista de direcciones IP autorizadas.
- Exfiltración de código fuente de proyectos privados protegidos por una lista de direcciones IP autorizadas.
- Lectura de variables y secretos de CI/CD de proyectos privados.
- Acceder a temas confidenciales en proyectos privados (mediante la acción rápida /move)
- Utilizar el CI_JOB_TOKEN disponible en los trabajos de CI/CD para acceder a más funciones de la cuenta.
Una dirección de correo electrónico de entrada de GitLab contiene un token que actúa como un token de acceso personal de alto nivel con permisos significativos.
La diferencia más importante es que, en lugar de acceder a GitLab a través de la API, los usuarios deben enviar los datos por correo electrónico. Desde el punto de vista de un defensor, si el resultado es el mismo —la vulneración de la cuenta—, ¿importa si se trata de una solicitud HTTP o de un correo electrónico?
Restricciones del atacante
Hay dos factores que limitan a un atacante que disponga de la dirección:
1. El token hereda los permisos de la víctima, y nada en la ruta del correo electrónico los amplía.
Los permisos de la víctima limitaron el alcance del daño. Una dirección de «Guest» filtrada no tiene prácticamente ningún valor. Una dirección de «Maintainer» filtrada podría acceder a ramas protegidas y a variables de CI/CD. No hay nada en la ruta del correo que establezca ese límite, solo el rol de la víctima.
2. Para realizar el enrutamiento es necesario saber a qué proyecto debe dirigirse.
GitLab determina el destino a partir de dos valores que figuran en la dirección de correo electrónico de entrada: el slug de la ruta del proyecto y el ID del proyecto. Para acceder a un segundo proyecto, un atacante debe proporcionar la ruta y el ID de otro proyecto, además del token robado. En el caso de los proyectos públicos, GitLab publica ambos valores. En el caso de los proyectos privados, el atacante necesita una filtración de información en la que se mencione el nombre del 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. Dedicamos una tarde a buscar en documentación pública y encontramos fácilmente una docena de direcciones de correo electrónico activas en archivos README, guías para colaboradores y páginas de asistencia. ¡Casi todas ellas habían sido publicadas deliberadamente por un responsable del proyecto para indicar a los usuarios dónde enviar los informes de errores! Algunas pertenecían a proyectos de código abierto muy populares.
No se trata de un error del usuario. Una dirección de correo electrónico es el único identificador que está pensado para ser compartido. GitLab la denomina «dirección de correo electrónico», la presenta con ese formato y te ofrece un botón para copiarla. No hay nada en ella que se parezca a una credencial.
La ventana emergente indica que hay que mantenerla privada y advierte de que cualquier persona que tenga la dirección puede crear elementos de trabajo en tu nombre. Esa advertencia se refiere al spam. No se refiere a las subidas de código ni a las ejecuciones de pipeline en todos los proyectos de la cuenta.
Notificamos a las cuentas afectadas antes de publicar la información. Lamentablemente, GitLab no dispone de ningún mecanismo para revocar de forma masiva estos tokens ni para notificarlo a los usuarios, por lo que nuestros esfuerzos tuvieron resultados dispares.
¿A quién afecta?
Todas las cuentas de GitLab.com y todas las instancias autogestionadas con el correo electrónico entrante activado. GitLab limita el alcance de la documentación sobre el correo electrónico entrante a las instancias autogestionadas y a GitLab.com, por lo que GitLab Dedicated no parece verse afectado. No hemos podido comprobarlo directamente.
Ninguno de esos usuarios puede desactivar esta función. No hay ninguna opción para desactivar la creación de incidencias por correo electrónico, ni para desactivar la creación de solicitudes de fusión por correo electrónico, ni ninguna forma de exigir que el remitente utilice una dirección verificada. El token no caduca. El único control que te ofrece GitLab es el enlace de restablecimiento que aparece en tu página de tokens de acceso personales, y al restablecerlo se invalidan todas las direcciones de proyectos que tengas.
Divulgación a GitLab
No se trata de una «vulnerabilidad» típica. Se debe, en parte, a unas expectativas de los usuarios mal gestionadas y, en mayor medida, a unos ajustes predeterminados poco seguros. Lo notificamos a través de HackerOne en mayo de 2026, pero se archivó como «comportamiento previsto» (lo cual no fue ninguna sorpresa). En junio de 2026, abrimos un incidencia confidencial en el repositorio de GitLab y recibimos una respuesta más detallada.
La postura de GitLab, tal y como la entendemos, es que se trata de un token como cualquier otro, y que cualquier token filtrado tiene consecuencias negativas. Eso describe cómo se comporta cualquier credencial una vez que cae en manos de un atacante, y es cierto. Pero pasa por alto lo que hace que esta sea diferente. GitLab creó una credencial que da acceso a todos los proyectos de la cuenta y elude las restricciones de IP, y luego la presentó como una dirección de correo electrónico.
En respuesta a nuestro informe, GitLab lanzó una actualización con tres cambios:
- Se ha eliminado de la interfaz de usuario la frase «No se puede utilizar para acceder a ningún otro dato».
- Se ha añadido «y solicitudes de fusión», ya que anteriormente la interfaz de usuario indicaba que la dirección solo podía crear elementos de trabajo.
- Se ha comprobado que el correo electrónico entrante no está sujeto a restricciones de IP.
Esa es una respuesta razonable a lo que hemos informado, pero las actualizaciones siguen sin reflejar todo el riesgo. Un usuario que lea «solicitudes de fusión» no se da cuenta de que la dirección contiene un token que envía código, ejecuta tareas de CI/CD y opera desde fuera de una lista de direcciones IP autorizadas. En ninguna de las dos interfaces se indica que ese token llega a todos los proyectos de la cuenta.
GitLab tampoco modificó el mecanismo subyacente. La medida más eficaz para reducir la superficie de ataque sería exigir que la dirección del remitente coincidiera con la de la cuenta de GitLab. De este modo, un atacante necesitaría tener acceso a la cuenta de correo electrónico de la víctima, y no solo a su dirección.
Cómo los detectamos
Hemos ampliado la cobertura de Betterleaks para identificar todos los tipos de tokens de correo electrónico entrante de GitLab, entre los que se incluyen:
- Tokens con el prefijo «glimt-»
- tokens con prefijo personalizado
- tokens acuñados antes de que existiera el prefijo «glimt-»
Betterleaks identifica ahora más formatos de tokens de correo electrónico entrante de GitLab que cualquier otro escáner de secretos, incluido el propio GitLab.
detección de secretos, de Aikido, ofrece la misma cobertura que Betterleaks en todos tus repositorios y solicitudes de fusión. Si aparece algún resultado, cambia tus credenciales inmediatamente.
La filtración de una dirección de correo electrónico de GitLab supone un vector más que los atacantes pueden aprovechar para propagar código malicioso y comprometer una cadena de suministro. Plantéate utilizar Safe Chain o Device Protection de Aikido para evitar que tú (o tu equipo) instaléis accidentalmente paquetes comprometidos. Safe Chain es una CLI de código abierto que envuelve npm, pip y otros gestores de paquetes para bloquear el malware conocido antes de que se instale. Device Protection hace lo mismo para los equipos bloqueando paquetes maliciosos, registrando las instalaciones en toda la organización y aplicando políticas de aprobación. Ninguna de las dos soluciones impide que un titular de un token publique código, pero ayudan a evitar que una dependencia maliciosa añadida a través de una confirmación comprometida se ejecute en el equipo de un desarrollador o en una compilación.
