🛡 VULNERABILIDADES 🛡

Las direcciones de correo de GitLab pueden ser utilizadas en ataques a la cadena de suministro.

⏰24 de septiembre de 2026🛡CyberObservatorio

Idioma

◢ VULNERABILIDADES ◣

Las direcciones de correo de GitLab pueden ser utilizadas en ataques a la cadena de suministro.

⟫ 23/09/2026 ⟫ Rob Wright

Fuente: Dark Reading

### La vulnerabilidad en GitLab: Un acceso privilegiado a través de direcciones de correo electrónico

La ciberseguridad es un campo en constante evolución, donde cada día surgen nuevas amenazas que pueden comprometer la integridad de los sistemas y la información. Recientemente, un estudio publicado por Aikido Security ha puesto de manifiesto un grave problema en la plataforma de desarrollo GitLab, que puede permitir a actores maliciosos realizar ataques devastadores utilizando únicamente una dirección de correo electrónico. Esta situación no solo afecta a los usuarios de GitLab, sino que también plantea un riesgo significativo para cualquier organización que utilice esta plataforma para gestionar sus proyectos de software.

### Un acceso privilegiado a través de correos electrónicos

El estudio de Aikido Security revela que cada usuario de GitLab recibe una dirección de correo electrónico única y privada, asignada automáticamente por la plataforma. Esta dirección permite a los usuarios crear problemas (issues) en sus proyectos de software. Sin embargo, lo que muchos usuarios desconocen es que estas direcciones incluyen un token de acceso que no expira, lo que otorga privilegios amplios no solo en el proyecto específico en el que el usuario está trabajando, sino en todos los proyectos públicos y privados a los que tenga acceso. Si una de estas direcciones se expone públicamente, un atacante podría explotarla para llevar a cabo ataques de cadena de suministro, sin necesidad de acceder directamente a la cuenta del usuario.

El informe señala que "cualquier buzón de correo en Internet puede enviar un mensaje a esa dirección, y GitLab procesa el mensaje como si fuera el propietario del token". Por lo tanto, poseer la dirección de correo electrónico equivale a tener tanto la autenticación como la autorización necesarias para interactuar con los proyectos en GitLab.

### Riesgos subestimados por los usuarios

La investigación de Aikido sugiere que muchos usuarios de GitLab son probablemente ajenos a los riesgos asociados con estas direcciones, ya que se han encontrado numerosas direcciones expuestas intencionadamente en Internet. Joe Leon, investigador de Aikido, destaca que lo que comenzó como una función sencilla para crear problemas ha evolucionado a lo largo de los años para incluir la capacidad de enviar solicitudes de fusión (merge requests) y archivos de parches, todos con acceso privilegiado. Aunque estas capacidades están documentadas, Leon sostiene que los riesgos no están adecuadamente comunicados, especialmente en la interfaz de usuario de GitLab.

La interfaz de usuario de GitLab describe la dirección de correo electrónico como una herramienta para añadir elementos de trabajo, como problemas, a un proyecto específico, y afirma que "no puede usarse para acceder a ningún otro dato". Sin embargo, esto es incorrecto, según Aikido. Leon explica que "la credencial que se incrusta en la dirección puede ser reutilizada en todos los proyectos públicos y privados".

### Detalles técnicos de la vulnerabilidad

Leon encontró que las direcciones de correo electrónico contienen una cadena de prefijo llamada glimt- (GitLab Incoming Mail Token), y que el token de cada usuario es el mismo para todos los proyectos a los que tiene acceso. Si una dirección de correo electrónico de un proyecto público se expone, un atacante podría modificar el identificador del proyecto y la ruta del proyecto en el correo electrónico para acceder a otros proyectos privados. Aikido señala que, aunque los identificadores son adivinables, se requiere que se filtre un nombre de proyecto para que un atacante pueda aprovechar esta vulnerabilidad.

Además, Leon descubrió que podía eludir las restricciones de dirección IP con las direcciones de correo electrónico de GitLab. Al restringir un proyecto privado a una dirección IP aleatoria que no poseía, GitLab le impidió clonar el proyecto o acceder a él a través de un navegador web. Sin embargo, los mensajes de correo electrónico con solicitudes de fusión lograron eludir esta barrera de seguridad.

### Un panorama preocupante

Durante su investigación, Leon realizó una búsqueda no exhaustiva en Internet que duró unas pocas horas y encontró fácilmente una docena de direcciones de correo electrónico entrantes que habían sido expuestas intencionadamente en archivos de ReadMe y de soporte. Algunas de las direcciones expuestas pertenecen a proyectos de código abierto populares. Leon expresó su preocupación: "Estoy seguro de que hay muchas más por ahí. Esto fue solo la fruta al alcance de la mano".

Un aspecto alarmante de esta situación es que podría ser difícil determinar si un atacante ha abusado de una dirección de correo electrónico entrante para, por ejemplo, inyectar código malicioso en un proyecto a través de una solicitud de fusión. "No es obvio que se haya hecho a través de un correo electrónico", añade Leon. "Necesitarías acceso a los servidores de GitLab, suponiendo que recopilen estos datos".

### Respuesta de GitLab y medidas correctivas

