La dirección de correo privada de GitLab para reportar incidencias funciona como una credencial permanente que permite a cualquiera suplantar al usuario. Un atacante puede usarla para enviar parches de código, realizar commits en ramas protegidas y ejecutar trabajos de CI/CD, saltándose el 2FA y restricciones de IP. Para mitigarlo, se recomienda restablecer el token de correo electrónico en el perfil de usuario o desactivar la función a nivel de instancia.





 La dirección de correo electrónico privada que GitLab te da para informar de problemas por email es una credencial. Cualquiera que la obtenga puede enviar un parche que GitLab confirmará en tu nombre, en cualquier rama en la que puedas hacer push, incluida la principal (main), y puede iniciar trabajos de CI/CD que se ejecuten como tú.

GitLab muestra a cada usuario esta dirección detrás de un botón etiquetado como "Enviar elemento de trabajo a este proyecto". El correo enviado a ella abre un problema en ese proyecto, creado por ti.

La cadena en medio de la dirección es un token vinculado a tu cuenta, y la documentación de GitLab dice que no caduca.

La dirección parece pertenecer a un solo proyecto. No es así. Aikido Security Aikido Security, que informó sobre este comportamiento, descubrió que las direcciones que GitLab crea para los diferentes proyectos de un usuario comparten el mismo token, y que el token se aplica a cada proyecto que la cuenta puede abrir, ya sea público o privado.

GitLab no comprueba quién envió el correo electrónico. Cualquier buzón puede escribir a la dirección, y GitLab actúa sobre el mensaje como si viniera de ti. Quien posea la dirección puede tanto iniciar sesión como tú como actuar con tus permisos, sin tocar nunca tu buzón. La dirección hace más que informar de errores. Aikido mostró cómo quien la posea puede convertirla en una forma de confirmar código, utilizando la propia función de GitLab de solicitud de fusión (merge request) por correo electrónico función de GitLab:

1. Cambia el sufijo de la dirección de -issue a -merge-request. Entonces GitLab abre una solicitud de fusión en lugar de un problema.
2. Escribe un parche y pon el nombre de una rama de destino en la línea del asunto del correo electrónico.
3. Adjunta el parche y envíalo. GitLab aplica el parche a esa rama y crea la rama si aún no existe.
4. El cambio queda registrado como un commit en esa rama, creado por ti. Si es una rama en la que puedes hacer push, esto incluye la rama main.
5. Si el parche edita el archivo .gitlab-ci.yml del proyecto y tu rol lo permite, GitLab ejecuta el trabajo del atacante como si fueras tú.

La solicitud de fusión en sí no puede dirigirse a una copia del proyecto que controle el atacante, por eso el parche adjunto, y no la solicitud de fusión, es el que lleva el código.

Dos cosas evitan que esto sea peor. El token conlleva solo tus propios permisos, por lo que hasta dónde llegue un atacante depende de tu rol. Una dirección filtrada de una cuenta de Invitado es casi inútil, mientras que una de Mantenedor puede acceder a ramas protegidas y secretos de CI/CD. Llegar a un proyecto también requiere más que la dirección. GitLab deduce el objetivo a partir de la ruta del proyecto y su ID numérico, por lo que un atacante que quiera un proyecto concreto necesita la ruta y el ID de ese proyecto, además del token. Los proyectos públicos publican ambos. Un proyecto privado requiere una filtración separada que lo nombre, aunque los IDs de proyecto de GitLab son fáciles de adivinar.

Debido a que el correo electrónico entrante está exento de restricciones de IP, el ataque puede originarse fuera de una lista blanca de IP. La documentación de GitLab establece que el correo electrónico entrante no está sujeto a restricciones de IP documentación de GitLab.

Aikido bloqueó un proyecto privado a una sola dirección IP que no era la suya. GitLab bloqueó su navegador y rechazó un git clone, pero aceptó el correo electrónico de la solicitud de fusión y el commit llegó a main.

La misma ruta se salta la autenticación de dos factores. La documentación de GitLab señala que las funciones de correo electrónico entrante funcionan sin 2FA documentación de GitLab, incluso en instancias que lo requieran. Cada cuenta de GitLab.com tiene uno de estos tokens, al igual que cada instancia de GitLab autogestionada con el correo electrónico entrante activado, que es el valor predeterminado en GitLab.com.

GitLab Dedicated no parece estar afectado, ya que GitLab limita la función a las instancias autogestionadas y a GitLab.com, pero Aikido dijo que no pudo probar Dedicated directamente.

Qué hacer

No puedes evitar que otras personas tengan la función, pero puedes anular una dirección filtrada.

* Restablece tu token de correo electrónico entrante desde la página de tokens de acceso personal página de tokens en tu perfil. El restablecimiento reemplaza todas las direcciones de los proyectos a la vez, por lo que una dirección que estés usando activamente dejará de funcionar hasta que entregues la nueva.
* Revisa tus propios archivos README, guías de contribución y páginas de soporte en busca de alguna dirección publicada. Aikido dijo que encontró alrededor de una docena de direcciones activas de esta manera, la mayoría de ellas publicadas a propósito como lugares para enviar informes de errores, y algunas en proyectos de código abierto ampliamente utilizados.
* En una instancia autogestionada, un administrador puede desactivar el correo electrónico entrante para toda la instancia. No hay un ajuste que permita a un usuario individual desactivar la creación de problemas o solicitudes de fusión basadas en correo electrónico.

GitLab cambió el texto relacionado con el token después del informe de Aikido. La descripción ahora dice que la dirección puede crear problemas y solicitudes de fusión, mientras que antes solo enumeraba elementos de trabajo, y GitLab eliminó una línea que afirmaba que el token no podía usarse para acceder a ningún otro dato. El comportamiento no ha cambiado. El token sigue sin caducar, GitLab sigue sin comprobar quién envió el correo electrónico y todavía no hay un interruptor para que un usuario individual desactive la función.

GitLab ha abierto un problema problema en GitLab para estudiar la posibilidad de aceptar estos correos electrónicos solo desde una dirección verificada en el propietario de la cuenta, pero eso está bajo consideración, no implementado.

Aikido dijo que informó primero sobre este comportamiento a través de HackerOne en mayo de 2026, donde fue cerrado como un comportamiento previsto, y luego presentó un problema confidencial a GitLab en junio. La posición de GitLab, según describió Aikido, es que este es un token como cualquier otro, y que cualquier credencial filtrada conduce a resultados negativos.

The Hacker News se ha puesto en contacto con GitLab y Aikido para obtener comentarios.

Fuente:
THN