Atualizar GitLab self-managed (CVE-2026-110264)
Em 21 de outubro de 2026 o GitLab corrigiu o CVE-2026-110264, uma falha CVSS 10.0 que permite executar código no servidor sem autenticação e afeta o GitLab self-managed desde a versão 7.0, de 2014. Nove dias antes tinha corrigido o CVE-2026-97229, também 10.0. O GitLab.com já está atualizado; as instalações próprias dependem de você.
Você tem esta vulnerabilidade? Atualizamos o seu GitLab para a versão corrigida do seu ramo, planejamos a parada se as migrações de banco de dados exigirem e revisamos runners, tokens e logs.
$ sudo gitlab-rake gitlab:env:info | grep -A1 "GitLab information"GitLab informationVersion: 19.4.2-ee# 19.4.2 corrige o CVE-2026-97229, não o CVE-2026-110264$ cat /opt/gitlab/embedded/service/gitlab-rails/VERSION19.4.2-ee# Também no navegador: https://seu-gitlab/helpPara o ramo 19.4: atualizar para 19.4.3Duas falhas CVSS 10.0 em nove dias
Quem atualizou em 12 de outubro por causa do CVE-2026-97229 precisa atualizar de novo: aquela correção não cobre o CVE-2026-110264, que atinge todas as versões desde 2014.
O CVE-2026-110264 é um estouro de inteiro ao compilar uma expressão regular manipulada no Onigmo, o motor de expressões regulares do Ruby que o GitLab inclui e corrige nos seus próprios pacotes. O GitLab o traz desde a 7.0, e por isso a falha vai tão longe. O GitLab não explicou de quais condições um atacante precisa, então não dá para se descartar pela configuração, e não oferece mitigação temporária: a única correção é atualizar.
Em 12 de outubro o GitLab tinha corrigido o CVE-2026-97229, também CVSS 10.0: execução de código sem autenticação por meio de uma expressão regular manipulada na configuração de CI/CD, nas versões 19.2 a 19.4 (corrigida em 19.2.8, 19.3.5 e 19.4.2). Existe uma prova de conceito pública.
Em 22 de outubro, o GitLab não relata exploração do CVE-2026-110264, e ele não consta no catálogo KEV da CISA. O GitLab publicou duas regras Sigma para procurar tentativas, “Onigmo native worker crash” e “Org mode render error burst”. As instâncias do GitLab Dedicated em 19.3.5-internal0 ou 19.4.2-internal0 e posteriores já têm a correção.
Fontes: The Hacker News: CVE-2026-110264 · The Hacker News: CVE-2026-97229
Versões corrigidas do GitLab
Vale para o GitLab CE e EE instalado por você (Omnibus, Docker, Helm). Se a sua versão é anterior à do seu ramo, você está afetado pelo CVE-2026-110264.
| Se você tem | Atualize para | Nota |
|---|---|---|
| 19.5 (antes de 19.5.1) | 19.5.1 | |
| 19.4 (antes de 19.4.3) | 19.4.3 | Migrações de BD: parada com um só nó |
| 19.3 (antes de 19.3.6) | 19.3.6 | Migrações de BD: parada com um só nó |
| 19.2 (antes de 19.2.9) | 19.2.9 | |
| 19.1 (antes de 19.1.9) | 19.1.9 | |
| 19.0 (antes de 19.0.10) | 19.0.10 | |
| 7.0 – 18.11 (antes de 18.11.13) | 18.11.13 | Pode exigir versões intermediárias |
Verifique isto
- Você tem GitLab CE ou EE instalado no seu servidor, em Docker ou na sua nuvem, não no GitLab.com.
- A versão exibida em
/helpé anterior à do seu ramo na tabela. - Você atualizou em 12 de outubro para 19.2.8, 19.3.5 ou 19.4.2: continua afetado pelo CVE-2026-110264.
- Você está na 18.10 ou anterior: o destino é 18.11.13 ou uma 19.x, e o GitLab exige paradas intermediárias no caminho de atualização.
- A sua instância é acessível pela internet, mesmo com o cadastro de usuários fechado: a falha não precisa de conta.
Sem mitigação temporária
O GitLab não oferece nenhum workaround para o CVE-2026-110264. O que dá para preparar é a própria atualização, para que dê certo de primeira.
- 01 O GitLab não disse quais condições são necessárias para explorar a falha, então nenhuma configuração deixa você de fora.
- 02 Num servidor de um só nó, as versões 19.4.3 e 19.3.6 executam migrações de banco de dados durante a atualização e o GitLab fica parado até que terminem.
- 03 Com vários nós é possível aplicar sem parada seguindo o procedimento de zero-downtime do GitLab.
- 04 Antes de mexer em qualquer coisa: backup do banco de dados e dos repositórios, e de
gitlab-secrets.jsonegitlab.rb, que não entram no backup padrão.
Sete passos, nesta ordem
Aplicamos o mesmo procedimento em cada servidor: primeiro saber qual versão roda em cada lugar, depois corrigir e, no fim, verificar que ninguém entrou antes do patch.
Inventário de versões
Registramos versão e edição (CE ou EE), tipo de instalação (Omnibus, Docker, Helm), número de nós, runners registrados e de onde a instância é acessível.
Mitigação imediata
Sem workaround oficial, o que se pode fazer enquanto a janela é preparada é reduzir quem chega à instância, por exemplo deixando-a só atrás da VPN se a sua equipe puder trabalhar assim.
Atualização
Backup, caminho de atualização com as paradas que o GitLab exige se você vem de uma versão antiga e salto para a versão corrigida do seu ramo. Se as migrações obrigarem a parar, escolhemos o momento com você.
Verificação
Verificamos a versão em /help, que as migrações de banco terminaram, que os runners conectam e que os pipelines voltam a passar.
Revisão de indícios de comprometimento
Aplicamos as regras Sigma publicadas pelo GitLab nos logs e revisamos usuários, tokens de acesso pessoal e chaves SSH criados recentemente.
Rotação de segredos, se necessário
Se houver indícios, trocamos tokens de runners, tokens pessoais e de deploy, variáveis de CI/CD e as chaves que os pipelines usam para fazer deploy.
Acompanhamento de novos avisos
Deixamos registrada a versão, o caminho de atualização e o calendário de patches do GitLab, para que a próxima atualização não comece do zero.
Por que uma atualização do GitLab dá errado
O seu GitLab está há anos sem atualizar?
Consultoria gratuita →Perguntas frequentes sobre o CVE-2026-110264
Qual versão do GitLab corrige o CVE-2026-110264?
Já atualizei em 12 de outubro. Preciso atualizar de novo?
Uso o GitLab.com. Preciso fazer algo?
A atualização deixa o GitLab parado?
Há alguma mitigação se eu não puder atualizar hoje?
Conte qual GitLab você tem
Com a versão, o tipo de instalação e o número de nós dizemos o caminho de atualização e se vai ser preciso parar.
Conte-nos seu desafio. Propomos uma solução.
Sem compromisso. Em menos de 24 horas, você recebe uma proposta com escopo, cronograma e orçamento. Sem letras miúdas.