resumo
O GitLab fornece um endereço de email privado para criar problemas. Se for divulgado, qualquer pessoa que o tenha pode enviar código, executar tarefas CI/CD e ignorar restrições de IP em todos os seus projetos públicos e privados. Isto afeta todas as contas do GitLab.com e servidores GitLab auto-hospedados que permitem aos utilizadores criar problemas por email.
O que precisa de verificar
Passo 1: A funcionalidade está ativada?
- GitLab.com: Sim, para todas as contas. Não pode desativá-la.
- GitLab auto-hospedado: Talvez.
- Abra uma das listas de itens de trabalho do seu projeto e clique em ⋮. Se vir "Enviar item de trabalho por email para este projeto" ou algo semelhante, está ativado.
- GitLab Dedicated: Não.
Passo 2: Alguém partilhou um destes endereços?
O endereço só é perigoso se alguém que não seja o seu proprietário o tiver. Procure nos seus repositórios, documentos, centro de ajuda e wikis por `@incoming.gitlab.com` (os utilizadores auto-hospedados devem procurar pelo domínio no seu próprio endereço). Uma ocorrência é perigosa se o endereço tiver um token antes de `-issue` ou `-merge-request`:
- Perigoso: incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
- Seguro: incoming+group-project-12346426-issue-@incoming.gitlab.com
O Betterleaks (gratuito, de código aberto) e a detecção de segredos do Aikido encontram estes endereços nos seus repositórios automaticamente, incluindo formatos mais antigos.
Passo 3: Redefinir endereços divulgados
O proprietário de um endereço de email divulgado deve aceder a User settings > Personal access tokens > Incoming email token e clicar em redefinir (link direto para o GitLab.com). Isto altera todos os endereços de email dos seus projetos de uma só vez e os antigos deixam de funcionar.
Verifique os commits recentes, especialmente as alterações a .gitlab-ci.yml, e as execuções recentes de pipelines para detetar qualquer atividade de que o proprietário do endereço de email não se lembre.
A história completa
Os projetos no GitLab têm um botão com a etiqueta "Enviar item de trabalho por e-mail para este projeto".
Se clicar nele, o GitLab mostra-lhe um endereço de e-mail privado. Envie qualquer e-mail para esse endereço e aparecerá uma nova issue nesse projeto, criada por si.
incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
A string glimt- no meio desse endereço é uma credencial. É um token de longa duração associado à sua conta e nunca expira.
Também faz consideravelmente mais do que registar bugs. Qualquer pessoa na posse desse endereço pode enviar código e executar tarefas de CI/CD em todos os projetos a que a sua conta tenha acesso.
Testámos isto contra um projeto privado protegido pelas restrições de IP do GitLab, configurado para aceitar ligações apenas a partir de um endereço específico que não era o nosso. O GitLab bloqueou o nosso browser e rejeitou o git clone. No entanto, aceitou o e-mail e o commit foi integrado na branch main.
Inofensivo no papel na UI
Criar issues por e-mail é uma funcionalidade comum. Trello, Todoist e Monday.com incluem uma versão da mesma e todas a limitam da mesma forma. O e-mail enviado para um endereço único cria uma unidade de trabalho num projeto. Assim, os utilizadores chegam ao GitLab à espera do mesmo.
E a UI do GitLab confirmou isso. A janela modal indicava aos utilizadores que o endereço pertence apenas a si e que adiciona itens a este projeto.
A página de Personal access tokens (em `User settings`) descartava qualquer outra hipótese. O GitLab afirmava que o token de e-mail de entrada o autentica quando cria uma nova issue por e-mail e que "não pode ser utilizado para aceder a quaisquer outros dados".
Este é o modelo mental com que os utilizadores do GitLab ficam. É um endereço de e-mail para criar issues num projeto específico e deve ser mantido privado.
Nota: Após eu contactar o GitLab, estes adicionaram o texto "and merge requests" a ambos os elementos da UI.
O meu endereço de e-mail é um PAT?
O GitLab tem razão ao afirmar que o deve manter privado, mas estão a desvalorizar o risco. O token contido neste endereço de e-mail é essencialmente um personal access token granular com acesso significativo aos seus projetos no GitLab.
Acesso a toda a conta
Abra "Enviar item de trabalho por e-mail para este projeto" em cinco projetos diferentes e o GitLab fornece-lhe cinco endereços diferentes. O token glimt- incorporado em cada um é idêntico, mesmo em projetos privados.
A interface apresenta o endereço como sendo limitado ao projeto, mas a credencial no seu interior não é. Esse token pertence a toda a sua conta e acede a todos os projetos a que tem acesso, sejam públicos ou privados.
O remetente não importa
O GitLab não verifica o remetente. Em princípio, verificar se o endereço de envio corresponde ao e-mail do proprietário do token adicionaria uma camada de defesa, mas o GitLab não faz isto (embora estejam agora a ponderá-lo). Qualquer caixa de correio na internet pode enviar para esse endereço e o GitLab processa a mensagem como sendo do proprietário do token. Se tiver o endereço, tem tanto a autenticação como a autorização.
De issues para código
Altere o sufixo -issue no endereço de e-mail para -merge-request, e o GitLab abrirá um merge request.
Isso por si só não é muito, uma vez que um atacante não consegue direcionar o merge request para uma bifurcação maliciosa que controle. No entanto, os e-mails de merge request aceitam um anexo git .patch, e o GitLab aplica essas alterações à branch de origem. Se o patch afetar o ficheiro .gitlab-ci.yml e a função da vítima o permitir, o GitLab executa a tarefa do atacante.
O caminho completo, do início ao fim:
- A vítima publica ou expõe o endereço de issue-por-e-mail de um projeto.
- O atacante substitui -issue@ por -merge-request@.
- O atacante escreve um patch que adiciona uma tarefa ao .gitlab-ci.yml, sem qualquer conhecimento do repositório de destino.
- O atacante envia o patch por e-mail, indicando o nome da branch de origem na linha de assunto. O GitLab faz o push para essa branch se ela existir e cria-a se não existir.
- O GitLab executa a tarefa no projeto da vítima, como se fosse a vítima.
A execução de CI/CD é um dos resultados. O outro é um commit em qualquer branch para a qual a vítima possa fazer push, incluindo a main, criada por ela. Qualquer pessoa que compile a partir desse repositório obtém o código do atacante.
Os e-mails contornam as restrições de IP
Restringimos 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 merge request.
As equipas ativam restrições de IP acreditando que definiram um perímetro de segurança em torno de um projeto, frequentemente na borda de uma VPN corporativa. O perímetro funciona para HTTP e SSH, mas não para e-mails recebidos. Um atacante que não consiga aceder ao projeto a partir da rede pode aceder-lhe através do canal de correio eletrónico.
O que um único endereço proporciona a um atacante
Um único endereço de e-mail divulgado pode comprometer seriamente a conta GitLab de um utilizador ou organização. Confirmámos cada um destes vetores de ataque em projetos sob o nosso controlo:
- Fazer push de código para uma branch protegida num repositório privado protegido por uma lista de permissões de IP.
- Exfiltrar código-fonte de projetos privados protegidos por uma lista de permissões de IP.
- Ler variáveis de CI/CD e Secrets a partir de projetos privados.
- Aceder a issues confidenciais em projetos privados (através da ação rápida /move)
- Utilizar o CI_JOB_TOKEN disponível em tarefas de CI/CD para aprofundar o acesso na conta.
Um endereço de e-mail de entrada do GitLab contém um token que funciona como um token de acesso pessoal granular com permissões significativas.
A distinção mais importante é que, em vez de aceder ao GitLab via API, os utilizadores devem publicar dados através de e-mails. Na perspectiva de quem faz a defesa, se isso pode resultar no mesmo comprometimento da conta, interessa saber se se trata de um pedido HTTP ou de um e-mail?
Restrições do atacante
Há dois factores que limitam um atacante de posse do endereço:
1. O token herda as permissões da vítima e nenhum elemento no fluxo de e-mail as eleva.
As permissões da vítima limitam os danos. Um endereço de Convidado (Guest) divulgado é praticamente inútil. Um endereço de Mantenedor (Maintainer) divulgado pode atingir branches protegidos e variáveis de CI/CD. Nada no fluxo de e-mail define esse limite, apenas o papel da vítima.
2. O encaminhamento exige saber qual o projecto a atacar.
O GitLab resolve o destino a partir de dois valores contidos no endereço de e-mail de entrada: o slug do caminho do projecto e o ID do projecto. Para aceder a um segundo projecto, um atacante deve fornecer o caminho e o ID de um projecto diferente juntamente com o token roubado. Para projectos públicos, o GitLab publica ambos os valores. Para projectos privados, o atacante precisa de uma fuga de informação que indique o nome do projecto (o ID é fácil de adivinhar).
Uma dúzia, publicados de propósito
Tudo o resto depende de um atacante conseguir obter um endereço de e-mail. Passámos uma tarde a pesquisar na documentação pública e encontrámos facilmente uma dúzia de endereços de e-mail de entrada activos em READMEs, guias de contribuição e páginas de suporte. Quase todos tinham sido publicados deliberadamente, por um mantenedor que indicava aos utilizadores para onde enviar relatórios de erros! Alguns pertenciam a projectos open source 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 um endereço de e-mail, formata-o como tal e disponibiliza um botão para o copiar. Nada nele se assemelha a uma credencial.
A janela modal refere para o manter privado e avisa que qualquer pessoa na posse do endereço pode criar itens de trabalho em seu nome. Esse aviso descreve spam. Não descreve envios de código (pushes) e execuções de pipelines em todos os projectos da conta.
Notificámos as contas afectadas antes da publicação. Infelizmente, o GitLab não dispõe de um mecanismo para revogar estes tokens em massa ou notificar os utilizadores, pelo que os nossos esforços tiveram resultados mistos.
Quem é afectado
Todas as contas GitLab.com e todas as instâncias autoalojadas (self-managed) com o e-mail de entrada activado. O GitLab restringe a documentação de e-mail de entrada a instâncias Self-Managed e GitLab.com, pelo que o GitLab Dedicated não aparenta ser afectado. Não conseguimos testar isso directamente.
Nenhum desses utilizadores consegue desativar esta funcionalidade. Não existe nenhuma definição para desativar a criação de issues por e-mail, nenhuma definição para desativar a criação de merge requests por e-mail, nem qualquer forma de exigir que o remetente coincida com um endereço verificado. O token não expira. O único controlo que o GitLab faculta é a hiperligação de reinicialização na página de tokens de acesso pessoal, sendo que reiniciá-lo invalida todos os endereços de projecto que possui.
Divulgação ao GitLab
Esta não é uma "vulnerabilidade" típica. Trata-se de expectativas violadas dos utilizadores a dobrar e predefinições inseguras a triplicar. Reportámos o caso através do HackerOne em maio de 2026, mas foi encerrado como comportamento pretendido (sem surpresa). Submetemos um problema confidencial no repositório do GitLab em junho de 2026, o qual obteve uma resposta mais detalhada.
A posição do GitLab, tal como a entendemos, é que este é um token como qualquer outro e que qualquer token divulgado conduz a maus resultados. Isso descreve o comportamento de qualquer credencial assim que um atacante a detém, o que está correcto. No entanto, evita o que torna este caso diferente. O GitLab criou uma credencial que atinge todos os projectos da conta e ignora restrições de IP, apresentando-a posteriormente como um endereço de e-mail.
Em resposta ao nosso relatório, o GitLab implementou uma atualização com três alterações:
- Removeu a frase "Não pode ser utilizado para aceder a quaisquer outros dados" da interface de utilizador.
- Adicionou "e merge requests" onde a interface de utilizador indicava anteriormente que o endereço apenas podia criar itens de trabalho.
- Documentou que o e-mail de entrada não está sujeito a restrições de IP.
Essa é uma resposta justa ao que reportámos, mas as actualizações continuam a não transmitir a totalidade do risco. Um utilizador que leia "merge requests" não fica a saber que o endereço transporta um token que envia código, executa tarefas de CI/CD e funciona a partir do exterior de uma lista de permissões de IP. Nada em nenhuma das interfaces indica que esse token alcança todos os projectos na conta.
O GitLab também manteve o mecanismo subjacente inalterado. A maior redução individual da superfície de ataque seria exigir que o endereço do remetente coincidisse com o da conta do GitLab. Nesse caso, um atacante necessitaria de acesso à conta de e-mail da vítima e não apenas a um endereço.
Como os detetamos
Adicionámos cobertura adicional ao Betterleaks para identificar todos os tipos de tokens de email de receção do GitLab, incluindo:
- tokens com o prefixo `glimt-`
- tokens com prefixos personalizados
- tokens gerados antes da existência do prefixo `glimt-`
O Betterleaks identifica agora mais formatos de tokens de email de entrada do GitLab do que qualquer outro scanner de secrets, incluindo o GitLab.
A detecção de segredos do Aikido aplica a mesma cobertura que o Betterleaks nos seus repositórios e merge requests. Se surgir algum resultado, faça a rotação das suas credenciais imediatamente.
Um endereço de email do GitLab comprometido apresenta outro vetor para os agentes de ameaças enviarem código malicioso e comprometerem a cadeia de fornecimento. Considere executar o Safe Chain ou a Device Protection do Aikido para evitar que você (ou a sua equipa) instalem acidentalmente pacotes comprometidos. O Safe Chain é uma CLI open-source que encapsula o npm, o pip e outros gestores de pacotes para bloquear malware conhecido antes da sua instalação. A Device Protection faz o mesmo para as equipas, bloqueando pacotes maliciosos, registando instalações a nível organizacional e aplicando políticas de aprovação. Nenhum deles impede que o detentor de um token envie código, mas ajudam a evitar que uma dependência maliciosa adicionada através de um commit comprometido seja executada na máquina de um programador ou numa compilação.
