Skip to content
enterprise

O bug 10/10 do GitLab colocou 12 anos em risco

Um motor de regex de aparência rotineira tornou-se a porta de entrada para um dos sustos de segurança mais graves do GitLab. O aviso maior: patches de emergência podem expor os custos ocultos de executar software crítico por conta própria.

Eleanor Shaw
O bug 10/10 do GitLab colocou 12 anos em risco

Um projeto público pode abrir a porta

Uma vulnerabilidade crítica, CVE-2026-110264, abalou recentemente instâncias do GitLab autogerenciadas, alcançando uma pontuação perfeita de 10.0 na escala CVSS. Essa falha permite que um invasor não autenticado execute código arbitrário em servidores vulneráveis, uma ameaça direta à integridade dos dados e à continuidade operacional.

O exploit requer uma pré-condição específica: a instância do GitLab deve hospedar pelo menos um projeto público ou acionar a renderização de Org-mode. Uma entrada de expressão regular especialmente criada atinge então o código vulnerável dentro do motor de regex Onigmo, integrado ao GitLab, levando a um estouro de inteiro (integer overflow) e subsequente execução de código.

Esta vulnerabilidade projeta uma longa sombra, remontando ao GitLab 7.0, lançado em junho de 2014. Ela afeta as edições autogerenciadas Community Edition (CE) e Enterprise Edition (EE) em um vasto espectro de versões, incluindo:

  • 18.11.x
  • 19.0.x–19.4.x
  • 19.5.0

As plataformas GitLab.com e GitLab Dedicated receberam patches silenciosos, mas as implantações auto-hospedadas enfrentam risco imediato. Não há solução alternativa; as organizações devem atualizar suas instâncias para versões corrigidas, como 18.11.13, 19.0.10 ou 19.5.1, para mitigar essa ameaça grave. Aproximadamente 82.000 servidores GitLab autogerenciados permanecem expostos à internet, tornando a ação rápida imperativa.

O bug estava escondido dentro do motor de regex do Ruby

O bug residia profundamente dentro do runtime Ruby integrado ao GitLab. Especificamente, o motor de expressão regular Onigmo, que o Ruby integra, manipulava incorretamente IDs de repetição durante a compilação de regex. Um padrão cuidadosamente criado poderia acionar um estouro de inteiro, levando diretamente à corrupção de memória.

A exploração bem-sucedida permitiu que um invasor não autenticado executasse código nativo no servidor autogerenciado vulnerável. Esse código era executado sob o usuário de sistema git do GitLab, criando um risco grave para repositórios armazenados e potencialmente expondo dados sensíveis de CI/CD a comprometimento.

Este incidente destaca uma vulnerabilidade crítica na cadeia de suprimentos: componentes de runtime fornecidos ou integrados frequentemente escapam do escrutínio aplicado à base de código principal de uma aplicação. Mesmo revisões de segurança internas robustas podem deixar passar falhas em bibliotecas upstream.

A correção exigiu que o GitLab fornecesse binários personalizados e corrigidos do Ruby 3.3, 3.4 e 4.0 dentro de seus pacotes Omnibus, resolvendo o estouro do Onigmo. Qualquer serviço baseado em Ruby que compile expressões regulares não confiáveis deve agora avaliar urgentemente sua exposição, particularmente se não tiver aplicado os patches upstream mais recentes do Ruby (Ruby 4.0.9, 3.4.12 e 3.3.13). Esta vulnerabilidade demonstra que uma única falha em um componente fundamental pode colocar em risco anos de integridade operacional.

Dois 10 perfeitos em nove dias não é coincidência

O histórico de segurança recente do GitLab exige atenção imediata. Esta falha no Onigmo, classificada com CVSS 10.0, chegou apenas nove dias após outra correção crítica para uma falha no compilador de regex de CI/CD, também avaliada em 10.0. Essa concentração é sem precedentes e sinaliza uma mudança no perfil de risco.

