Resumo para quem decide

A CVE-2026-97229 é uma falha crítica no GitLab, com CVSS 10.0, que permite a um atacante não autenticado executar código arbitrário no servidor. O patch está disponível desde 12 de outubro de 2026, a CISA confirmou exploração ativa e adicionou a falha ao catálogo Known Exploited Vulnerabilities (KEV), e a Shadowserver identificou mais de 1.000 instâncias GitLab expostas na internet ainda sem a correção, três semanas depois do patch ter sido publicado, segundo reportagem do BleepingComputer.

Se sua empresa roda GitLab self-managed (CE ou EE) em qualquer versão 19.2 anterior a 19.2.8, 19.3 anterior a 19.3.5 ou 19.4 anterior a 19.4.2, a ação é simples e urgente: atualizar para 19.4.2, 19.3.5 ou 19.2.8 agora, não na próxima janela de manutenção.

O que é a CVE-2026-97229 e por que ela é crítica

A falha no CI/CD Regular Expression Compiler

A vulnerabilidade é um integer overflow no CI/CD Regular Expression Compiler, o componente do GitLab responsável por interpretar e avaliar expressões regulares dentro de arquivos de configuração de pipeline. Segundo o próprio GitLab, a falha “poderia ter permitido que um usuário não autenticado executasse código arbitrário no servidor GitLab via uma expressão regular especialmente criada em uma configuração de CI/CD, devido à validação insuficiente de expressões regulares”.

O vetor CVSS (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) confirma o cenário mais grave possível: ataque via rede, sem complexidade adicional, sem necessidade de privilégio prévio e sem exigir qualquer interação do usuário. A prova de conceito publicada pela Rapid7 em 13 de outubro mostra como isso acontece na prática: o atacante grava um .gitlab-ci.yml manipulado e um caminho de repositório em UTF-8 num branch de projeto público e, depois, faz uma requisição ao endpoint de CI Lint sem token, cookie ou qualquer credencial. O Onigmo, motor de expressões regulares do Ruby, recompila a expressão, ocorre o overflow e o comando roda no servidor com a conta git do GitLab, não como administrador.

Isso define quem corre mais risco. O cenário demonstrado pressupõe que o atacante consiga fazer push num projeto público da instância, o que é trivial em servidores com cadastro aberto ou com muitos usuários externos. As fontes não dizem quantas das instâncias expostas permitem isso, então a ausência de cadastro aberto reduz o risco, mas não substitui a atualização.

A falha foi reportada por um pesquisador identificado como joaxcar, através do programa de bug bounty do GitLab no HackerOne.

Versões afetadas e versões corrigidas

Os três releases foram publicados em 12 de outubro de 2026. GitLab.com já está rodando a versão corrigida, e todos os tenants do GitLab Dedicated foram atualizados internamente antes mesmo da publicação do patch release, segundo o próprio fabricante. Quem está exposto é exclusivamente a base self-managed que ainda não aplicou a atualização.

Exploração ativa: o que se sabe até agora

No fim de outubro, a CISA confirmou exploração ativa da CVE-2026-97229 e a incluiu no catálogo KEV, dando às agências federais dos EUA prazo até o domingo, 1º de novembro, para corrigir seus servidores. É um prazo bem mais curto que o habitual do catálogo, o que indica a urgência que a agência atribui ao caso.

A Shadowserver, organização que monitora exposição de infraestrutura na internet, informou no fim de semana que rastreia mais de 1.000 instâncias GitLab ainda vulneráveis à CVE-2026-97229, em meio à exploração em curso. A citação direta da organização, via BleepingComputer, é esta: “We are currently tracking over 1000 GitLab instances vulnerable to CVE-2026-97229 (on @CISACyber KEV) and over 11300 instances vulnerable to CVE-2026-110264 (out of around 39K GitLab instances we see daily).”

Há exploit público desde 13 de outubro, um dia depois do patch, o que encurta muito o caminho de quem quer atacar. Por outro lado, até agora ninguém atribuiu publicamente os ataques a nenhum grupo nem descreveu o que os atacantes fazem depois de obter execução de código.

Esse padrão de patch disponível há semanas, exploração ativa confirmada e milhares de instâncias ainda expostas não é exclusivo do GitLab. Vimos situação parecida na campanha FortiBleed contra equipamentos Fortinet, em que a exploração seguiu ativa mesmo com correção disponível. Também é comparável ao caso recente do BIG-IP APM da F5, em que a exploração começou de forma praticamente simultânea à divulgação da falha. No GitLab, o patch já existe há três semanas, e ainda assim a aplicação ficou para trás em mais de mil instâncias.

Por que RCE não autenticado no GitLab é um risco de cadeia de suprimento

GitLab não é só um repositório de código. Em muitas organizações, é o ponto central onde ficam segredos de CI/CD, tokens de acesso a serviços de nuvem, credenciais de deployment e as próprias pipelines que constroem e publicam software em produção. Um atacante com execução remota de código no servidor GitLab não precisa “roubar” código-fonte isoladamente: ele pode acessar variáveis de ambiente de pipelines, tokens de integração com registries de containers, chaves de API de provedores de nuvem e, a partir daí, buscar movimento lateral para outros sistemas da organização.

