Falha crítica no GitLab afeta versões desde 2014

Em resumo

Em 21 de outubro de 2026, o GitLab corrigiu a CVE-2026-110264, uma falha crítica no GitLab com nota 10 de 10: em certas condições, alguém sem login consegue executar código no servidor. Ela atinge toda instalação própria do GitLab CE e EE desde a versão 7.0, de 2014. A correção é atualizar para 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13. Quem usa o GitLab.com ou o GitLab Dedicated já está protegido.

O que aconteceu

O GitLab publicou na quarta-feira, 21 de outubro, uma rodada de correções com 12 falhas de segurança. A mais grave é a CVE-2026-110264, com nota 10 no CVSS, a escala usada para medir a gravidade de vulnerabilidades. Ela permite execução remota de código: o atacante faz o servidor rodar comandos dele, sem precisar de usuário nem senha.

A falha está no Onigmo, o motor de expressões regulares do Ruby que vem embutido no GitLab. Ao compilar uma expressão regular montada de propósito, o motor faz uma conta de tamanho que passa do limite do tipo numérico e “dá a volta” (um estouro de inteiro). Em falhas desse tipo, o tamanho errado faz o programa gravar dados fora da área de memória reservada, e é por aí que o atacante chega à execução de código.

O GitLab não divulgou o caminho exato do ataque nem as condições necessárias, para dar tempo de os administradores atualizarem. Por isso não dá para descartar a exposição olhando a configuração do servidor: se a sua versão está na faixa afetada, considere a instância vulnerável.

A falha foi relatada pelo pesquisador joaxcar pelo programa de recompensa por falhas do GitLab no HackerOne. Até 22 de outubro não havia confirmação de ataques usando a falha, e a CVE não estava no catálogo de falhas exploradas da CISA, a agência de cibersegurança dos Estados Unidos. Já há na internet código que se diz capaz de explorar a falha. Ninguém o verificou: não rode para testar o seu servidor, porque ele pode trazer malware.

Quem atualizou em 12 de outubro precisa atualizar de novo

Nove dias antes, em 12 de outubro, o GitLab corrigiu a CVE-2026-97229, outra falha com nota 10 no mesmo compilador de expressões regulares, relatada pelo mesmo pesquisador. A correção saiu nas versões 19.4.2, 19.3.5 e 19.2.8, e essas versões continuam vulneráveis à falha nova.

A diferença é o alcance. A falha de 12 de outubro afetava só as linhas 19.2 a 19.4. A de agora vai até a versão 7.0, e por isso o GitLab levou a correção também para 19.1, 19.0 e 18.11, fora da política normal, que cobre só a versão atual e as duas anteriores.

Se você pode atualizar

Estas são as versões com a correção, por linha:

Versão em uso	Atualize para
19.5	19.5.1
19.4	19.4.3
19.3	19.3.6
19.2	19.2.9
19.1	19.1.9
19.0	19.0.10
18.11 ou anterior	18.11.13 ou uma versão mais nova

Descubra a versão na área administrativa do GitLab ou no terminal, com sudo gitlab-rake gitlab:env:info. Antes de atualizar, faça um backup com sudo gitlab-backup create e guarde à parte o /etc/gitlab/gitlab.rb e o /etc/gitlab/gitlab-secrets.json, que o backup não inclui.

Na instalação por pacote Linux, fique na sua linha e indique a versão. Na linha 19.5, por exemplo:

sudo apt update && sudo apt install gitlab-ee=19.5.1-ee.0

Na edição Community, use gitlab-ce=19.5.1-ce.0. No Docker, troque a tag da imagem pela versão corrigida e suba o container de novo. Depois, confira a versão outra vez.

Reserve uma janela curta. As versões 19.4.3 e 19.3.6 trazem migrações de banco de dados, e numa instalação de um servidor só o GitLab fica fora do ar até elas terminarem. Instalações com vários servidores podem seguir o procedimento de atualização sem parada.

Versões anteriores à 18.11

Quem está numa versão mais antiga não tem correção na própria linha e não consegue pular direto para uma versão corrigida. O GitLab exige paradas obrigatórias no caminho: a partir da 17.5, elas ficam nas versões x.2, x.5, x.8 e x.11 de cada versão principal. Em cada parada, as migrações em segundo plano precisam terminar antes do passo seguinte. A ferramenta Upgrade Path, mantida pelo suporte do GitLab, calcula as paradas a partir da sua versão. Dependendo da distância, são horas de trabalho, e é por isso que a próxima seção existe.

Se você não pode atualizar agora

O GitLab não publicou nenhuma alternativa à atualização. A falha dispensa login, mas o atacante ainda precisa alcançar o GitLab pela rede. Enquanto a atualização não sai, o que resta é reduzir quem chega até ele:

Tire o GitLab da internet aberta. Deixe o acesso só por VPN, por uma lista de IPs no firewall ou no proxy, ou ponha na frente uma camada de autenticação, como o Cloudflare Access ou outro proxy de identidade, que pede login antes de a requisição chegar ao GitLab.
Libere o que precisa chegar. Runners de CI, webhooks e integrações também falam com o GitLab. Libere os endereços deles antes de fechar o acesso, ou o CI para.
Monitore. O GitLab publicou duas detecções para essa falha no TLDR, o repositório de regras Sigma da equipe de segurança dele: “Onigmo native worker crash” (queda de um processo do GitLab no motor de expressões regulares) e “Org mode render error burst” (rajada de erros na renderização de arquivos Org). Leve as duas para a sua ferramenta de logs.
Calcule o caminho de atualização hoje e marque a data, para que o fechamento do acesso seja uma medida de dias, não de meses.

Depois de atualizar, procure sinais de invasão

O GitLab guarda o código-fonte e, quase sempre, as credenciais que o CI usa para publicar em produção. Por isso uma invasão nele vai além do servidor. Depois de atualizar, confira:

usuários novos, principalmente administradores, e tokens de acesso pessoal que ninguém reconhece;
runners registrados recentemente e variáveis de CI/CD alteradas;
webhooks, chaves de deploy e chaves SSH novas;
processos do usuário do GitLab abrindo um shell, e arquivos novos em /tmp ou nas pastas do GitLab.

Se algo não bater, trate como invasão: isole o servidor, troque as variáveis de CI/CD, os tokens e as chaves de deploy, e confira o que os pipelines publicaram desde então.

O que fazer hoje

Descubra a versão de cada GitLab que você mantém, inclusive os de teste e os esquecidos.
Atualize para a versão corrigida da sua linha. Quem atualizou em 12 de outubro atualiza de novo.
Se não der para atualizar hoje, feche o acesso público ao GitLab e calcule o caminho de atualização.
Revise usuários, tokens, runners e variáveis de CI/CD.

Na mesma semana, o PHP também corrigiu duas falhas críticas. Se você mantém sites em PHP, veja o nosso post sobre o PHP2Shell. Atualizar o GitLab, planejar o caminho de versões antigas e fechar o acesso enquanto isso fazem parte da nossa gestão de servidores.