GitLab: atualizar com urgência não autoriza improvisar a migração

O GitLab corrigiu a CVE-2026-110264, classificada com CVSS 10,0, que pode permitir execução remota de código sem autenticação em condições não detalhadas publicamente.[3] O estouro de inteiro está na compilação de expressões regulares pelo Onigmo, distribuído com o GitLab, e a exposição alcança versões desde a 7.0, de 2014.[3]

O que muda para quem desenvolve

A ação é voltada a instalações autogerenciadas; GitLab.com já recebeu a correção, assim como versões internas indicadas do GitLab Dedicated.[3] Antes de abrir uma mudança emergencial, descubra quem realmente opera o serviço e qual versão atende às requisições.

As versões corrigidas citadas são 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13.[3] Uma atualização anterior para outro problema, em 12 de outubro, não cobre esta falha.[3] A pergunta correta não é se houve manutenção recente, mas qual correção aquela manutenção entregou.

Na informação disponível em 22 de outubro, não havia exploração conhecida relatada pela empresa nem mitigação temporária oferecida para descartar exposição por configuração.[3] Ausência de exploração conhecida não deve virar justificativa para esperar indefinidamente.

Como aplicar

Prepare um roteiro com versão de origem, etapas intermediárias suportadas, backup, restauração e verificações funcionais. Não presuma que uma instalação muito antiga aceita salto direto para a versão final.

As versões 19.4.3 e 19.3.6 incluem mudanças de banco; em servidor único, sua aplicação implica indisponibilidade, enquanto ambientes multinó podem seguir o procedimento oficial sem parada.[3] Inclua essa diferença na comunicação da janela, sem prometer disponibilidade contínua para uma topologia que não a suporta.

Como ensaio proposto, restaure uma cópia protegida em ambiente isolado e percorra o roteiro planejado. Depois, valide login, leitura e escrita de repositório, permissões e uma pipeline simples. Registre duração e erros. Não use o teste como autorização para expor dados reais fora das regras de acesso.

Cuidados e limites

O pacote de correções também abrange problemas de autenticação e cache em configurações específicas, além da falha no motor de regex.[3] Corrigir o binário não dispensa verificar se a configuração de identidade continua funcionando como esperado.

Minha recomendação é separar três evidências: backup restaurável, migração concluída e versão corrigida em execução. Nenhuma substitui as demais. A urgência aumenta a necessidade de um roteiro curto e verificável, não a utilidade de executar comandos sem conhecer o estado inicial.

Fonte

[3] Fonte: The Hacker News