Pular para o conteúdo
Oneck Creative

GitLab corrige falha de nota máxima que permite invadir o servidor sem login

Quem mantém o próprio GitLab precisa atualizar: a falha CVE-2026-110264 permite rodar comandos no servidor sem conta nem senha. O GitLab.com já está corrigido.

Escrito por
5 min de leitura
GitLab corrige falha de nota máxima que permite invadir o servidor sem login

O GitLab corrigiu em 21 de outubro de 2026 uma falha com nota 10, a máxima na escala CVSS, que permite a alguém sem login executar código no servidor. Quem usa o GitLab.com não precisa fazer nada. Quem mantém o próprio GitLab, instalado num servidor da empresa ou numa nuvem contratada, precisa atualizar.

Esse é o caso de muitas software houses, equipes de tecnologia e empresas que guardam ali o código dos seus sistemas, as chaves de publicação e as senhas que ligam o sistema ao banco de dados e ao meio de pagamento.

GitLab: falha com nota 10CVE-2026-110264, execução de código sem loginAtualize para19.5.1 ou 19.4.319.3.6 ou 19.2.919.1.9 ou 19.0.1018.11.13Já corrigidoGitLab.comGitLab Dedicated19.3.5-internal019.4.2-internal0Afetadas: da 7.0 até antes dasversões corrigidas de cada linha.Fonte: GitLab, patch release 19.5.1 (21/10/2026)

O que é a falha

A falha recebeu o código CVE-2026-110264. Segundo o comunicado do GitLab, trata-se de um estouro de inteiro no compilador de expressões regulares, que permite a um usuário não autenticado executar código no servidor. Em português claro: um invasor, sem conta e sem senha, consegue rodar comandos na máquina onde o GitLab está instalado.

As versões afetadas cobrem uma faixa enorme, da 7.0 até antes da 18.11.13, e várias linhas recentes:

  • 19.0 antes da 19.0.10;
  • 19.1 antes da 19.1.9;
  • 19.2 antes da 19.2.9;
  • 19.3 antes da 19.3.6;
  • 19.4 antes da 19.4.3;
  • 19.5 antes da 19.5.1.
As versões corrigidas são 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13, para as edições Community (CE) e Enterprise (EE).

O GitLab.com já está corrigido. O GitLab Dedicated, a versão hospedada pelo próprio GitLab para cada cliente, está corrigido a partir da 19.3.5-internal0 ou da 19.4.2-internal0.

Já está sendo explorada?

Até a manhã de 23 de outubro, não. O GitLab não fala em exploração, e a falha não aparece no catálogo de vulnerabilidades exploradas da CISA, a agência de segurança dos Estados Unidos. Também não encontramos exploit público.

Isso não é motivo para deixar para depois. Falha com nota máxima e sem necessidade de login costuma atrair atacantes logo depois que a correção sai, porque comparar a versão antiga com a nova ajuda a entender o problema. O caso recente do PHP mostrou isso: a exploração começou antes mesmo de a correção ser divulgada.

Segundo o BleepingComputer, a Shadowserver, organização que monitora a internet, rastreia mais de 2.700 instalações do GitLab CE expostas na rede. Não se sabe quantas estão vulneráveis nem quantas são do Brasil.

As outras 12 falhas

A mesma atualização corrige mais 12 problemas. Dois são de gravidade alta:

  • CVE-2026-15723 (nota 8,2), ligada à autenticação por OmniAuth e LDAP;
  • CVE-2026-112212 (nota 7,5), de envenenamento de cache em OAuth e OIDC, os protocolos de login com outras contas.
Tem GitLab próprio?O que fazer depois do alerta de 21/101Descubra se é própriogitlab.com já está corrigido2Veja a versão instaladaárea de administração, ajuda3Atualize a sua linhaservidor único fica fora do ar4Faça cópia de segurançaantes da janela de manutenção5Feche o acessoVPN ou lista de endereçosFonte: GitLab e BleepingComputer

O que fazer agora

  1. Descubra se você tem GitLab próprio. Pergunte à equipe ou ao fornecedor que cuida do seu sistema. Se o endereço do GitLab da empresa termina em gitlab.com, você usa a versão hospedada e já está protegido.
  2. Veja a versão instalada. Ela aparece na área de administração do GitLab, na página de ajuda.
  3. Atualize para a versão corrigida da sua linha. Se a instalação é muito antiga, planeje a migração para uma linha suportada.
  4. Programe a janela de manutenção. O GitLab avisa que, em instalação de servidor único, a atualização deixa o sistema fora do ar por um tempo, por causa das migrações de banco de dados. Combine com a equipe e faça cópia de segurança antes.
  5. Tire o GitLab da internet aberta, se puder. Acesso só por VPN ou por lista de endereços permitidos reduz muito o risco desta falha e das próximas.
  6. Revise as chaves guardadas no GitLab. Variáveis de CI/CD, tokens de publicação e senhas de banco de dados devem ter permissão mínima e ser trocadas se houver qualquer sinal de acesso estranho.

Por que isso pesa para a pequena empresa

O repositório de código é o cofre do sistema. Quem invade o GitLab tem o código-fonte, entende como o sistema funciona e, muitas vezes, encontra as chaves de acesso à produção. Para uma loja virtual ou um sistema de gestão, isso pode significar checkout alterado, dados de clientes copiados ou o sistema derrubado.

Se a sua empresa instalou o GitLab há anos para ter controle do código e nunca mais atualizou, esse servidor esquecido é o primeiro que uma falha como esta encontra.

Onde a Oneck entra

A frente de Software & Sistemas da Oneck Creative desenvolve e mantém sistemas com rotina de atualização, controle de acesso e monitoramento das ferramentas que guardam o código. Se você não sabe quem cuida do GitLab da sua empresa, ou em que versão ele está, fale com a gente pelo WhatsApp ou conheça a Software & Sistemas da Oneck Creative.

Fontes: GitLab: patch release 19.5.1; BleepingComputer: GitLab warns of new max severity code execution vulnerability.

Compartilhar

WhatsAppLinkedIn

Conversa

Comentários

Carregando comentários...

Deixe seu comentário

Os comentários passam por moderação antes de aparecer. Seu e-mail não é publicado.