Historicamente, o GitLab registrou apenas quatro vulnerabilidades CVSS 10.0 de 2019 até o final de 2025. No entanto, no início do outono de 2026, a plataforma enfrentou três desses 10 perfeitos em apenas seis semanas. Um predecessor de setembro foi supostamente explorado dentro de um dia após seu patch, ressaltando a urgência.

Este ritmo acelerado de avisos críticos cria uma pressão operacional significativa para instâncias autogerenciadas. Atualizações de emergência frequentemente exigem downtime e migrações complexas de banco de dados, interrompendo pipelines de desenvolvimento. Avisos repetidos geram patch fatigue entre os administradores, aumentando a probabilidade de que os sistemas permaneçam sem correção.

Cada atraso deixa um sistema exposto vulnerável dentro da janela de varredura de um atacante. Com aproximadamente 82.000 servidores GitLab autogerenciados acessíveis pela internet, a superfície de ataque é substancial. Para detalhes abrangentes e avisos adicionais, consulte o GitLab Releases & Security Advisories. Os líderes devem reconhecer que este padrão não é meramente lamentável; ele exige uma reavaliação estratégica da postura de segurança e dos protocolos de atualização.

Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.

um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros

Aplique o patch primeiro; investigue enquanto espera

Ação imediata é crítica para instâncias GitLab autogerenciadas. Não há solução alternativa para esta vulnerabilidade CVSS 10.0; os administradores devem atualizar para uma versão corrigida sem demora. Consulte a página de avisos de segurança e lançamentos do GitLab para confirmar sua versão e aplicar o backport relevante.

O GitLab mitigou o risco para seus serviços hospedados, incluindo GitLab.com e GitLab Dedicated, aplicando patches proativamente. No entanto, o ônus recai sobre as organizações que executam instâncias autogerenciadas para atualizar para uma versão segura, como 18.11.13, 19.0.10 ou 19.5.1. A falha em fazer isso deixa seus sistemas expostos.

Após a aplicação do patch, uma investigação minuciosa é fundamental. Revise as orientações de detecção do GitLab para indicadores de comprometimento, procurando especificamente por falhas no worker Onigmo ou surtos incomuns de erros de renderização em Org-mode. Avalie a exposição pública da sua instância, dado que aproximadamente 82.000 servidores GitLab autogerenciados são acessíveis pela internet.

Finalmente, se houver suspeita de comprometimento, conduza uma auditoria abrangente de segredos de CI/CD e logs de acesso. A aplicação proativa de patches e a análise vigilante pós-incidente são suas defesas mais fortes contra ameaças que podem comprometer mais de uma década de integridade operacional.

Perguntas Frequentes

O que é a vulnerabilidade GitLab CVE-2026-110264?

É uma falha de execução remota de código CVSS 10.0 envolvendo estouro de inteiro no Onigmo, o mecanismo de regex do Ruby incluído no GitLab.

Quais instâncias do GitLab são afetadas?

A falha afeta versões do GitLab CE e EE autogerenciadas desde a 7.0, quando um projeto público ou gatilho de renderização relevante está presente.

Como os administradores podem proteger uma instância GitLab autogerenciada?

Atualize para uma versão corrigida do GitLab o mais rápido possível; o aviso fornece versões corrigidas em todas as ramificações de lançamento suportadas.

O GitLab.com foi afetado?

O GitLab informou que o GitLab.com e o GitLab Dedicated foram corrigidos antes da divulgação pública. Administradores de instâncias autogerenciadas devem aplicar suas próprias atualizações.

Found this useful? Share it.

For builders

Want Stork to write one of these about your product?

Send us a URL. We use the product, form a view, and publish what we actually think — in 8 languages, labeled Sponsored, with no copy approval on your side. That last part is what makes it worth quoting.

See how it works$199 · AI tools & software only

Para builders

Esta página está trabalhando para a ferramenta de outra pessoa.

Agentes de IA leem. Compradores chegam nela. Ela responde em oito idiomas e via MCP. Sua ferramenta pode ter uma assim — no ar em 24 horas.