Uma funcionalidade criada para facilitar o uso do GitLab pode representar um risco importante quando seu endereço de e-mail associado é exposto publicamente. Uma investigação da empresa de segurança Aikido mostrou que a segurança no GitLab pode ser afetada quando endereços usados para criar itens de trabalho por e-mail aparecem em locais como arquivos README, documentação ou guias de contribuição.
O problema está relacionado aos endereços gerados pelo GitLab para receber mensagens. Embora pareçam apenas caixas de entrada específicas para criação de issues, esses endereços carregam um token de autenticação identificado pelo prefixo glimt-. Quem obtém esse endereço pode enviar mensagens ao GitLab e executar ações com as permissões associadas à conta proprietária do token.
O cenário se torna mais preocupante porque o mecanismo também pode ser utilizado para criar merge requests com arquivos .patch. Em determinadas condições, isso permite alterar arquivos do projeto, incluindo configurações de CI/CD, fazendo com que código enviado pelo atacante seja executado com as permissões disponíveis para a vítima. A investigação também demonstrou que esse fluxo não respeita determinadas restrições de acesso baseadas em endereço IP.
Como a segurança no GitLab pode ser afetada pela exposição de e-mails
O GitLab possui recursos que permitem criar issues e merge requests por meio de mensagens de e-mail. Na interface, o usuário pode solicitar um endereço específico para enviar um item de trabalho para determinado projeto.
Um endereço desse tipo possui uma estrutura semelhante a:
incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
O trecho glimt- identifica um token de e-mail de entrada do GitLab. A documentação oficial classifica o chamado incoming mail token como um tipo próprio de credencial.
Isso muda completamente a maneira como esse endereço deve ser tratado. Não se trata simplesmente de um endereço descartável para recebimento de mensagens. Segundo a própria documentação do GitLab, qualquer pessoa que tenha acesso ao endereço pode criar issues ou merge requests como se fosse o usuário correspondente. Caso o endereço seja exposto, a recomendação é redefinir o token.
A questão central descoberta pela Aikido é justamente essa diferença entre aparência e função. Um endereço publicado em um README pode parecer uma informação operacional sem grande importância, mas, na prática, ele funciona como uma credencial de autenticação.
O truque da alteração do sufixo para merge requests
A investigação revelou que o problema não fica restrito à criação de issues.
O endereço exibido para criação de itens de trabalho termina com o sufixo -issue. Segundo a Aikido, alterar essa parte para -merge-request permite utilizar o mesmo token para criar uma solicitação de código.
Esse comportamento é particularmente relevante para a segurança de repositórios GitLab, porque merge requests podem transportar alterações no código-fonte.
O GitLab documenta oficialmente a criação de merge requests por e-mail. O recurso aceita arquivos .patch como anexos, com limite combinado de 2 MB, e pode criar uma nova branch caso a informada no assunto ainda não exista.
Na prática, o fluxo demonstrado pela Aikido pode ser resumido assim:
- Um endereço de e-mail de entrada pertencente a uma conta é exposto.
- O atacante obtém esse endereço.
- O trecho
-issueé substituído por-merge-request. - O atacante prepara um arquivo
.patchcontendo alterações no código. - O patch é enviado por e-mail, com a branch indicada no assunto.
- O GitLab processa a mensagem e aplica as alterações de acordo com as permissões disponíveis.
- Se o código modificado incluir alterações em
.gitlab-ci.yml, o pipeline poderá executar as instruções introduzidas pelo atacante, dependendo das permissões e das configurações do projeto.
Isso transforma uma simples exposição de endereço em um possível vetor para injeção de código em repositórios.
O risco não significa que qualquer endereço exposto conceda automaticamente controle administrativo. O token herda as permissões da conta associada. Porém, justamente por isso, uma conta com privilégios elevados pode transformar o vazamento em um incidente muito mais grave.
O contorno de restrições de IP e permissões
Outro ponto importante para a segurança no GitLab é a forma como o acesso por e-mail se relaciona com controles de rede.
Durante os testes, a Aikido configurou uma restrição de endereço IP para um projeto privado. O acesso pela interface web e operações de clonagem foram bloqueados quando realizadas fora do endereço autorizado. Entretanto, uma solicitação enviada pelo mecanismo de e-mail continuou sendo processada.
Isso ocorre porque a restrição de IP atua sobre determinados caminhos de acesso ao GitLab, enquanto o processamento de mensagens recebidas acontece por outro canal.
Consequentemente, uma organização não deve considerar uma política de IP como proteção suficiente contra a exposição desse tipo de credencial. O e-mail funciona como uma porta alternativa para determinadas operações.
Existe, porém, um limite importante: o atacante não recebe privilégios superiores aos da vítima. Uma conta com permissões reduzidas terá impacto limitado, enquanto uma conta com funções como Maintainer pode possuir acesso a branches protegidas, repositórios e variáveis utilizadas em pipelines.
Além disso, para atingir outros projetos, o atacante precisa conhecer informações que permitam identificar o projeto desejado. Em projetos públicos, dados como caminho e ID podem ser facilmente encontrados; em projetos privados, é necessário algum conhecimento adicional ou outra forma de exposição.
O impacto para projetos de código aberto e a resposta do GitLab
A descoberta da Aikido foi comunicada ao GitLab por meio do HackerOne em maio de 2026. Segundo a empresa de segurança, o relatório foi inicialmente encerrado pelo GitLab como comportamento esperado. Posteriormente, a Aikido abriu um chamado confidencial diretamente no projeto do GitLab, em junho de 2026.
A discussão é importante porque envolve uma questão recorrente em segurança: uma funcionalidade pode operar exatamente conforme foi projetada e, ainda assim, apresentar riscos quando uma credencial é exposta em um contexto para o qual os usuários não esperavam que ela tivesse esse nível de poder.
O GitLab já reconhece oficialmente que o endereço deve ser mantido privado. A documentação atual afirma que qualquer pessoa com acesso a esse endereço pode criar issues ou merge requests como se fosse o usuário e recomenda redefinir o token imediatamente caso ele tenha sido compartilhado ou vazado.
Após a comunicação da Aikido, a interface do GitLab recebeu alterações para esclarecer que os endereços também podem criar merge requests e que o processamento de e-mails não está sujeito às restrições de IP. A empresa de segurança, porém, afirma que o mecanismo subjacente permaneceu inalterado.
Para projetos de código aberto, o cenário merece atenção especial. READMEs e arquivos de documentação frequentemente apresentam instruções de contribuição, contatos de manutenção e endereços destinados ao envio de informações.
Se um desses endereços corresponder a uma credencial de entrada do GitLab, sua publicação pode ampliar a superfície de ataque sem que o conteúdo pareça, à primeira vista, um segredo.
O problema também pode atingir a cadeia de suprimentos de software. Um atacante que consiga alterar código em um projeto utilizado por outras equipes pode introduzir modificações que serão analisadas, compiladas ou distribuídas por processos automatizados.
O risco é ainda maior quando os pipelines possuem acesso a segredos de CI/CD, registries privados, serviços de nuvem ou outros recursos internos. Nesse cenário, o comprometimento do código-fonte pode se transformar em um ponto de partida para atingir sistemas além do próprio repositório.
É importante destacar que isso não significa que todo pipeline do GitLab esteja vulnerável da mesma maneira. O impacto depende das permissões da conta, das regras de proteção de branches, das configurações do pipeline, dos segredos disponíveis e de como o projeto valida e executa alterações.
Como proteger seu repositório GitLab contra essa brecha
A primeira medida para melhorar a segurança no GitLab é tratar endereços contendo tokens glimt- como credenciais sensíveis, e não como simples endereços de e-mail.
Projetos devem ser auditados em busca desses endereços em README, CONTRIBUTING, wikis, documentação pública, exemplos de configuração, issues e outros arquivos versionados. A mesma verificação deve ser feita em repositórios públicos antigos, forks e materiais externos mantidos pela equipe.
Se um endereço foi exposto, a medida mais importante é redefinir o incoming email token. A documentação do GitLab disponibiliza a opção de redefinição nas configurações da conta. A própria plataforma recomenda essa ação quando existe suspeita de compartilhamento ou vazamento.
Também é necessário revisar os projetos e branches que poderiam ter sido modificados pelo token. Em caso de exposição, equipes de segurança devem procurar merge requests inesperados, commits desconhecidos, novas branches, alterações em .gitlab-ci.yml e execuções incomuns de pipelines.
Outro ponto fundamental é reduzir o impacto caso uma credencial seja comprometida. Permissões excessivas em contas de desenvolvedores e Maintainers aumentam a superfície de ataque. Da mesma forma, pipelines não devem receber acesso indiscriminado a segredos ou infraestrutura quando isso não for necessário.
Para ambientes que realmente precisam utilizar recursos de entrada por e-mail, o próprio GitLab recomenda cuidados adicionais. Na documentação de hardening, a empresa aconselha dedicar um endereço específico para mensagens recebidas, utilizar subendereçamento, exigir MFA nas contas envolvidas e avaliar cuidadosamente a exposição desse recurso em ambientes protegidos.
Administradores também devem considerar se o recurso é realmente necessário. A documentação de hardening do GitLab recomenda evitar o uso de e-mail de entrada em ambientes que exigem maior proteção, justamente por envolver comunicação externa capaz de enviar informações para a instância.
Por fim, equipes de DevOps devem incorporar esse tipo de credencial às rotinas de gestão de segredos e resposta a incidentes. Um endereço glimt- encontrado em um repositório deve ser tratado com a mesma atenção dedicada a outras credenciais expostas.
A descoberta da Aikido serve como alerta para uma regra simples: funcionalidades convenientes também precisam ser avaliadas como possíveis caminhos de autenticação. Audite agora seus README e guias de contribuição, procure endereços de entrada do GitLab e, se encontrar algum token exposto, faça a rotação e revise as atividades relacionadas.
Compartilhar esse alerta com sua equipe de DevOps, segurança e administração de sistemas também pode ajudar a evitar que uma informação aparentemente inofensiva se transforme em um vetor de comprometimento da cadeia de software.
