Uma vulnerabilidade com pontuação CVSS 10.0 permite execução remota de código sem autenticação em instalações autogerenciadas do GitLab. A inclusão da falha no catálogo KEV da CISA confirma exploração ativa e aumenta a urgência para administradores de sistemas.
Os servidores GitLab autogerenciados estão no centro de um alerta de segurança envolvendo a vulnerabilidade CVE-2026-97229, uma falha crítica que pode permitir a execução remota de código (RCE) sem necessidade de autenticação. O problema está relacionado ao compilador de expressões regulares utilizado em configurações de CI/CD e recebeu pontuação máxima de 10,0 no CVSS 3.1.
O cenário exige atenção especial de equipes de infraestrutura, DevOps e segurança. Em 29 de outubro de 2026, a Cybersecurity and Infrastructure Security Agency (CISA) adicionou oficialmente a vulnerabilidade ao catálogo Known Exploited Vulnerabilities (KEV), reconhecendo sua exploração no mundo real. A agência estabeleceu 1º de novembro de 2026 como prazo de correção para as agências federais norte-americanas.
O risco vai além da indisponibilidade de uma plataforma de desenvolvimento. Uma invasão bem-sucedida pode comprometer repositórios privados, credenciais, variáveis de ambiente, tokens de acesso e pipelines de implantação. Isso transforma uma instância vulnerável em uma possível porta de entrada para ataques à cadeia de suprimentos de software (software supply chain attacks).
Uma ressalva importante sobre a quantidade de vítimas: embora o alerta editorial mencione mais de mil servidores expostos, não foi possível confirmar esse número em uma publicação verificável da Shadowserver Foundation. Portanto, a quantidade não deve ser apresentada como uma medição independente confirmada. A exploração ativa, entretanto, está oficialmente reconhecida pela CISA.
Como funciona a vulnerabilidade CVE-2026-97229 nos servidores GitLab
A CVE-2026-97229 é classificada como uma falha de estouro de inteiro (integer overflow), identificada no compilador de expressões regulares utilizado pelo mecanismo de CI/CD do GitLab.
O problema ocorre durante o processamento de expressões regulares especialmente elaboradas. Uma validação insuficiente permite que determinados valores ultrapassem os limites esperados durante a compilação dessas expressões, provocando um comportamento inesperado no processamento interno.
Em condições específicas, essa falha pode abrir caminho para que um invasor execute código arbitrário no servidor que hospeda o GitLab.
A vulnerabilidade afeta tanto o GitLab Community Edition (CE) quanto o GitLab Enterprise Edition (EE). Seu impacto foi classificado como crítico porque combina exploração pela rede, baixa complexidade de ataque e ausência de privilégios necessários.
O perigo da execução não autenticada
Um dos aspectos mais preocupantes da CVE-2026-97229 é a possibilidade de exploração sem autenticação.
Isso significa que o invasor não precisa necessariamente possuir uma conta legítima na plataforma, conhecer uma senha administrativa ou obter previamente um token de acesso válido.
A exploração utiliza uma expressão regular especialmente preparada em uma configuração de CI/CD para atingir o componente vulnerável.
O resultado potencial é a execução de comandos arbitrários no servidor. Dependendo das permissões do processo comprometido e da arquitetura da instalação, o invasor pode alcançar informações sensíveis, modificar arquivos, acessar credenciais e interferir nos processos de desenvolvimento e implantação.
Para equipes de DevSecOps, esse cenário representa um risco particularmente elevado. O GitLab frequentemente concentra informações que permitem acessar outros sistemas, incluindo:
- Tokens de acesso utilizados por aplicações e serviços.
- Variáveis protegidas armazenadas nas configurações de CI/CD.
- Credenciais de registros de contêineres e serviços de nuvem.
- Chaves utilizadas para implantação de aplicações.
- Código-fonte proprietário e repositórios privados.
- Configurações de infraestrutura como código (IaC).
Uma invasão desse tipo pode ultrapassar os limites do próprio GitLab e comprometer outros componentes da infraestrutura corporativa.
O panorama revelado pela CISA e o alerta de exploração ativa
A confirmação mais importante sobre a gravidade da situação veio em 29 de outubro de 2026, quando a CISA incluiu a CVE-2026-97229 em seu catálogo KEV.
Esse catálogo reúne vulnerabilidades para as quais existem evidências de exploração ativa. Portanto, a inclusão representa um sinal concreto de que a falha deixou de ser apenas um risco teórico.
Para as agências federais dos Estados Unidos, a determinação estabeleceu 1º de novembro de 2026 como prazo para a aplicação das medidas corretivas.
Embora esse prazo seja direcionado às entidades federais norte-americanas, ele também funciona como um importante indicador de prioridade para organizações privadas, universidades, empresas de tecnologia e administradores de servidores Linux.
A classificação CVSS 10.0 reforça a gravidade: a vulnerabilidade pode afetar a confidencialidade, a integridade e a disponibilidade do ambiente comprometido.
O GitLab também publicou orientações de detecção para instalações autogerenciadas, incluindo indicadores relacionados a falhas do processo nativo de expressões regulares, conhecido como Onigmo.
Versões afetadas e etapas imediatas para proteger seu servidor GitLab
A GitLab publicou correções emergenciais em 12 de outubro de 2026, disponibilizando versões atualizadas para as duas edições da plataforma.
As versões corrigidas para a CVE-2026-97229 são:
| Edição | Versão corrigida |
|---|---|
| GitLab CE | 19.4.2 |
| GitLab EE | 19.4.2 |
| GitLab CE | 19.3.5 |
| GitLab EE | 19.3.5 |
| GitLab CE | 19.2.8 |
| GitLab EE | 19.2.8 |
As instalações que utilizam as seguintes versões estão vulneráveis:
- 19.2.0 até 19.2.7;
- 19.3.0 até 19.3.4;
- 19.4.0 até 19.4.1.
É importante observar que cada versão corrigida pertence a uma ramificação específica. Administradores devem escolher a atualização correspondente à versão utilizada, respeitando também as orientações de compatibilidade e atualização do fabricante.
GitLab.com e GitLab Dedicated já receberam correções
Nem todos os usuários precisam executar procedimentos manuais.
Segundo o comunicado oficial da empresa:
- GitLab.com: já está executando uma versão corrigida.
- GitLab Dedicated: os ambientes foram atualizados internamente antes da publicação do comunicado.
- GitLab autogerenciado: administradores precisam verificar suas instalações e aplicar as atualizações necessárias.
Portanto, o principal grupo de atenção é formado por organizações que mantêm seus próprios servidores GitLab em distribuições Linux, máquinas virtuais, ambientes Kubernetes ou infraestrutura em nuvem.
Como verificar e atualizar a instalação
O primeiro passo é identificar a versão em execução. Em instalações Linux tradicionais, o administrador pode utilizar:
sudo gitlab-rake gitlab:env:infoO comando apresenta informações sobre o ambiente, incluindo a versão instalada.
Também é possível consultar diretamente o pacote:
sudo dpkg -l gitlab-ce gitlab-eeEm distribuições baseadas em RPM, utilize:
rpm -qa | grep gitlabDepois de identificar a versão, programe imediatamente a atualização para uma versão corrigida compatível.
Antes de iniciar o procedimento, é recomendável:
- Realizar um backup completo dos repositórios, bancos de dados e configurações.
- Verificar os requisitos de atualização e as notas de lançamento da versão de destino.
- Aplicar a atualização utilizando o gerenciador de pacotes ou o método oficial de instalação.
- Reiniciar os serviços quando necessário.
- Confirmar que a versão corrigida está efetivamente em execução.
- Verificar os registros de segurança em busca de atividades suspeitas anteriores à atualização.
A aplicação do patch elimina a vulnerabilidade conhecida, mas não garante que uma instalação anteriormente comprometida esteja limpa. Se houver indícios de exploração, é necessário investigar o ambiente, revisar contas e tokens, avaliar possíveis alterações nos repositórios e considerar a rotação de credenciais expostas.
Medidas adicionais de defesa em profundidade
Enquanto a atualização não é concluída, algumas medidas podem reduzir a superfície de ataque.
O acesso administrativo ao GitLab não deve ficar desnecessariamente exposto à internet pública. Sempre que possível, utilize VPN, regras restritivas de firewall e controles de acesso por endereço IP.
Também é importante revisar as permissões de projetos públicos, restringir a criação e a escrita de projetos por usuários não confiáveis e monitorar solicitações anormais relacionadas às configurações de CI/CD.
Essas medidas são complementares. Restringir o acesso não substitui a instalação da versão corrigida.
Uma sequência preocupante no histórico de segurança do GitLab
A CVE-2026-97229 não representa um episódio isolado na trajetória recente da plataforma. Ao longo de 2026, outras vulnerabilidades demonstraram como componentes de autenticação, APIs e mecanismos internos do GitLab podem se tornar alvos de ataques de alto impacto.
Entre os casos relevantes está a CVE-2026-0723, relacionada a um problema no processo de autenticação de dois fatores. A falha poderia permitir que um invasor que conhecesse o identificador de credencial de uma vítima contornasse a proteção mediante respostas de dispositivo forjadas.
Outro episódio importante envolve a CVE-2026-85706, uma vulnerabilidade de travessia de diretórios (path traversal) na API de commits do repositório. O problema permitia que solicitações especialmente construídas acessassem arquivos locais do servidor, criando condições para exposição de informações sensíveis.
A sequência ganhou outro capítulo em outubro com a CVE-2026-110264, uma segunda vulnerabilidade crítica relacionada ao estouro de inteiro durante a compilação de expressões regulares.
Essa falha recebeu novamente pontuação CVSS 10.0 e possui abrangência de versões diferente da CVE-2026-97229. Seu alcance inclui ramificações anteriores do GitLab, e as correções correspondentes foram publicadas em versões posteriores, como 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13.
Esse último episódio é especialmente importante: instalar uma correção para a CVE-2026-97229 não significa necessariamente que a instalação esteja protegida contra todas as vulnerabilidades posteriores do compilador de expressões regulares.
Administradores precisam acompanhar os boletins de segurança mais recentes e verificar se existem atualizações adicionais aplicáveis à sua ramificação.
Por que plataformas DevSecOps são alvos tão valiosos?
O interesse dos criminosos por ferramentas como o GitLab não acontece por acaso.
Plataformas DevSecOps concentram diferentes recursos estratégicos de uma organização em um único ambiente. Além do código-fonte, elas armazenam informações de autenticação, configurações de implantação, integrações com provedores de nuvem e credenciais utilizadas por aplicações.
Para grupos de ransomware e agentes especializados em espionagem corporativa, comprometer esse ambiente pode oferecer oportunidades muito maiores do que invadir uma estação de trabalho isolada.
Um invasor pode tentar utilizar credenciais encontradas nos pipelines para alcançar outros serviços, alterar componentes de software, comprometer imagens de contêineres ou inserir código malicioso em processos de compilação.
Esse tipo de comprometimento é particularmente perigoso porque pode atingir também os consumidores e usuários finais dos produtos desenvolvidos pela organização.
Por isso, proteger o GitLab não é apenas uma tarefa de manutenção de servidores. É uma medida fundamental para preservar a integridade de toda a cadeia de desenvolvimento de software.
Conclusão: administradores precisam atualizar seus servidores GitLab imediatamente
A CVE-2026-97229 representa uma ameaça crítica para organizações que mantêm instalações autogerenciadas do GitLab. A combinação de execução remota de código sem autenticação, pontuação CVSS 10.0 e inclusão no catálogo KEV da CISA exige uma resposta imediata das equipes responsáveis pela infraestrutura.
A disponibilidade de versões corrigidas desde outubro não elimina o risco para ambientes que continuam utilizando versões vulneráveis. Pelo contrário, a confirmação de exploração ativa torna ainda mais perigoso adiar a manutenção.
Administradores de sistemas devem verificar todas as instâncias em operação, incluindo ambientes de homologação, laboratórios, servidores secundários e instalações esquecidas que continuam acessíveis pela internet.
Também é fundamental investigar possíveis sinais de comprometimento, revisar credenciais e acompanhar as atualizações posteriores relacionadas ao compilador de expressões regulares.
Se sua organização utiliza o GitLab Community Edition ou Enterprise Edition autogerenciado, não espere o próximo ciclo de manutenção para corrigir essa vulnerabilidade. A atualização deve ser tratada como prioridade de segurança.