É esse tipo de cenário que caracteriza um ataque de cadeia de suprimento de software: comprometer o ambiente de build e deployment de uma empresa pode ter efeito muito maior do que comprometer um servidor isolado, porque o impacto se propaga para tudo que passa por aquela pipeline. Vale a leitura sobre ataques à cadeia de fornecedores de software para entender como esse tipo de comprometimento costuma escalar além do sistema inicialmente atingido.

O GitLab afirma ter mais de 70 milhões de usuários registrados e ser usado por mais de 50% das empresas da Fortune 100. Para empresas brasileiras que mantêm instâncias self-managed, seja por exigência de compliance, controle de dados ou arquitetura interna, essa escala de adoção global não muda o cálculo de risco local: o que importa é se a sua instância específica está na faixa de versões vulneráveis e exposta à internet.

Como proteger sua instância GitLab agora

Atualização: a única mitigação oficial

O patch release do GitLab não traz nenhum contorno para quem não pode atualizar de imediato. A orientação oficial do fabricante é direta: atualizar para 19.4.2, 19.3.5 ou 19.2.8, dependendo da série que você está rodando.

Antes de aplicar o patch, confirme a versão exata da sua instância (GitLab > Admin Area > Dashboard, ou via /help na interface web) e compare com a tabela de versões vulneráveis. Se sua instância está em qualquer versão anterior às corrigidas, trate como exposição confirmada, já que a requisição que dispara a falha não exige autenticação e o exploit é público.

Detecção para quem ainda não atualizou

Para instâncias self-managed que não conseguem aplicar o patch imediatamente, o GitLab lançou seis detecções de ameaça voltadas especificamente para identificar tentativas de exploração da CVE-2026-97229:

• Onigmo native worker crash
• Graphql cilint hostile regexp
• ci regexp oversized non ascii path
• ci regexp guard rejection
• ci lint workhorse worker crash
• ci lint scripted client error burst

Essas detecções servem como camada de monitoramento, não como substituto da correção. Os nomes já indicam o que procurar: crash de worker do Onigmo ou do Workhorse e rajadas de requisições ao CI Lint com expressões regulares anômalas. Qualquer crash desse tipo numa instância que ficou sem patch deve ser tratado como possível tentativa de exploração, e vale revisar commits recentes de .gitlab-ci.yml em projetos públicos.

Vale lembrar que a CVE-2026-97229 não é a única falha crítica recente no mesmo componente. O CI/CD Regular Expression Compiler já teve outra falha crítica, a CVE-2026-110264, corrigida no mês anterior e também de severidade máxima, com execução de código. Segundo a Shadowserver, mais de 11.300 instâncias GitLab ainda estão vulneráveis a essa falha anterior, de um total de aproximadamente 39.000 instâncias monitoradas diariamente. Isso reforça que uma verificação completa de versão deve cobrir ambas as falhas, não só a mais recente.

Perguntas frequentes

Minha instância GitLab.com ou GitLab Dedicated está em risco?
Não. GitLab.com já está rodando a versão corrigida, e todos os tenants do GitLab Dedicated foram atualizados internamente antes da publicação do patch release. O risco é exclusivo de instalações self-managed que ainda não aplicaram a atualização.

Como sei se minha versão self-managed está vulnerável?
Verifique a versão exata rodando na sua instância. Se estiver em qualquer versão 19.2 anterior a 19.2.8, 19.3 anterior a 19.3.5 ou 19.4 anterior a 19.4.2, sua instância está na faixa vulnerável e precisa ser atualizada para 19.4.2, 19.3.5 ou 19.2.8, conforme a série.

Existe prova de conceito pública para essa falha?
Sim. A Rapid7 publicou detalhes técnicos e um exploit funcional em 13 de outubro, um dia depois do patch. Ele pressupõe permissão para fazer push num projeto público da instância e executa comandos com a conta git do GitLab.

O que fazer se eu não puder atualizar imediatamente?
Não há workaround alternativo documentado pelo GitLab além da atualização. O que dá para fazer é monitorar as seis detecções de ameaça lançadas pelo fabricante e, como o exploit público depende de push em projeto público, restringir cadastro aberto e criação de projetos públicos por usuários externos. Nada disso substitui a atualização.

Essa vulnerabilidade está relacionada a outras falhas recentes do GitLab?
Sim, pelo menos indiretamente. A CVE-2026-110264, corrigida no mês anterior, afeta o mesmo componente (CI/CD Regular Expression Compiler) e também permite execução de código. Desde novembro de 2021, a CISA já adicionou seis falhas do GitLab ao catálogo KEV, sendo que uma delas também foi usada em ataques de ransomware, sem identificação pública de qual CVE especificamente. Outras falhas recentes incluem a CVE-2026-85706, na API de commits de repositório, explorável para roubo de credenciais, e a CVE-2026-0723, que permite bypass de autenticação de dois fatores.