Se a sua empresa executa o GitLab no próprio servidor, atualize hoje. Em 12 de outubro de 2026, o GitLab lançou um patch de segurança crítico que corrige 24 vulnerabilidades. A pior, CVE-2026-97229, recebeu a pontuação de gravidade mais alta possível: 10 de 10. Ela permite que alguém sem conta no seu servidor execute o próprio código nele. Todo servidor que roda as versões 19.2 anteriores à 19.2.8, 19.3 anteriores à 19.3.5 ou 19.4 anteriores à 19.4.2 é afetado. A única correção indicada pelo GitLab é atualizar para 19.4.2, 19.3.5 ou 19.2.8. Se você usa o serviço em nuvem do GitLab.com, não precisa fazer nada.

O que é o GitLab e por que um empresário deveria se importar?

O GitLab é onde sua equipe técnica guarda o código-fonte dos seus sistemas e aplicativos, e onde novas versões são compiladas e enviadas para os seus servidores. Muitas empresas o executam em um servidor interno em vez do serviço em nuvem, para manter o código e os dados dentro da organização. Esse servidor costuma guardar mais do que o dono imagina: o código-fonte completo, as senhas dos bancos de dados, as chaves que conectam você a gateways de pagamento e serviços do governo, e a permissão para publicar nos servidores que seus clientes usam. Quem o controla pode ler tudo isso e pode alterar seu código antes que ele chegue aos seus clientes.

O que exatamente o GitLab anunciou?

Segundo o anúncio oficial do patch do GitLab, a falha está na parte que processa expressões regulares dentro das configurações dos pipelines de build e deploy (CI/CD). Uma expressão regular é um pequeno trecho de texto que descreve um padrão de busca. O anúncio diz que a falha pode permitir que um usuário não autenticado execute código arbitrário no servidor do GitLab por meio de uma expressão regular especialmente criada, devido à validação insuficiente dessas expressões. Um pesquisador a relatou pelo programa de recompensa por bugs do GitLab no HackerOne.

O anúncio não diz que a falha foi explorada. Mas uma pontuação de 10 significa que ela pode ser explorada pela internet, sem senha e sem ajuda de nenhum funcionário. Os atacantes costumam começar a procurar falhas como esta poucos dias depois que uma correção se torna pública, porque a própria correção aponta onde está a fraqueza.

O que mais o patch inclui?

O mesmo patch corrige outras 23 vulnerabilidades, cinco delas classificadas como altas:

  • Uma injeção de script malicioso (XSS) no realce de sintaxe, com pontuação 8.7.
  • Uma falha de autorização ao criar pipelines, com pontuação 8.5.
  • Uma expressão regular permissiva demais que afeta o acesso a arquivos, com pontuação 8.2.
  • Uma falha de autorização nas políticas de execução de pipelines da edição paga, com pontuação 7.7.
  • Uma falha de injeção de prompt no agente de IA GitLab Duo da edição paga, com pontuação 7.3.

Portanto, versões anteriores à 19.2, que não são afetadas pela falha crítica, não estão necessariamente seguras. A política oficial de manutenção do GitLab diz que as correções de segurança são aplicadas apenas à versão atual e às duas versões mensais anteriores. Um servidor em qualquer versão mais antiga não recebe mais nenhuma correção de segurança e precisa de atualização de qualquer forma.

Quem precisa agir?

  • Usuários da nuvem GitLab.com: nada a fazer; o GitLab diz que o serviço já roda a versão corrigida.
  • Clientes do GitLab Dedicated: também nada a fazer, segundo o anúncio.
  • Quem executa o GitLab no próprio servidor: atualize imediatamente. Essa é a recomendação explícita do GitLab para toda instalação autogerenciada.
  • Quem não sabe onde o seu GitLab roda: pergunte hoje à sua equipe ou ao fornecedor que desenvolveu seus sistemas. Muitos servidores internos foram configurados por um fornecedor anterior e depois esquecidos.

Passos práticos para esta semana

  1. Descubra a versão: peça ao seu responsável técnico que abra a página de Ajuda no GitLab, leia o número da versão mostrado ali e compare com os números acima.
  2. Agende a atualização hoje, não no fim do mês: segundo o anúncio do GitLab, um servidor de nó único fica fora do ar durante o patch até que as migrações do banco de dados terminem, enquanto configurações com vários nós podem receber o patch sem interrupção se o procedimento adequado sem tempo de inatividade for seguido. Uma hora fora do ar fora do horário comercial custa muito menos do que um servidor comprometido.
  3. Se você está na 19.3: vá direto para a 19.3.5, não para a 19.3.4. O anúncio observa que a 19.3.4 tinha um bug que afetava as páginas de merge request quando a integração com o Ona estava ativada, corrigido na 19.3.5.
  4. Reduza a exposição à internet: se ninguém de fora da empresa precisa acessar seu servidor GitLab, faça com que ele aceite conexões apenas da rede da empresa ou por meio de uma VPN. Isso não substitui o patch, mas estreita a porta da próxima vez.
  5. Verifique depois do patch: revise usuários, chaves e tokens de acesso criados recentemente. Se aparecer algo que ninguém reconhece, troque as senhas e chaves armazenadas no servidor.

Os passos de atualização para cada método de instalação estão no guia oficial de atualização do GitLab.

A visão da Origami

Usamos o GitLab todos os dias, já que nossos repositórios ficam lá, por isso acompanhamos seus anúncios de segurança tão de perto quanto nossas faturas. A lição vai além do GitLab: todo sistema que você mesmo executa para manter seus dados em casa vem com o dever de aplicar o patch no mesmo dia em que a correção sai. O problema que mais vemos não é essa decisão em si, mas a falta do nome de quem é responsável pelas atualizações. Um servidor que um fornecedor configurou há três anos, e que ninguém sabe quem mantém, é a primeira coisa que um atacante procura. Dissemos o mesmo sobre a falha das lojas Magento: aplicar o patch não basta se ele chega tarde. Se você precisa de alguém para revisar seus servidores ou assumir as atualizações deles, fale conosco.

Fontes