Ing. Calogero Bono
Em 12 de outubro de 2026 o GitLab publicou as versões 19.4.2, 19.3.5 e 19.2.8 para Community Edition e Enterprise Edition. Dentro está a correção da CVE-2026-97229, uma falha com pontuação CVSS 10.0 que pode levar à execução de código arbitrário no servidor. Na quinta-feira, a CISA, agência dos Estados Unidos, confirmou exploração ativa e incluiu a falha no catálogo KEV. Se você administra uma instância própria do GitLab, o assunto é atualizar imediatamente.
Alguns termos antes de entrar nos fatos. CVE é o código que identifica uma vulnerabilidade pública. CVSS é a pontuação de gravidade de 0 a 10. CI/CD indica os pipelines automáticos que compilam, testam e publicam o código. KEV é o catálogo da CISA com as falhas já exploradas em ataques reais. RCE significa execução remota de código, ou seja, rodar comandos no servidor de outra pessoa.
O que é a CVE-2026-97229?
Segundo a página oficial do GitLab, trata-se de um problema de integer overflow no compilador de expressões regulares usado nas configurações de CI/CD. Em certas condições, um usuário não autenticado podia executar código arbitrário no servidor com uma expressão regular construída de propósito, por causa de uma validação insuficiente.
O vetor CVSS é de rede, com complexidade baixa, sem privilégios e sem interação do usuário. Por isso a pontuação chega a 10.0. A falha foi reportada por joaxcar por meio do programa de bug bounty na HackerOne.
Quem está explorando?
Como informa o BleepingComputer, a CISA incluiu a falha no KEV e pediu às agências federais que protegessem os servidores até domingo. Segundo o The Hacker News, o prazo para as agências civis é 1º de novembro de 2026.
A inclusão está ligada a um incidente divulgado pela Alpine Linux. Um agente desconhecido tentou sem sucesso explorar a falha na instância da distribuição nos dias 20 e 21 de outubro de 2026. Enviou configurações de CI feitas sob medida e derrubou os processos worker oito vezes. Em quatro desses casos, o exploit falhou na etapa seguinte. O atacante também baixou a imagem de container do GitLab da Alpine. As novas tentativas de 25 e 26 de outubro foram bloqueadas.
Os mantenedores da Alpine declararam que «The attack came close to working». Acrescentaram que não encontraram provas de sucesso, mas não podem descartá-lo, e por isso reconstruíram a instância do zero. Segundo eles, o repositório aports, os pacotes e as versões de 21 de outubro não foram adulterados.
Quais versões são afetadas?
Para a CVE-2026-97229, o GitLab indica todas as versões da 19.2 anteriores à 19.2.8, da 19.3 anteriores à 19.3.5 e da 19.4 anteriores à 19.4.2. O GitLab.com já usa a versão corrigida. As instâncias GitLab Dedicated receberam uma atualização interna antes da publicação.
O GitLab também informa que a 19.3.4 tinha um bug nas páginas de merge request com a integração Ona ativa. O problema foi corrigido na 19.3.5. A empresa também publicou seis regras de detecção de ameaças para ajudar quem administra instâncias self-managed a identificar tentativas de exploração.
As outras falhas da mesma correção
A versão não traz apenas o caso mais grave. Entre as outras correções, com as pontuações declaradas pelo GitLab.
- CVE-2026-92883, cross-site scripting no realce de sintaxe, CVSS 8.7.
- CVE-2026-16301, um usuário Developer podia iniciar pipelines em branches protegidas, CVSS 8.5.
- CVE-2026-14814, envenenamento do cache de arquivos raw, com possível exposição de variáveis protegidas, CVSS 8.2.
- CVE-2026-81839, pipelines executadas com os privilégios do novo grupo após a transferência de um projeto (somente EE), CVSS 7.7.
- CVE-2026-96893, injeção nas instruções dos agentes de IA do GitLab Duo (somente EE), CVSS 7.3.
Há ainda cinco falhas de gravidade média, incluindo a leitura de notas confidenciais via GraphQL e a exposição de tokens nos logs do GitLab Pages. O quadro completo está na página oficial.
Limitações que você precisa conhecer
Não sabemos quantas instâncias foram comprometidas. A Shadowserver, citada pelo BleepingComputer, rastreia quase 2.800 instâncias Community Edition expostas na Internet, mas não informa quantas já estão atualizadas. Esse número não deve ser lido como o número de sistemas vulneráveis.
As fontes não dizem quem é o atacante nem se há outros casos além da Alpine. O detalhe técnico do exploit não foi publicado. O GitLab torna as informações das falhas públicas 90 dias após o lançamento da correção, então outros detalhes podem aparecer.
O que muda para quem trabalha com tecnologia
Se você tem um GitLab self-managed para o seu escritório ou a sua empresa, a prioridade é a versão. Uma falha sem autenticação em um servidor que guarda código, segredos e pipelines é um risco concreto, inclusive para os seus clientes. Quem hospeda o repositório no GitLab.com já está protegido pela plataforma.
A lição da Alpine é prática. Se você não pode descartar um comprometimento, reconstrua a instância e troque os segredos. Automatizar as instalações ajuda, como explicamos no guia sobre Ansible para configuração e deploy. Nos servidores também é preciso disciplina com atualizações, tema que tratamos no caso de Fragnesia e PHP2Shell. Outro exemplo recente de varreduras depois da correção é o caso do Oracle E-Business Suite. Se você não tem tempo para acompanhar tudo, existem hospedagem e servidores gerenciados com atualizações de segurança.
Nossa opinião
O caso mostra como o intervalo entre a correção e o ataque é curto. A correção é de 12 de outubro, e as tentativas na Alpine começaram no dia 20, ou seja, oito dias depois. Quem atualiza só no ciclo mensal seguinte chega tarde demais.
Fica também uma observação crítica. O GitLab é citado como presente em mais da metade das Fortune 100, e o BleepingComputer lista uma sequência de falhas de gravidade máxima no mesmo período, incluindo outras duas de criticidade máxima. Para um serviço que guarda o código e os segredos de uma empresa, essa frequência pesa. Não basta dizer que o GitLab corrige rápido, mesmo que ele corrija. Quem decide manter tudo internamente precisa contar com um monitoramento contínuo ou confiar essa tarefa a quem faz isso profissionalmente.
Perguntas frequentes
Devo atualizar o GitLab agora?
Sim, se a sua instância for self-managed e estiver nas versões indicadas. O GitLab recomenda a atualização imediata para 19.4.2, 19.3.5 ou 19.2.8. A exploração ativa foi confirmada pela CISA.
O GitLab.com corre risco?
Não, segundo o GitLab. O GitLab.com já usa a versão corrigida e as instâncias Dedicated foram atualizadas antes do lançamento público.
É preciso ter uma conta para explorar a falha?
Não. O vetor CVSS indica que não é necessário nenhum privilégio e que não há interação do usuário. O ataque passa por uma configuração de CI/CD construída de propósito.
Como saber se fui atacado?
As fontes não trazem uma forma certa de verificar. O GitLab publicou seis regras de detecção para instâncias self-managed. A Alpine observou falhas repetidas nos workers depois de configurações de CI anômalas.
Basta atualizar?
Depende. Se a instância estava exposta e sem correção nos dias anteriores, não é possível descartar um comprometimento. A Alpine optou por reconstruí-la do zero.
O que acompanhar nas próximas semanas, entre correções e verificações
Nos próximos dias, o importante é descobrir se surgirão outros casos além da Alpine e se detalhes técnicos serão divulgados. Três recomendações.
- Atualize para a versão mais recente disponível do seu ramo e confira o número da versão após a instalação.
- Verifique os logs dos workers em busca de falhas repetidas e configurações de CI incomuns, usando as regras de detecção do GitLab.
- Se a instância estava exposta e sem atualização, troque tokens e variáveis protegidas e avalie a reconstrução.
