Um compilador de expressões regulares tornou-se uma porta de entrada

A GitLab corrigiu a 12 de outubro a CVE-2026-97229, um excesso de inteiros com CVSS 10,0 no compilador que trata expressões regulares na configuração de pipelines de CI/CD. Em certas condições, diz o aviso da GitLab, um utilizador sem autenticação podia executar código arbitrário no servidor GitLab através de uma expressão regular manipulada numa configuração de CI/CD.

O aviso não explica essas condições, e nenhum dos três relatos que lemos o faz. Um investigador com o pseudónimo joaxcar comunicou a falha através do programa de recompensas HackerOne da GitLab. O GitLab.com já corre a versão corrigida e os clientes do GitLab Dedicated nada têm de fazer, mas os administradores de instâncias autogeridas têm de atualizar de imediato. Segundo a heise, a 13 de outubro a GitLab não tinha comunicado ataques.

Linha de versõesVulnerávelCorrigida em
GitLab 19.2Anteriores à 19.2.819.2.8
GitLab 19.3Anteriores à 19.3.519.3.5
GitLab 19.4Anteriores à 19.4.219.4.2

Na mesma versão foram corrigidas três falhas de gravidade alta. A CVE-2026-92883 (8,7) é uma falha de cross-site scripting. A CVE-2026-16301 (8,5) permite a um utilizador com a função Developer executar pipelines em ramos protegidos. A CVE-2026-14814 (8,2) pode envenenar respostas em cache e expor variáveis de ambiente protegidas. A heise contabiliza cinco falhas de gravidade alta no total.

Três falhas críticas da GitLab em poucas semanas

A CVE-2026-97229 é a terceira falha crítica da GitLab nas últimas semanas, e a de setembro mostrou a rapidez com que os atacantes se movem.

CVECVSSComponenteConsequência noticiada
CVE-2026-8570610,0GitLab CE e EELeitura sem autenticação de dados sensíveis, como credenciais e segredos, com sondagens horas depois da divulgação e inclusão na lista da CISA um dia após a correção
CVE-2026-909709,9AI GatewayUm utilizador autenticado com acesso à Duo Agent Platform podia sair da sandbox de modelos de prompts e executar comandos
CVE-2026-9722910,0Compilador de expressões regulares de CI/CDExecução de código sem autenticação, sem ataques comunicados a 13 de outubro

Depois da falha de setembro, a CISA deu três dias às agências federais dos Estados Unidos para protegerem os seus sistemas. Desde novembro de 2021 assinalou cinco falhas da GitLab usadas em ataques, uma delas por grupos de ransomware. A 13 de outubro não tinham sido comunicados ataques à nova falha, mas o ritmo de setembro é aquele com que convém planear.

Porque é que um servidor de pipelines vale um ataque

Um servidor de CI/CD fica entre o código-fonte e a produção, por isso executar código nele vale mais para um atacante do que na maioria dos servidores empresariais.

Costuma guardar os segredos de que as pipelines precisam para compilar, testar e implementar, como tokens de acesso e chaves de implementação, e pode alterar o que chega aos clientes. A GitLab diz ter mais de 30 milhões de utilizadores registados e que mais de 50 por cento das Fortune 100 a usam. Alojar por conta própria troca comodidade por controlo sobre onde estão o seu código e os seus dados, e passa para si o dever de aplicar correções. Pode ser uma escolha deliberada para equipas com requisitos de residência de dados, e é também a razão por que o dia de correções do fornecedor passa a ser o seu prazo.

Um plano de 72 horas para equipas autogeridas

Trate isto como um trabalho de 72 horas para cada instância acessível a partir da internet e comece pela verificação da versão.

Primeiro, leia a sua versão instalada e compare-a com 19.2.8, 19.3.5 e 19.4.2, e confirme depois os números de compilação exatos no aviso da GitLab. Segundo, agende a atualização para dentro de 72 horas, começando por qualquer instância acessível a partir da internet. Terceiro, até estar feito, limite quem pode chegar ao servidor e quem pode editar os ficheiros de configuração de CI/CD.

Quarto, se não puder excluir a exposição, rode os segredos guardados como variáveis de pipeline depois de aplicada a correção. Quinto, subscreva os avisos de segurança da GitLab para que o próximo chegue a uma pessoa no mesmo dia. As 72 horas são a janela que sugerimos nós, não um prazo da GitLab.