GitLab CVE-2026-97229: RCE CVSS 10 explorada, atualize já

O desafio principal é que essa falha reúne as duas características que os invasores mais valorizam, nenhuma autenticação e execução total de código, e já foi testada contra um alvo real. Segundo o The Hacker News, a inclusão na lista da CISA está ligada a um incidente divulgado pelo Alpine Linux. Um agente desconhecido tentou explorar a falha na instância GitLab do Alpine em 20 e 21 de outubro de 2026, enviando configurações de CI manipuladas que fizeram os processos de trabalho do GitLab falharem oito vezes. Em quatro dessas quedas o exploit falhou na etapa seguinte. O invasor também baixou a imagem de contêiner do GitLab do Alpine.

As tentativas posteriores, em 25 e 26 de outubro, foram bloqueadas. Os mantenedores do Alpine disseram que o ataque chegou perto de funcionar, que não encontraram evidência de sucesso mas não podem descartá-lo, e que por isso trataram a instância como comprometida e a reconstruíram do zero. Informaram ainda que o repositório de pacotes e as versões de 21 de outubro não foram adulterados. Nenhum agente de ameaça foi identificado.

Três lições para as equipes empresariais:

• A janela de correção foi real. A correção saiu em 12 de outubro e as tentativas começaram oito dias depois. A exploração seguiu de perto a disponibilidade do patch, o padrão usual em falhas críticas.
• Quedas são evidência. As quedas repetidas de processos foram a forma como o Alpine percebeu a atividade. Muitas organizações não alertam sobre falhas de aplicação em ferramentas de desenvolvimento.
• Reconstruir às vezes é a resposta certa. Quando não é possível provar que um servidor não foi comprometido, uma reconstrução limpa com segredos rotacionados é mais segura do que esperar.

O GitLab também informa que os detalhes técnicos completos serão divulgados 90 dias após a versão, ou seja, não antes de 10 de janeiro de 2027. Até lá, é menos provável que circule código de exploit público, mas o incidente do Alpine mostra que invasores capazes não esperaram.

A resposta ao CVE-2026-97229 consiste em identificar cada instância autogerenciada do GitLab, atualizar para uma versão corrigida, procurar sinais de exploração e rotacionar os segredos que o servidor alcançava. Siga estes passos na ordem.

1. Inventarie cada instância. Inclua o servidor de produção óbvio e os esquecidos: servidores de teste, instâncias de unidades de negócio e servidores herdados de aquisições. Não dá para corrigir o que não se sabe que existe.
2. Verifique a versão. O GitLab lista como afetadas todas as versões a partir da 19.2 anteriores à 19.2.8, da 19.3 anteriores à 19.3.5 e da 19.4 anteriores à 19.4.2, tanto CE quanto EE. As versões corrigidas são 19.2.8, 19.3.5 e 19.4.2. O aviso do GitLab não lista soluções alternativas, então atualizar é o remédio.
3. Atualize já e confirme. Agende uma janela de emergência, atualize e verifique a versão em execução. Teste seus pipelines, pois uma versão de correções desse porte inclui muitas outras mudanças. A mesma versão resolve cerca de duas dezenas de vulnerabilidades, entre elas CVE-2026-92883 (cross-site scripting, CVSS 8.7), CVE-2026-16301 (autorização inadequada em pipelines downstream, CVSS 8.5) e CVE-2026-14814 (CVSS 8.2).
4. Procure exploração. O GitLab publicou seis detecções de ameaças para instâncias autogerenciadas, cobrindo sinais como quedas do processo Onigmo, expressões regulares hostis enviadas ao caminho GraphQL do CI lint, caminhos não ASCII de tamanho excessivo, rejeições do filtro de expressões, quedas do processo de CI lint e rajadas de erros de cliente no CI lint. Revise seus logs pelo menos desde 12 de outubro e atente para downloads inesperados de imagens de contêiner.
5. Trate achados suspeitos como comprometimento. Se encontrar indicadores, siga o exemplo do Alpine: isole o servidor, reconstrua-o a partir de uma imagem limpa e restaure os dados de um backup confiável.
6. Rotacione os segredos. Variáveis de CI/CD, chaves de deploy, tokens de registro de runners e credenciais de nuvem armazenados no GitLab devem ser rotacionados se houver qualquer dúvida.
7. Reduza a exposição. Uma plataforma de código raramente precisa estar aberta a toda a internet. Coloque-a atrás de um acesso privado e segmentado, como uma rede gerenciada multioperadora com VPN ou acesso de confiança zero, e limite quem alcança o CI lint e os endpoints da API.

