GitLab CVE-2026-97229: a CISA lista-a como explorada e a Alpine Linux mostra que atualizar nem sempre basta

A CISA adicionou a CVE-2026-97229, uma falha do GitLab com CVSS 10.0, ao catálogo de vulnerabilidades exploradas. A Alpine Linux relata uma tentativa de ataque ao seu próprio servidor, que continuou vulnerável após uma atualização porque a correção depende também da versão de Ruby.

O que aconteceu

Em 29 de outubro de 2026, a CISA adicionou a CVE-2026-97229 ao catálogo de vulnerabilidades exploradas: as agências federais dos EUA têm até 1 de novembro para agir e devem realizar uma análise forense. O GitLab classifica a falha como crítica, com pontuação CVSS de 10,0: um excesso de inteiro no compilador de expressões regulares da configuração CI/CD permite, em determinadas condições, que um utilizador não autenticado execute código no servidor. O GitLab corrigiu-a em 12 de outubro nas versões 19.4.2, 19.3.5 e 19.2.8. A Alpine Linux indicou em 28 de outubro que um atacante tentou explorá-la contra o servidor GitLab do projeto nos dias 20 e 21 de outubro.

Quem é afetado e como os atacantes entram

São afetadas as edições Community e Enterprise autogeridas a partir da 19.2; o GitLab.com e o Dedicated já estão corrigidos. O erro está no Onigmo, o motor de expressões regulares integrado no Ruby, e a correção do GitLab altera o Ruby incluído nos seus pacotes e imagens oficiais. A Alpine instalou primeiro a 19.3.4 por engano e depois a 19.3.6 numa imagem baseada em Ruby padrão, que não continha a correção. Com uma conta nova e configurações CI manipuladas, o atacante fez falhar processos do GitLab oito vezes. A Alpine não encontrou provas de execução de código, mas não pôde excluí-la, pelo que reconstruiu o servidor de raiz, repôs todas as palavras-passe e substituiu as chaves secretas do GitLab. O projeto afirma que as suas versões e pacotes foram verificados e não foram alterados, e que as chaves de assinatura nunca estiveram nesse servidor.

O que fazer agora

1. Verifique a versão com sudo gitlab-rake gitlab:env:info.
2. Atualize para o patch mais recente do seu ramo: 19.5.3, 19.4.5, 19.3.7 ou 19.2.10.
3. Se compila o GitLab por conta própria (a partir do código-fonte ou no seu próprio contentor), verifique ruby -v: precisa de 3.3.13, 3.4.12, 4.0.9 ou posterior. Volte a descarregar alpinelinux/gitlab:19.3.6 se a obteve antes de 27 de outubro; as etiquetas mais antigas são vulneráveis.
4. Procure vestígios: aplique as seis regras de deteção publicadas pelo GitLab e analise falhas de processos, erros 502, tarefas CI falhadas e contas registadas recentemente. Um resultado limpo prova pouco: segundo a Alpine, uma exploração bem-sucedida não deixa falha nem vestígio nos registos web.
5. Em caso de dúvida, reconstrua e substitua chaves secretas, palavras-passe, variáveis CI/CD, tokens de runners e segredos de webhooks. Exija a aprovação de um administrador para novas contas.
6. Reveja as suas outras aplicações Ruby: o código que passa dados não fiáveis a Regexp.new, Regexp.union ou a um padrão interpolado precisa de um Ruby corrigido. Segundo a equipa do Ruby, nem Regexp.timeout nem um limite de comprimento protegem de forma fiável.

A nossa opinião

Um número de versão não prova que um servidor está corrigido quando a correção reside numa dependência: a verificação deve abranger toda a compilação, sobretudo em imagens próprias. Uma forja reúne código-fonte e segredos de implementação e não deve ficar aberta a toda a Internet. Conserve registos suficientes, incluindo ligações de saída, para poder responder quando surgir a questão de um comprometimento.

Fontes

• GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-97229
• Alpine Linux — GitLab security incident: attempted exploitation of CVE-2026-97229
• Alpine Linux — GitLab is back: what you need to do
• Ruby — Regexp fixes for GitLab CVEs
• GitLab — Patch Release 19.5.3

Como escolhemos, verificamos e escrevemos nossas análises →