Falha crítica no GitLab permite execução de código sem autenticação
O GitLab corrigiu uma vulnerabilidade de gravidade máxima que pode permitir a execução remota de código em servidores instalados e administrados pelas próprias organizações. Registrada como CVE-2026-110264, a falha recebeu pontuação CVSS 10.0, o nível mais alto da escala. O aviso sobre a correção foi publicado em 21 de outubro.
O problema decorre de um estouro de inteiro durante a compilação de expressões regulares. Em determinadas condições, uma expressão especialmente preparada pode provocar o transbordamento e levar à execução de código no servidor. Para tentar explorar a falha, não é necessário ter uma conta, conhecer credenciais ou convencer alguém a realizar uma ação: o ataque pode ser iniciado remotamente pela rede.
A vulnerabilidade afeta instalações self-managed em versões do GitLab a partir da 7.0, lançada em 2014. As atualizações que corrigem o problema são as versões 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13. Administradores devem confirmar qual versão está em operação e aplicar o pacote correspondente à linha utilizada.
Uma atualização crítica distribuída em 12 de outubro não resolve essa vulnerabilidade. Ela corrigiu a CVE-2026-97229, também avaliada com CVSS 10.0 e relacionada ao processamento de expressões regulares, mas contemplou apenas a versão 19.2 e as posteriores. As correções recém-publicadas estão um patch à frente daquele conjunto.
O serviço GitLab.com já foi atualizado. Clientes do GitLab Dedicated que utilizam versões a partir de 19.3.5-internal0 e 19.4.2-internal0 também receberam o pacote. Para instalações próprias, a aplicação da atualização inclui migrações no banco de dados e pode causar indisponibilidade em ambientes com um único nó. Por isso, é importante planejar a janela de manutenção e verificar previamente os procedimentos de recuperação.
O pacote de correções reúne 12 vulnerabilidades. A falha crítica foi comunicada por joaxcar por meio do programa de recompensas de segurança da empresa. O risco merece atenção especial porque plataformas de CI/CD podem armazenar credenciais de serviços em nuvem, chaves de acesso e mecanismos usados para assinar artefatos destinados à produção.
Até 22 de outubro, não havia relatos de exploração da CVE-2026-110264. Na mesma data, ela ainda não constava no NVD nem na lista de vulnerabilidades exploradas da CISA. A ausência de registros, contudo, não elimina o perigo: vulnerabilidades sem autenticação e com pontuação máxima podem ser rapidamente incorporadas a tentativas automatizadas de ataque.
Para organizações que não conseguem atualizar de imediato, o GitLab disponibilizou duas regras de detecção. Elas ajudam a identificar sinais como travamentos do compilador de expressões regulares e erros repetidos durante a renderização de marcação. Essas medidas servem para monitoramento e resposta, mas não substituem a instalação da versão corrigida.
Uma primeira providência é inventariar todas as instâncias self-managed, incluindo ambientes de teste, desenvolvimento e contingência. Em estruturas com vários servidores, a checagem deve abranger cada nó e componente relevante, evitando que uma instalação esquecida permaneça vulnerável mesmo após a atualização do ambiente principal.
Também é recomendável revisar os registros de aplicação e do sistema em busca de falhas incomuns no processamento de expressões regulares, reinicializações inesperadas ou erros recorrentes de renderização. Caso haja indícios de acesso indevido, a organização deve preservar os logs, investigar a origem das requisições e avaliar se credenciais armazenadas no servidor precisam ser revogadas ou substituídas.
Como a plataforma pode participar diretamente da cadeia de desenvolvimento e entrega de software, a resposta não deve se limitar à atualização. Equipes de segurança e infraestrutura devem conferir permissões, tokens, segredos e chaves acessíveis à instância, além de verificar se artefatos recentes foram produzidos ou assinados em circunstâncias suspeitas.
Por fim, a atualização deve ser acompanhada de testes funcionais e da confirmação de que as migrações de banco foram concluídas corretamente. Em sistemas de nó único, uma janela de manutenção planejada reduz o impacto operacional; em qualquer arquitetura, manter um backup recente e um plano de recuperação ajuda a restaurar o serviço caso surjam problemas durante o processo.