GitLab: a configuração de CI/CD também precisa de uma fronteira de segurança

O GitLab corrigiu a CVE-2026-97229, um estouro de inteiro com CVSS 10,0 que, sob determinadas condições, permite execução de código sem autenticação por meio de uma expressão regular em configuração de CI/CD.[1] O alvo é o servidor GitLab, não apenas o ambiente em que um runner executa um job.[1] A distinção muda a prioridade: revisar o código da aplicação não substitui corrigir a plataforma que o recebe.

O que muda para quem desenvolve

As versões corrigidas são 19.2.8, 19.3.5 e 19.4.2; as versões anteriores dessas respectivas linhas estão afetadas.[1] A atualização também resolve problemas de execução de JavaScript nas sessões de outros usuários, autorização de pipelines descendentes em branches protegidas e envenenamento do cache de arquivos brutos.[1]

No último caso, pipelines podem consumir conteúdo adulterado e potencialmente expor variáveis de ambientes protegidos.[1] Para a engenharia, o conjunto aponta três fronteiras diferentes: processamento de configuração, autorização para executar trabalho e integridade dos dados consumidos pelo build. Eu trataria cada fronteira como um item independente de revisão, não como um único alerta encerrado pelo scanner.

A análise é simples: quem entrega um arquivo ao sistema não deveria, por isso, ganhar autoridade sobre o servidor ou sobre segredos de outro projeto. Colocar algo em YAML não torna seu processamento automaticamente inofensivo.

Como aplicar

Comece pelo inventário das instâncias autogerenciadas. Registre a versão efetivamente em execução, a linha de manutenção, o responsável pela atualização e a exposição de rede. Compare esse inventário com as versões corrigidas da notícia, sem presumir que atualizar uma instância atualizou todas.[1]

Depois, prepare uma janela de mudança com cópia de segurança e procedimento de recuperação adequado ao ambiente. Em homologação, valide login, leitura de repositórios, execução de uma pipeline representativa e acesso aos artefatos. Na produção, confira a versão após a implantação e registre o resultado dessas verificações.

Faça também um teste de autorização com contas de laboratório: um usuário com papel Developer deve conseguir executar somente os fluxos previstos pela política do projeto. Inclua pipelines descendentes e branches protegidas no roteiro. Não use dados sensíveis reais nem tente reproduzir exploração em uma instância pública.

Por fim, liste quais jobs recebem variáveis protegidas e de onde vem o conteúdo utilizado no build. Se um job depende de arquivos remotos, estabeleça como verificar sua identidade e integridade antes de liberar credenciais.

Cuidados e limites

A reportagem não descreve exploração confirmada dessa CVE específica.[1] Os antecedentes de outras falhas do GitLab não comprovam comprometimento pela nova vulnerabilidade.[1] Portanto, não publique um diagnóstico de invasão só porque encontrou uma versão afetada.

Ao mesmo tempo, eu não consideraria a atualização uma prova de que o passado está limpo. Se houver sinais concretos de incidente, investigue acessos, alterações e uso de credenciais separadamente. Corrigir a entrada e entender o que já passou por ela são tarefas diferentes.

Fonte

[1] Fonte: The Hacker News