O endereço de e-mail privado que o GitLab fornece para abrir issues por e-mail é uma credencial. Quem obtiver esse endereço pode enviar um patch que o GitLab aplicará em seu nome, em qualquer branch para a qual você tenha permissão de push, inclusive a main, além de acionar jobs de CI/CD executados como se fossem seus.
O GitLab exibe esse endereço para cada usuário por meio de um botão com a etiqueta “Email work item to this project”. A mensagem enviada para ele abre uma issue naquele projeto, assinada por você.
A sequência no meio do endereço é um token vinculado à sua conta, e a documentação do GitLab afirma que ele não expira.
À primeira vista, o endereço parece pertencer a um único projeto. Mas não é isso que acontece. A Aikido Security, que relatou o comportamento, constatou que os endereços criados pelo GitLab para os diferentes projetos de um usuário compartilham o mesmo token, e que esse token vale para todos os projetos aos quais a conta pode ter acesso, públicos ou privados.
O GitLab não verifica quem enviou o e-mail. Qualquer caixa de entrada pode escrever para esse endereço, e o GitLab trata a mensagem como se tivesse sido enviada por você. Quem estiver com o endereço em mãos pode tanto entrar como você quanto agir com suas permissões, sem jamais tocar na sua caixa de entrada.
Esse endereço faz mais do que abrir bugs. A Aikido mostrou como alguém que o possui pode transformá-lo em uma forma de enviar código, usando o recurso do próprio GitLab de merge request por e-mail:
- Altere o sufixo do endereço de -issue para -merge-request. O GitLab então abre um merge request em vez de uma issue.
- Escreva um patch e coloque o nome de uma branch de destino no assunto do e-mail.
- Anexe o patch e envie. O GitLab aplica a alteração nessa branch e cria a branch se ela ainda não existir.
- A mudança entra como um commit nessa branch, atribuída a você. Se for uma branch para a qual você pode fazer push, isso inclui a main.
- Se o patch alterar o arquivo .gitlab-ci.yml do projeto e sua função permitir isso, o GitLab executa o job do atacante como se fosse você.
O merge request em si não pode ser direcionado para uma cópia do projeto controlada pelo atacante, e é por isso que o código viaja no patch anexado, não no merge request.
Dois fatores impedem que isso seja ainda pior. O token carrega apenas as suas próprias permissões, então o alcance do ataque depende da sua função. Um endereço vazado de uma conta Guest é quase inútil, enquanto um de Maintainer pode acessar branches protegidas e segredos de CI/CD.
Chegar a um projeto também exige mais do que o endereço. O GitLab identifica o destino com base no caminho do projeto e no ID numérico, então um atacante que queira atingir um projeto específico precisa do caminho e do ID, além do token. Projetos públicos divulgam ambos. Já um projeto privado exige outro vazamento que revele sua existência, embora os IDs de projeto do GitLab sejam fáceis de adivinhar.
Como o e-mail de entrada é isento de restrições de IP, o ataque pode partir de fora de uma lista de IPs permitidos. A documentação do GitLab informa que o e-mail de entrada não está sujeito a restrições de IP.
A Aikido bloqueou um projeto privado para um único endereço de IP que não era o dela. O GitLab bloqueou o acesso pelo navegador e recusou um git clone, mas aceitou o e-mail de merge request, e o commit foi parar na main.
O mesmo caminho também contorna a autenticação de dois fatores. A documentação do GitLab observa que os recursos de e-mail de entrada funcionam sem 2FA, mesmo em instâncias que exigem esse mecanismo.
Toda conta do GitLab.com possui um desses tokens, assim como toda instância self-managed do GitLab com e-mail de entrada ativado, que é a configuração padrão no GitLab.com.
O GitLab Dedicated aparentemente não é afetado, porque a empresa limita o recurso a self-managed e GitLab.com, mas a Aikido disse que não conseguiu testar o Dedicated diretamente.
O que fazer
Não é possível impedir que outras pessoas tenham o recurso, mas é possível inutilizar um endereço vazado.
- Redefina seu token de e-mail de entrada na página de tokens de acesso pessoal do seu perfil. A redefinição substitui todos os endereços de projeto de uma vez, então um endereço que você esteja usando deixará de funcionar até que você distribua o novo.
- Revise seus próprios READMEs, guias de contribuição e páginas de suporte em busca de um endereço publicado. A Aikido disse ter encontrado cerca de uma dúzia de endereços ativos dessa forma, a maioria divulgada de propósito como canal para envio de bugs, e alguns em projetos open source bastante usados.
- Em uma instância self-managed, um administrador pode desativar o e-mail de entrada para toda a instância. Não existe uma configuração que permita a um usuário individual desativar a criação de issues ou merge requests por e-mail.
Depois do relatório da Aikido, o GitLab alterou o texto em torno do token. A descrição agora informa que o endereço pode criar issues e merge requests, enquanto antes mencionava apenas itens de trabalho, e o GitLab removeu uma linha que dizia que o token não podia ser usado para acessar nenhum outro dado.
O comportamento não mudou. O token continua sem expiração, o GitLab continua sem verificar quem enviou o e-mail e ainda não existe uma opção para que um usuário individual desative o recurso.
O GitLab abriu uma issue para avaliar a possibilidade de aceitar esses e-mails apenas de um endereço verificado na conta do proprietário, mas isso ainda está em análise, não em vigor.
A Aikido informou que relatou o comportamento pela HackerOne em maio de 2026, onde o caso foi encerrado como comportamento esperado, e depois abriu uma issue confidencial com o GitLab em junho. A posição do GitLab, segundo a Aikido, é que esse é um token como qualquer outro e que qualquer credencial vazada pode levar a resultados ruins.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...