resumo
O GitLab atribui-lhe um endereço de e-mail privado para criar issues. Se esse endereço for divulgado, qualquer pessoa que o possua poderá enviar código, executar tarefas de CI/CD e contornar restrições de IP em todos os seus projetos públicos e privados. Isto afeta todas as contas do GitLab.com e todos os servidores GitLab auto-hospedados que permitem aos utilizadores criar issues por e-mail.
O que é preciso verificar
Passo 1: A funcionalidade está ativada?
- GitLab.com: Sim, para todas as contas. Não é possível desativar essa funcionalidade.
- GitLab auto-hospedado: Talvez.
- Abra uma das listas de itens de trabalho do seu projeto e clique em ⋮. Se vir «Enviar o item de trabalho por e-mail para este projeto» ou algo semelhante, significa que a funcionalidade está ativada.
- GitLab Dedicated: Não.
Passo 2: Alguém já partilhou um destes endereços?
O endereço só é perigoso se estiver na posse de alguém que não seja o seu proprietário. Procure por `@incoming.gitlab.com` nos seus repositórios, documentos, centro de ajuda e wikis (os utilizadores com servidores próprios devem procurar o domínio no seu próprio endereço). Uma correspondência é perigosa se o endereço tiver um token antes de `-issue` ou `-merge-request`:
- Perigo: project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com a aproximar-se
- Safe: recebidos + group-project-12346426-issue-@incoming.gitlab.com
O Betterleaks (gratuito, de código aberto) e a funcionalidade de deteção de « secrets » do site Aikido identificam automaticamente estes endereços nos seus repositórios, incluindo formatos mais antigos.
Passo 3: Repor os endereços que foram divulgados
O proprietário de um endereço de e-mail que tenha sido alvo de uma fuga de dados deve aceder a «Definições do utilizador» > «Tokens de acesso pessoais» > «Token de e-mail recebido» e clicar em «Repor» (ligação direta para o GitLab.com). Isto altera todos os endereços de e-mail dos seus projetos de uma só vez, e os antigos deixam de funcionar.
Verifique os commits recentes, especialmente as alterações ao ficheiro .gitlab-ci.yml, e as execuções recentes do pipeline para ver se há algo que o titular do endereço de e-mail não se lembre de ter feito.
A história completa
Os projetos do GitLab têm um botão com a indicação «Enviar item de trabalho por e-mail para este projeto».
Se clicar nessa opção, o GitLab mostra-lhe um endereço de e-mail privado. Envie qualquer mensagem para esse endereço e será criada uma nova issue nesse projeto, de autoria sua.
incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
A sequência «glimt-» no meio desse endereço é uma credencial. Trata-se de um token de longa duração associado à sua conta, que nunca expira.
Além disso, faz muito mais do que apenas registar bugs. Qualquer pessoa que tenha esse endereço pode enviar código e executar tarefas de CI/CD em todos os projetos aos quais a sua conta tenha acesso.
Testámos isto num projeto privado protegido pelas restrições de IP do GitLab, configurado para aceitar ligações a partir de um único endereço que não era o nosso. O GitLab bloqueou o nosso navegador e rejeitou o comando «git clone». Aceitou o e-mail e o commit foi registado no ramo «main».
À primeira vista, parece inofensivo na interface do utilizador
A criação de tarefas por e-mail é uma funcionalidade comum dos produtos. O Trello, o Todoist e o Monday.com oferecem todos uma versão desta funcionalidade e definem-na da mesma forma. Um e-mail enviado para um endereço específico cria uma tarefa num projeto. Por isso, os utilizadores chegam ao GitLab à espera de encontrar o mesmo.
E a interface do utilizador do GitLab confirmou isso. A janela modal informava os utilizadores de que o endereço era exclusivamente seu e que adicionava itens a este projeto.
A página «Tokens de acesso pessoais» (em «Definições do utilizador») descartou todas as outras possibilidades. O GitLab indicou que o token de e-mail recebido autentica o utilizador quando este cria uma nova questão por e-mail e que «não pode ser utilizado para aceder a quaisquer outros dados».
É esse o modelo mental que fica na mente dos utilizadores do GitLab. Trata-se de um endereço de e-mail para criar issues num projeto específico, e deve ser mantido em sigilo.
Nota: Depois de ter contactado a GitLab, eles adicionaram o texto «e pedidos de fusão» a ambos os elementos da interface do utilizador.
O meu endereço de e-mail é um PAT?
O GitLab tem razão ao dizer que deve mantê-lo privado, mas está a subestimar o risco. O token contido neste endereço de e-mail é, essencialmente, um token de acesso pessoal de alto nível, que confere acesso significativo aos seus projetos no GitLab.
Acesso a toda a conta
Se abrir a opção «Enviar item de trabalho por e-mail para este projeto» em cinco projetos diferentes, o GitLab fornece-lhe cinco endereços diferentes. O token «glimt-» incorporado em cada um deles é idêntico, mesmo nos projetos privados.
A interface do utilizador apresenta o endereço como pertencente ao âmbito do projeto, mas a credencial que contém não pertence a esse âmbito. Esse token pertence à sua conta na totalidade e abrange todos os projetos aos quais tem acesso, sejam eles públicos ou privados.
O remetente não tem importância
O GitLab não verifica o remetente. Em princípio, verificar se o endereço de origem corresponde ao e-mail do titular do token acrescentaria uma camada de proteção, mas o GitLab não o faz (embora estejam agora a considerar essa possibilidade). Qualquer caixa de correio na Internet pode enviar mensagens para esse endereço, e o GitLab processa a mensagem como se fosse do titular do token. Se tiver o endereço, tem tanto a autenticação como a autorização.
Das questões ao código
Altere o sufixo «-issue» no endereço de e-mail para «-merge-request» e o GitLab irá abrir um pedido de fusão.
Por si só, isso não é grande coisa, uma vez que um atacante não pode direcionar o pedido de fusão para um fork malicioso que controle. No entanto, os e-mails de pedidos de fusão aceitam um anexo .patch do Git, e o GitLab aplica essas alterações ao ramo de código-fonte. Se o patch alterar o ficheiro .gitlab-ci.yml e a função da vítima o permitir, o GitLab executa a tarefa do atacante.
O percurso completo, do início ao fim:
- A vítima divulga ou revela o endereço de e-mail destinado a relatar problemas de um projeto.
- O atacante substitui -issue@ por -merge-request@.
- O atacante cria um patch que adiciona uma tarefa ao ficheiro .gitlab-ci.yml, sem ter conhecimento do repositório alvo.
- O atacante envia o patch por e-mail, indicando o ramo de origem na linha de assunto. O GitLab faz o push para esse ramo, caso este exista, e cria-o caso não exista.
- O GitLab executa a tarefa no projeto da vítima, na qualidade de vítima.
A execução de CI/CD é um dos resultados. O outro é um commit em qualquer ramo para o qual a vítima possa fazer um push, incluindo o ramo principal, de autoria da própria vítima. Qualquer pessoa que execute a compilação a partir desse repositório acaba por incorporar o código do atacante.
Os e-mails contornam as restrições de IP
Restringimos o acesso a um projeto privado a um único endereço IP que não era o nosso.
O GitLab bloqueou o nosso navegador e rejeitou os nossos comandos `git clone`. No entanto, continuou a aceitar um e-mail de pedido de fusão.
As equipas ativam restrições de IP, acreditando que criaram uma barreira de segurança em torno de um projeto, muitas vezes na periferia de uma VPN corporativa. Essa barreira é eficaz para o HTTP e o SSH, mas não para o correio eletrónico recebido. Um atacante que não consiga aceder ao projeto a partir da rede pode, em vez disso, aceder-lhe através do caminho do correio eletrónico.
Que tipo de informação um endereço permite obter a um atacante
A divulgação de um único endereço de e-mail pode comprometer gravemente a conta do GitLab de um utilizador ou de uma organização. Confirmámos cada uma destas vias de ataque em projetos sob o nosso controlo:
- Enviar código para um ramo protegido num repositório privado protegido por uma lista de endereços IP autorizados.
- Exfiltração de código-fonte de projetos privados protegidos por uma lista de endereços IP autorizados.
- Leitura de variáveis de CI/CD e de « secrets » de projetos privados.
- Aceder a assuntos confidenciais em projetos privados (através da ação rápida /move)
- Utilizar o CI_JOB_TOKEN disponível nas tarefas de CI/CD para aceder a mais funcionalidades da conta.
Um endereço de e-mail de entrada do GitLab contém um token que funciona como um token de acesso pessoal de alto nível, com permissões significativas.
A diferença mais importante é que, em vez de acederem ao GitLab através da API, os utilizadores têm de enviar dados por e-mail. Do ponto de vista de quem defende o sistema, se isso pode resultar no mesmo comprometimento da conta, será que importa se se trata de um pedido HTTP ou de um e-mail?
Restrições do atacante
Há dois fatores que limitam um atacante que tenha esse endereço:
1. O token herda as permissões da vítima e nada no percurso do e-mail as eleva.
As permissões da vítima limitaram os danos. Um endereço «Guest» que tenha sido divulgado é praticamente inútil. Um endereço «Maintainer» que tenha sido divulgado poderia aceder a ramos protegidos e a variáveis de CI/CD. Nada no percurso do e-mail estabelece esse limite, apenas a função da vítima.
2. O encaminhamento requer saber qual o projeto a visar.
O GitLab determina o destino a partir de dois valores contidos no endereço de e-mail de origem: o slug do caminho do projeto e o ID do projeto. Para aceder a um segundo projeto, um atacante tem de fornecer o caminho e o ID de um projeto diferente, juntamente com o token roubado. No caso dos projetos públicos, o GitLab publica ambos os valores. No caso dos projetos privados, um atacante necessita de uma fuga de informação que identifique o projeto (o ID pode ser adivinhado).
Uma dúzia, publicada de propósito
Tudo o que foi referido acima depende de um atacante conseguir obter um endereço de e-mail. Passámos uma tarde a pesquisar documentação pública e encontrámos facilmente uma dúzia de endereços de e-mail ativos em ficheiros README, guias de contribuição e páginas de apoio. Quase todos tinham sido publicados deliberadamente por um mantenedor, indicando aos utilizadores para onde enviar relatórios de erros! Alguns pertenciam a projetos de código aberto muito populares.
Isto não é um erro do utilizador. Um endereço de e-mail é o único identificador que existe para ser partilhado. O GitLab chama a isto «endereço de e-mail», apresenta-o como tal e disponibiliza um botão para o copiar. Nada nele se assemelha a uma credencial.
A janela modal indica, de facto, que se deve manter a privacidade e adverte que qualquer pessoa que tenha o endereço pode criar itens de trabalho em seu nome. Esse aviso refere-se ao spam. Não se refere a envios de código nem a execuções de pipeline em todos os projetos da conta.
Notificámos as contas afetadas antes da publicação. Infelizmente, o GitLab não dispõe de nenhum mecanismo para revogar em massa esses tokens nem para notificar os utilizadores, pelo que os nossos esforços tiveram resultados mistos.
Quem é afetado
Todas as contas do GitLab.com e todas as instâncias autogeridas com a função de receção de e-mail ativada. O GitLab limita a documentação relativa à receção de e-mail às instâncias autogeridas e ao GitLab.com, pelo que o GitLab Dedicated não parece estar afetado. Não foi possível testar isso diretamente.
Nenhum desses utilizadores pode desativar esta funcionalidade. Não existe nenhuma configuração para desativar a criação de issues por e-mail, nenhuma configuração para desativar a criação de pedidos de fusão por e-mail e nenhuma forma de exigir que o remetente utilize um endereço verificado. O token não expira. O único controlo que o GitLab lhe oferece é o link de reinicialização na sua página de tokens de acesso pessoal, e a reinicialização invalida todos os endereços de projeto que possui.
Divulgação ao GitLab
Esta não é uma «vulnerabilidade» típica. Trata-se, em parte, de expectativas dos utilizadores não correspondidas e, em grande parte, de configurações predefinidas inseguras. Comunicámos o problema através do HackerOne em maio de 2026, mas o caso foi encerrado como sendo um comportamento pretendido (o que não foi surpresa). Abrimos um ticket confidencial no repositório do GitLab em junho de 2026, e recebemos uma resposta mais detalhada.
A posição da GitLab, tal como a entendemos, é que se trata de um token como qualquer outro e que qualquer fuga de um token conduz a consequências negativas. Isso descreve o comportamento de qualquer credencial assim que um atacante a obtém, e é correto. Mas ignora o que torna esta credencial diferente. A GitLab criou uma credencial que acede a todos os projetos da conta e contorna as restrições de IP, tendo-a depois apresentado como um endereço de e-mail.
Em resposta ao nosso relatório, a GitLab lançou uma atualização com três alterações:
- Foi removida a frase «Não pode ser utilizado para aceder a quaisquer outros dados» da interface do utilizador.
- Foi adicionado «e pedidos de fusão», uma vez que a interface de utilizador indicava anteriormente que a morada só permitia criar itens de trabalho.
- Foi comprovado que o correio eletrónico recebido não está sujeito a restrições de IP.
Essa é uma resposta adequada ao que relatámos, mas as atualizações continuam a não transmitir a totalidade do risco. Um utilizador que leia «pedidos de fusão» não fica a saber que o endereço contém um token que envia código, executa tarefas de CI/CD e funciona a partir de fora de uma lista de IPs autorizados. Nada em nenhuma das duas interfaces indica que esse token chega a todos os projetos da conta.
O GitLab também não alterou o mecanismo subjacente. A maior redução na superfície de ataque consistiria em exigir que o endereço do remetente correspondesse ao da conta do GitLab. Um atacante precisaria, então, de acesso à conta de e-mail da vítima, e não apenas ao endereço.
Como é que os detetamos
Adicionámos cobertura adicional ao Betterleaks para identificar todos os tipos de tokens de e-mail recebidos pelo GitLab, incluindo:
- Tokens com o prefixo `glimt-`
- tokens com prefixo personalizado
- tokens cunhados antes de o prefixo «glimt-» existir
O Betterleaks identifica agora mais formatos de tokens de e-mail recebidos do GitLab do que qualquer outro verificador de segredos, incluindo o próprio GitLab.
AikidoA deteção do « secrets » abrange as mesmas áreas que o Betterleaks nos seus repositórios e pedidos de fusão. Se forem detetados resultados, altere as suas credenciais imediatamente.
Um endereço de e-mail do GitLab que vazou representa mais um vetor para que os autores de ameaças disseminem código malicioso e comprometam uma cadeia de abastecimento. Considere utilizar o Safe Chain ou o Device Protection do site Aikidopara evitar que você (ou a sua equipa) instale acidentalmente pacotes comprometidos. O Safe Chain é uma CLI de código aberto que envolve o npm, o pip e outros gestores de pacotes para bloquear malware conhecido antes da sua instalação. O Device Protection faz o mesmo para as equipas, bloqueando pacotes maliciosos, registando as instalações a nível da organização e aplicando políticas de aprovação. Nenhum deles impede que um detentor de um token envie código, mas ajudam a impedir que uma dependência maliciosa, adicionada através de um commit comprometido, seja executada no computador de um programador ou numa compilação.