Envie os logs a um SIEM central para que um padrão de quedas em um servidor de desenvolvimento vire alerta, e não nota de rodapé.

Tratar as plataformas de desenvolvimento com o mesmo rigor dos sistemas de produção protege o software que você entrega e os clientes que dependem dele. Responder bem a essa falha traz benefícios práticos.

• Menor risco na cadeia de suprimentos. Um servidor GitLab limpo, atualizado e monitorado reduz a chance de um invasor inserir código nos seus builds ou roubar os segredos usados para implantá-los.
• Resposta a incidentes mais rápida e barata. Logs centralizados e um procedimento de reconstrução testado transformam um possível comprometimento em um exercício controlado. A reconstrução do zero feita pelo Alpine é um bom modelo, pois elimina a dúvida.
• Melhor postura em auditorias e contratos. Clientes, seguradoras e auditores perguntam cada vez mais com que rapidez as vulnerabilidades exploradas ativamente são corrigidas. Um processo de correção guiado pelo KEV, com datas documentadas, responde a essa pergunta.
• Visibilidade da infraestrutura paralela. O inventário costuma revelar servidores sem gestão. Encontrá-los numa semana tranquila custa muito menos do que depois de uma violação.
• Um processo repetível. Os mesmos passos servem para a próxima falha crítica em uma ferramenta de CI/CD, um hipervisor ou um equipamento de borda, então o esforço se paga a cada vez.

O prazo de 1º de novembro da CISA vale para as agências civis federais dos EUA, mas é uma referência sensata para qualquer empresa. Se o seu GitLab autogerenciado ainda está hoje em uma versão afetada, você já está atrás do calendário público.

A HIT Communications ajuda empresas a manter plataformas críticas atualizadas, monitoradas e recuperáveis, para que um aviso de fabricante não vire um incidente prolongado. Com mais de 30 anos de experiência na América Latina, nos Estados Unidos e na Europa, reunimos redes, segurança e operações de TI em uma única equipe.

Nossos serviços de cibersegurança incluem SOC 24/7, SIEM e detecção e resposta gerenciadas que ingerem logs de plataformas de desenvolvimento, firewalls e sistemas de identidade, e alertam tanto por quedas e anomalias quanto por assinaturas de ataque conhecidas. Nossos serviços gerenciados de TI cobrem planejamento de correções, operação de infraestrutura local e em nuvem, e backup, para que atualizações de emergência sejam agendadas, testadas e documentadas, e não improvisadas.

Se você opera GitLab autogerenciado e não tem certeza de qual versão possui, quem consegue acessá-lo ou quais segredos ele guarda, podemos ajudar a inventariar as instâncias, planejar a atualização com mínima indisponibilidade e implantar o monitoramento dos sinais que o GitLab publicou.

O CVE-2026-97229 lembra que os sistemas que constroem o seu software merecem a mesma proteção que os que o executam. Uma falha CVSS 10.0 que não exige login tem correção desde 12 de outubro, uma tentativa de ataque contra um projeto muito conhecido e um alerta da CISA cujo prazo federal já venceu.

Comece hoje com três ações: liste cada instância autogerenciada do GitLab e sua versão, atualize para 19.4.2, 19.3.5 ou 19.2.8 ou posterior, e procure nos seus logs os sinais de quedas e de CI lint que o GitLab publicou. Se quiser apoio com o inventário, a janela de manutenção ou o monitoramento contínuo, fale com a equipe da HIT Communications.