O recurso de email para criar issues no GitLab contém um token de acesso pessoal de longa duração embutido — e qualquer pessoa que descubra o endereço consegue executar código, fazer push em repositórios e contornar restrições de IP. A empresa trata o recurso como designado, não como falha, mas a realidade é que o token permanece ativo em todos os projetos da conta, não apenas no projeto que gerou o endereço.
A Aikido Security descobriu que o endereço de email fornecido pelo GitLab (formato incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com) funciona como uma credencial de conta inteira, não como um simples endpoint de comunicação. Isso significa risco real para qualquer organização que deixar esses endereços vazarem em repositórios públicos, documentação ou logs.
O problema real do token GitLab
O token prefixado com “glimt-” é idêntico em todos os endereços gerados para uma mesma conta. Enquanto a interface do GitLab avisa para manter o token em segredo e afirma que ele “não pode acessar outros dados”, a prática mostra o oposto: o mesmo token funciona em todos os projetos da conta, públicos ou privados.
Qualquer pessoa com acesso ao endereço de email consegue:
- Criar issues e merge requests
- Fazer push de código para branches
- Executar jobs de CI/CD
- Contornar restrições de IP configuradas na conta
- Agir com as mesmas permissões do usuário legítimo
A mudança de um sufixo no token permite passar por diferentes tipos de ação. Isso não é um detalhe menor — é a abertura para injetar código malicioso direto no pipeline de integração contínua de um projeto.
Por que as restrições de IP não funcionam
GitLab oferece um recurso de restrição por IP para aumentar a segurança das contas. No entanto, essas regras não se aplicam a emails. A Aikido testou exatamente isso: o navegador foi bloqueado, um git clone foi rejeitado, mas o commit enviado por email atravessou e pousou na branch principal.
Esse comportamento é intencional segundo a empresa. GitLab não o classifica como vulnerabilidade. A Aikido discorda, apontando que o GitLab criou uma credencial que contorna as próprias medidas de segurança que o usuário configurou — uma contradição clara em qualquer estratégia de defesa.
Vazamento é questão de tempo
Joseph Leon, pesquisador de segurança na Aikido, encontrou aproximadamente uma dúzia de endereços de email expostos em poucas horas de busca. Entre eles havia projetos open source populares, como o wget2. Projetos públicos naturalmente listam caminhos e IDs de forma visível. Projetos privados são mais difíceis de explorar, mas seus IDs podem ser adivinhados.
Uma vez que alguém publica o endereço em um README, o coloca em um script de automação ou o deixa em um log acessível, qualquer pessoa com esse endereço vira um ator malicioso em potencial dentro da sua organização GitLab.
O que Leon recomenda
A solução passaria por simples validação: exigir que o endereço de email remetente corresponda ao email registrado da conta GitLab. Isso bloquearia a maioria dos ataques sem prejudicar a funcionalidade legítima do recurso.
Até que (e se) isso acontecer, as recomendações são:
- Procure por esses endereços em repositórios, documentação e wikis
- Se suspeitar de exposição, resete imediatamente o token de email
- Trate esses endereços como credenciais, não como endpoints normais
- Limite quem tem acesso a canais onde esses endereços possam aparecer
- Considere desabilitar o recurso se sua organização não o usa
No como o PratiqueTech já orientou em outras análises, tokens de longa duração embutidos em qualquer comunicação externa são um padrão de segurança fraco. Quanto mais tempo um token vive, maior a janela para descoberta e exploração.
GitLab reconhece, mas não muda
A empresa atualizou a descrição da interface para mencionar que o token permite criar issues “e merge requests”, reconhecendo que o recurso vai além do que prometia. Mas não mudou a mecânica de funcionamento.
O impacto de um vazamento depende das permissões da conta comprometida. Se o usuário consegue fazer push para a branch principal ou executar pipelines de CI/CD, o dano pode ser severo — injeção de código direto em produção, roubo de variáveis de ambiente, modificação de artefatos de build.
Para mitigar, mantenha esses endereços tão secretos quanto senhas. Resete-os regularmente. E se seu fluxo de trabalho não depende deles, considere simplesmente não gerar esses tokens.
Se você trabalha com integração de sistemas GitLab e precisa validar URLs, IPs ou dados estruturados em suas automações, use o validador de JSON para garantir que seus scripts e webhooks estão formatados corretamente antes de disparar credenciais por email.
