GitLab atualizado, Ruby vulnerável: a correção precisa chegar ao artefato

O Alpine Linux relatou tentativas de explorar a CVE-2026-97229 em seu GitLab e decidiu reconstruir a instância, substituir segredos e redefinir senhas, mesmo sem evidência conclusiva de execução bem-sucedida de código.[2] A atualização para GitLab 19.3.6 não havia resolvido a exposição da imagem mantida pelo projeto porque o Ruby utilizado continuava vulnerável.[2]

Esse é o ângulo importante: uma atualização só protege o que efetivamente foi corrigido no artefato implantado. A versão visível da aplicação não descreve toda a sua composição.

O que muda para quem desenvolve

A falha está no Onigmo, mecanismo de expressões regulares incorporado ao Ruby e acionado no processamento de configurações de CI.[2] Os pacotes e contêineres oficiais do GitLab incluíam a correção no runtime, mas a imagem do Alpine usava o Ruby padrão.[2]

O relato cita Ruby 3.3.13, 3.4.12 e 4.0.9 como versões corrigidas nas respectivas linhas e orienta baixar novamente alpinelinux/gitlab:19.3.6, cuja edição de 27 de outubro passou a trazer o runtime corrigido.[2] Imagens anteriores com a mesma tag permaneciam vulneráveis.[2]

A análise é direta: tag não deve ser usada como prova suficiente de correção. O registro de uma mudança precisa apontar qual imagem foi construída e qual imagem chegou ao ambiente.

Como aplicar

Escolha um serviço em contêiner e faça uma revisão de composição, sem executar um exploit. Registre a versão da aplicação, a do runtime, as bibliotecas nativas relevantes e o digest do artefato implantado. Compare esse conjunto com as condições do aviso de segurança aplicável.

Depois, confira se a evidência de implantação corresponde ao artefato aprovado. Um pipeline que construiu uma imagem corrigida, mas não a colocou em execução, ainda não encerrou a correção.

Como pequeno experimento, use um ambiente isolado para comparar duas reconstruções da mesma tag. Documente os digests e as versões internas encontradas. O objetivo não é demonstrar uma invasão, mas testar se o processo consegue distinguir artefatos que compartilham um nome.

Inclua também a retenção externa de logs e a revisão de segredos no procedimento de resposta. Decida previamente quais evidências precisam sobreviver à perda do host.

Cuidados e limites

O Alpine não encontrou evidência de execução bem-sucedida, mas não conseguiu descartá-la; parte dos registros já não existia e faltavam logs de conexões de saída.[2] Isso explica a resposta conservadora, não confirma adulteração dos pacotes da distribuição.

As chaves de assinatura de pacotes e lançamentos não ficavam no GitLab, e o projeto realizou verificações de integridade com outras fontes de registros.[2] Também não há indicação para presumir comprometimento de toda imagem oficial alpine.[2]

A lição não é desconfiar indiscriminadamente de uma distribuição. É exigir rastreabilidade entre aviso, componente corrigido e processo realmente em execução.

Fonte

[2] Fonte: The Hacker News