GitLab: regex que executa código

01Sumário executivo

A CVE-2026-97229, corrigida em 12 de outubro de 2026, permite que um usuário sem autenticação execute código no servidor GitLab por meio de uma expressão regular construída na configuração de CI/CD [1]. A CVE-2026-110264, corrigida em 21 de outubro, é um segundo estouro de inteiro no compilador de expressões regulares, alcançável sob certas condições também sem autenticação, e afeta todas as versões a partir da 7.0 [2]. Ambas valem para as edições Community e Enterprise em instalação própria; o GitLab.com e o GitLab Dedicated já estavam corrigidos na divulgação [1] [2].

O pré-requisito prático da CVE-2026-97229 é enviar um .gitlab-ci.yml malicioso a um projeto público; em instâncias onde qualquer pessoa pode se cadastrar e criar projetos, isso não exige credencial nenhuma [3]. Foi exatamente o caminho usado contra a Alpine Linux: em 20 e 21 de outubro, um atacante criou uma conta, enviou configurações de CI construídas e derrubou os trabalhadores do GitLab oito vezes; em quatro delas, avançou além da primeira etapa do exploit [4]. A CISA incluiu a falha no catálogo KEV em 29 de outubro, com prazo federal de três dias [3] [5].

A ação é: atualize para 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13, que cobrem as duas falhas, e, se o GitLab roda sobre um Ruby que não é o do pacote oficial, atualize também o Ruby para 3.3.13, 3.4.12 ou 4.0.9 [2] [4]. A seção 6 registra que o CiberLab não usa GitLab.

02Identificação do objeto analisado

03Contexto técnico: o Onigmo dentro do Ruby

3.1Expressões regulares que viram programa

O GitLab é escrito em Ruby, e o Ruby usa o Onigmo como motor de expressões regulares [3] [5]. Para avaliar uma expressão regular, o Onigmo a compila num pequeno programa de instruções e o executa numa máquina virtual própria [3]. O tamanho desse programa é calculado antes da compilação; se o cálculo estiver errado, o programa gerado não cabe no espaço reservado ou contém instruções que o motor não deveria emitir [3].

3.2Onde o GitLab aceita expressões regulares

O arquivo .gitlab-ci.yml aceita expressões regulares em regras de pipeline, por exemplo para decidir em quais ramos ou caminhos um job roda [1] [3]. Qualquer pessoa que consiga enviar esse arquivo a um projeto consegue entregar uma expressão regular ao servidor. Em instâncias com cadastro aberto, isso inclui qualquer visitante [3].

3.3Codificação e recompilação

O Ruby associa uma codificação a cada texto. Uma expressão regular guardada como US-ASCII pode ser recompilada como UTF-8 quando é comparada com um texto UTF-8 que contém caracteres fora do ASCII [3]. A validação do GitLab examina a versão US-ASCII; a recompilação que acontece depois não passa pela mesma validação [3].

04Mecanismo das vulnerabilidades e causa raiz

4.1CVE-2026-97229: validada em ASCII, explorada em UTF-8

A expressão regular do atacante passa pela validação do GitLab enquanto está em US-ASCII [3]. Quando é avaliada contra um caminho de repositório em UTF-8 especialmente formado, o Onigmo a recompila, e um estouro no cálculo do tamanho do programa gera instruções de expressão regular inválidas [3]. Essas instruções quebram a integridade do fluxo de controle e dão ao atacante operações controladas na máquina virtual do Onigmo, dentro do processo Ruby, até a execução de comandos do sistema como o usuário git [3].

A Rapid7 reproduziu a execução de código numa imagem oficial do GitLab CE 19.4.1 (Linux amd64, com ASLR ligado), e a mesma entrada não executou contra a 19.4.2 [3]. O pré-requisito é enviar um .gitlab-ci.yml malicioso com um caminho de repositório UTF-8 a um ramo de um projeto público [3].

4.2CVE-2026-110264: o segundo estouro

O aviso de 21 de outubro descreve um estouro de inteiro ao compilar uma expressão regular construída, que permite a um usuário sem autenticação, sob certas condições, executar código arbitrário no servidor [2]. As notas de versão incluem um patch de Ruby para estouro de identificador de repetição (repeat ID overflow) nos ramos 19.2 a 19.5, mas não o associam explicitamente à CVE [2]. Fontes secundárias situam o caminho de ataque na renderização de arquivos Org mode, o que é coerente com o sinal de detecção que o próprio GitLab publica [2] [6].

4.3A correção está no Ruby

As correções são patches no interpretador Ruby que acompanha os pacotes Omnibus e as imagens oficiais (CNG) do GitLab: um patch de tamanho de programa e um de liberação dupla em faixas de repetição, para Ruby 3.3 e 3.4, em 12 de outubro [1]. O Ruby oficial publicou as correções em 3.3.13, 3.4.12 e 4.0.9, em 22 e 23 de outubro [4] [5].

05O ataque à Alpine Linux

A Alpine Linux publicou um relato detalhado do ataque à sua instância pública do GitLab, que mostra como uma correção mal aplicada mantém o servidor exposto [4].

O atacante enviou configurações de CI com expressões regulares maliciosas, derrubou os trabalhadores oito vezes e, em quatro delas, avançou além da primeira etapa antes de falhar [4]. Também baixou a imagem de contêiner do GitLab da Alpine, o que sugere que ajustava o exploit à compilação exata [4]. Mais tarde, fez tentativas de login com senhas vazadas de outros sites [4] [5].