Aikido reportó sus hallazgos a GitLab a través de HackerOne en mayo, pero GitLab cerró el informe como un comportamiento intencionado. Posteriormente, Aikido siguió en junio con un problema confidencial en el repositorio de GitLab. Al final, GitLab modificó su interfaz de usuario para reflejar que la dirección de correo electrónico puede utilizarse para solicitudes de fusión y eliminó la afirmación de que "no puede usarse para acceder a ningún otro dato". Además, actualizó su documentación para informar a los usuarios de que las direcciones de correo electrónico no están sujetas a restricciones de dirección IP.

Leon sugiere que la mejor mitigación sería exigir que la dirección del remitente coincida con la del cuenta de GitLab. Esto representaría un obstáculo significativo para los atacantes, ya que necesitarían comprometer la cuenta de correo electrónico del usuario en lugar de depender únicamente de la dirección de GitLab. "Eso elimina prácticamente la mayor parte del problema aquí", dice.

GitLab está considerando esta modificación, aunque hasta el momento no ha ofrecido ningún comentario oficial sobre el asunto.

Mientras tanto, Aikido recomienda que las organizaciones reduzcan su superficie de ataque rotando de manera proactiva los tokens de acceso en sus direcciones de correo electrónico de GitLab y escaneando estas direcciones en sus entornos de desarrollo y repositorios como si fueran otros secretos. Esta medida podría ayudar a mitigar el riesgo de explotación de estas vulnerabilidades y proteger mejor la integridad de los proyectos de software.

◢ VULNERABILIDADES ◣

GitLab Email Addresses Can Be Weaponized for Supply Chain Attacks

⟫ 23/09/2026 ⟫ Rob Wright

Source: Dark Reading

It turns out that cyber-threat actors can do quite a bit of damage with nothing more than an email address. New research from Aikido Security published today examines how a GitLab incoming email address acts as a highly privileged access token that grants broad user rights to an organization's public and private projects.GitLabautomatically assigns each user of the DevOps platform a private email address to create issues in their software projects; if a user emails the address, a new issue will appear in a project authored by that user. Creating project issues via emails sent to automated unique addresses is not an uncommon capability, Aikido noted in the report. For example, project management platforms such as Trello, Todoist, and Monday.com have similar features. But GitLab email addresses each contain a non-expiring token that provides broad access to an organization's resources — and not just the project in which an individual user is working. And if that address itself is publicly exposed, an attacker could abuse it forsupply chain attackswithout needing actual access to the account. "Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner,"the reportstated. "If you have the address, you have both authentication and authorization." Aikido's research team argues that many GitLab users are likely unaware of the risks associated with these addresses, shown by the number of intentionally exposed addresses on the public Internet. Aikido researcher Joe Leon tells Dark Reading that what started as a simple feature on GitLab for creating project issues has expanded over the years to include more functionality, such as sendingmerge requestsand patch files, with privileged access. And while the capabilities are documented, Leon says the risks are understated, especially in the GitLab user interface (UI). "It wasn't communicated clearly that there's something sensitive in there that not only can create issues but push code. And in pushing code, it can potentially push code to main [the main branch] or execute aCI/CDjob," he says. GitLab's UI describes the email address as a tool to add work items like issues to a particular project and specifically states that "It cannot be used to access any other data." But that is demonstrably false, according to Aikido. "The credential that's embedded in the address can be reused across all public and private projects," Leon says. Leon found that the email addresses contain what's called a glimt- (GitLab Incoming Mail Token) prefix string, and that each user's token string is the same for all public and private projects to which they have access. If an email address for a public project is exposed, an attacker could modify the project path slug and the project ID in the email to reach other private projects (Aikido's report noted that IDs are guessable but an attacker would need a project name to be leaked). "They present it as an email address to create an issue in a particular project. And if you're working on a public project, you can distribute it; that makes sense," Leon says. "But I didn't realize that [with] the credential, with just adjusting the email address, anybody could push code to my private projects too. That blew my mind." Additionally, Leon found that he could bypass IP address restrictions with GitLab email addresses. He restricted a private project to a single, random IP address that he didn't own. GitLab's restriction prevented him from cloning the project or accessing it via a Web browser — but email messages with merge requests broke through that security boundary. As part of the research project, Leon conducted a "a very non-exhaustive search" on the Internet that spanned a couple of hours, during which he easily found a dozen incoming email addresses that had been exposed intentionally in ReadMe and support files. A few of the exposed addresses belong to popular open source projects, Leon says. "I'm sure there are many more out there," he says. "This was the low-hanging fruit." Leon also says it could be difficult to determine if an attacker had abused an incoming email address to, for example,poison a projectwith malicious code via a merge request. "It's not obvious that it was done via email," he adds. "You'd need access to GitLab's servers, assuming they collect this data." Aikido reported its findings to GitLab throughHackerOnein May, though GitLab closed the report as intended behavior. The cybersecurity vendor then followed up in June with a confidential issue on the GitLab repository. GitLab eventually changed its UI to reflect that the email address can be used for merge requests and removed the statement "It cannot be used to access any other data." GitLab also updated its documentation to inform users that the email addresses are not subject to IP address restrictions. Leon says the best mitigation he'd like to see is a requirement that the sender address matches the one on the GitLab account; this would create a significant hurdle for attacks, as threat actors would need to compromise the user's email account rather than just relying on the GitLab address. "That basically removes the vast majority of the problem here," he says. Leon says GitLab is considering this change. Dark Reading contacted GitLab for comment, but the company did not respond at press time. In the meantime, Aikido recommended that organizations reduce their attack surfaces by preemptively rotating the access tokens in their GitLab email addresses, and scanning for these addresses in their development environments and repositories like anyother secrets.

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD