GitLab: falha crítica CVE-2026-19478 sob exploração ativa
Uma vulnerabilidade crítica no GitLab Community Edition (CE) e Enterprise Edition (EE) self-managed já está sob exploração ativa, apenas dias depois de ser divulgada publicamente. A falha, catalogada como CVE-2026-19478, recebeu CVSS 9.4 e permite que um atacante não autenticado modifique ou apague projetos públicos, sem precisar de credenciais, interação do usuário ou configuração incomum.
O que é a CVE-2026-19478
Trata-se de uma injeção de código explorável via diretiva GraphQL. O GitLab confirmou que a falha pode ser acionada através da API GraphQL da instância, e o vetor específico usa a diretiva @gl_introduced.
Segundo a pesquisadora de segurança da watchTowr, o time conseguiu reproduzir o exploit em minutos após a divulgação da falha, e detectou tentativas de exploração real contra sua rede de honeypots.
Por que é mais grave do que parece
O impacto vai além de apagar projetos públicos. A watchTowr registrou que um atacante pode excluir repositórios inteiros, forjar registros de merge para simular que uma correção foi aplicada quando não foi, e banir mantenedores do próprio projeto.
Jake Knott, pesquisador principal de segurança da watchTowr, atribuiu a velocidade do ataque ao uso de ferramentas de IA por parte dos invasores: “esta é a nova realidade da reprodução e exploração de vulnerabilidades, em que atacantes apoiados por IA conseguem comprimir o tempo entre a divulgação e a exploração — esperar pelo próximo ciclo de patches costuma já ser tarde demais”.
Versões afetadas e correção
A falha atinge apenas instâncias self-managed (GitLab.com/SaaS não é afetado) nas seguintes faixas de versão:
- 18.2 antes da 18.11.11
- 19.0 antes da 19.0.8
- 19.1 antes da 19.1.6
- 19.2 antes da 19.2.4
O GitLab lançou correção fora do ciclo normal quinzenal de patches, em 17 de agosto de 2026, nas versões 19.2.4, 19.1.6, 19.0.8 e 18.11.11.
Como se proteger agora
- Atualize a instância self-managed para uma das versões corrigidas o quanto antes.
- Se o patch não puder ser aplicado de imediato, restrinja o acesso não autenticado ao endpoint
/api/graphql. - Como mitigação adicional, remova o acesso público a repositórios enquanto o patch não é aplicado.
- Vasculhe os logs web em busca de requisições contendo a string
@gl_introduced— é o indício de sondagem ou tentativa de exploração.
Perguntas frequentes
O GitLab.com (SaaS) foi afetado?
Não. A falha atinge apenas instâncias self-managed de GitLab CE e EE.
É preciso estar autenticado para explorar a falha?
Não. O ataque não exige credenciais, interação do usuário nem configuração fora do padrão.
O que um atacante consegue fazer, além de apagar projetos?
Excluir repositórios inteiros, forjar registros de merge simulando uma correção falsa e banir mantenedores do projeto.
Atualizar a versão já elimina o risco?
Sim, aplicar 19.2.4, 19.1.6, 19.0.8 ou 18.11.11 corrige a falha. Sem atualização imediata, restrinja o acesso ao endpoint GraphQL como mitigação temporária.
Como saber se minha instância já foi alvo de sondagem?
Procure nos logs por requisições contendo a string @gl_introduced, o indicador identificado pela watchTowr.
Conclusão
O intervalo entre a divulgação de uma falha e sua exploração em massa está cada vez mais curto — neste caso, foram minutos. Quem administra GitLab self-managed exposto à internet deve tratar a atualização como prioridade imediata, e não esperar a próxima janela de manutenção.