A Alpine não encontrou evidência de execução de código, mas não pôde descartá-la: parte dos registros do dia do ataque faltava e não havia registro de conexões de saída [4]. Por isso tratou a instância como comprometida e a reconstruiu [4]. As chaves de assinatura de pacotes nunca ficaram no servidor do GitLab, e a verificação de commits, pacotes e imagens contra 45 servidores de build não mostrou adulteração [4].

06Verificação: a exposição do CiberLab

O repositório da plataforma CiberLab fica num servidor Gitea próprio, e não num GitLab. O Gitea é escrito em Go e não usa Ruby nem o Onigmo. A conclusão é que a plataforma não é afetada por nenhuma das duas falhas.

A lição da seção 5 vale para qualquer servidor de código: o Gitea é exposto ao mesmo tipo de risco se o cadastro aberto permitir que estranhos criem repositórios e disparem automações. Mantenha o cadastro fechado e o servidor atualizado.

07Detecção

7.1Versões do GitLab e do Ruby

# Ruby embutido no pacote Omnibus
/opt/gitlab/embedded/bin/ruby -v

# Resumo de versoes do GitLab e do Ruby
sudo gitlab-rake gitlab:env:info

# Em conteiner
docker exec <conteiner> ruby -v

7.2Sinais publicados pelo GitLab

O GitLab publicou duas detecções para instâncias próprias: queda de trabalhador nativo do Onigmo e rajada de erros de renderização Org mode [2]. A primeira cobre o padrão visto na Alpine; a segunda, o caminho associado à CVE-2026-110264 [2] [4].

7.3Sinais de abuso de CI

1. Contas novas que enviam CI: contas criadas há pouco que fazem push de .gitlab-ci.yml em projetos públicos [3] [4].
2. Expressões regulares longas ou com caracteres não ASCII: em regras de pipeline, combinadas com caminhos de repositório em UTF-8 incomuns [3].
3. Quedas repetidas de trabalhadores: erros 502 e jobs de CI falhando em série logo após um push [4].
4. Download da imagem do servidor: o atacante baixou a imagem de contêiner da instância para ajustar o exploit [4].
5. Logins com senhas vazadas: tentativas automatizadas depois da exploração [4] [5].

7.4Regra Sigma para registros do GitLab

title: Quedas de trabalhador do GitLab apos push de configuracao de CI
id: 5d2b8e31-7c4f-4a90-b6e2-1f3a9c0d7e58
status: experimental
description: Falhas de segmentacao em trabalhadores Puma ou Sidekiq do GitLab,
    padrao da exploracao da CVE-2026-97229 e da CVE-2026-110264
author: CiberLab (Ciência Embarcada)
references:
    - https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
    - https://alpinelinux.org/posts/GitLab-security-incident-CVE-2026-97229.html
logsource:
    product: gitlab
    category: application
detection:
    selection:
        message|contains:
            - 'Segmentation fault'
            - 'SIGSEGV'
        message|contains|all:
            - 'onig'
    condition: selection
falsepositives:
    - Defeitos nativos sem relacao com ataque
level: high
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2026-97229
    - cve.2026-110264

08Mitigação e resposta a incidentes

8.1Correção definitiva

Atualize para 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13, fora do ciclo normal [2] [3]. A versão inclui migrações de banco: instâncias de nó único terão indisponibilidade, e as de vários nós podem usar o procedimento sem parada [2]. Se o GitLab roda com Ruby próprio, atualize o Ruby para 3.3.13, 3.4.12, 4.0.9 ou superior; o Ruby 3.2 está fora de suporte e, segundo um relato, não receberá correção [4] [7]. Usuários da imagem alpinelinux/gitlab devem baixar de novo a etiqueta 19.3.6, reconstruída em 27 de outubro [4].

8.2Medidas temporárias

Restrinja o acesso anônimo a projetos públicos e impeça que usuários não confiáveis criem projetos ou escrevam neles [3]. Desligue o cadastro aberto. Essas medidas bloqueiam o caminho de entrega demonstrado, mas não corrigem o compilador [3].

8.3Resposta a um comprometimento

Uma instância que ficou vulnerável e exposta ao cadastro aberto, com quedas de trabalhadores sem explicação, deve ser tratada como a Alpine tratou a sua: restrinja o acesso, reconstrua a partir de imagem limpa, redefina todas as senhas e troque as chaves secretas do GitLab [4]. Gire também variáveis de CI/CD, tokens de runners, credenciais de webhooks, integrações e espelhos, e tokens de acesso pessoal, que estavam ao alcance do processo [4]. Verifique a integridade dos repositórios e dos artefatos publicados contra cópias externas [4]. Órgãos sujeitos à diretiva da CISA devem fazer triagem forense antes de atualizar [7].

8.4Mapeamento de técnicas MITRE ATT&CK

IDs e nomes conferidos na base oficial do MITRE ATT&CK for Enterprise [8]:

09Indicadores de comprometimento

A Alpine não divulgou IPs, nomes de usuário nem arquivos do atacante, e nenhuma outra fonte publicou indicadores de rede [4]. Os indicadores abaixo são de exposição e de comportamento:

10Limitações da análise

1. Ausência de detonação: o CiberLab não reproduziu as falhas nem executou a prova de conceito da Rapid7. A mecânica vem das referências [1] a [7].
2. Detalhe escasso da CVE-2026-110264: o GitLab não descreve o caminho de ataque, e a ligação com o Org mode vem de fontes secundárias e do sinal de detecção publicado [2] [6].
3. Contagem da Censys anterior à correção: os 25.766 hosts vulneráveis são de 13 de outubro e vêm de fonte secundária [7]; o número atual é menor.
4. Regra derivada: a regra Sigma da seção 7.4 foi deduzida dos sinais publicados e não foi testada; o formato das mensagens de queda varia entre versões.