Um invasor tentou explorar uma vulnerabilidade crítica no servidor GitLab do projeto Alpine Linux uma semana depois que o GitLab lançou uma correção, informou o Alpine em 28 de outubro.
A falha, identificada como CVE-2026-97229 e com pontuação CVSS de 10,0, pode permitir que um invasor execute código em um servidor GitLab por meio de uma expressão regular criada especialmente em uma configuração de CI. O Alpine não encontrou provas de que o ataque tenha funcionado, mas não descarta essa possibilidade. Por isso, reconstruiu o servidor do zero e redefiniu as senhas de todas as contas.
A correção do GitLab consiste em patches para o Ruby incluído nos pacotes e nas imagens de container da plataforma. A imagem do GitLab usada pelo Alpine incluía uma versão padrão do Ruby. Por isso, atualizar o servidor para o GitLab 19.3.6, em 22 de outubro, não corrigiu a falha.
Para quem executa o GitLab com uma versão própria do Ruby, compilada a partir do código-fonte ou incluída em uma imagem de container própria, “atualizar o GitLab não basta”, alertou o Alpine. Esses servidores também precisam do Ruby 3.3.13, 3.4.12, 4.0.9 ou posterior. Quem usa a imagem alpinelinux/gitlab precisa baixar novamente a versão 19.3.6.
O servidor gitlab.alpinelinux.org hospeda o aports, repositório a partir do qual os pacotes do Alpine são compilados. Segundo o projeto, os pacotes produzidos entre 20 e 24 de outubro, assim como as versões lançadas em 21 de outubro, foram criados com base em alterações do aports verificadas em registros externos ao GitLab.
Essas versões incluem os arquivos minirootfs, usados para criar as imagens oficiais do Alpine para Docker. O projeto está ampliando a verificação para incluir o período até 27 de outubro, quando o servidor foi fechado. As chaves usadas para assinar os pacotes e as versões do Alpine nunca estiveram no servidor GitLab.
Como o ataque aconteceu
Em 13 de outubro, o Alpine atualizou o servidor para o GitLab 19.3.4, em vez da versão 19.3.5, o que classificou como um erro. O servidor permaneceu nessa versão, sem a correção lançada em 12 de outubro, até que uma conta recém-criada começou a sondá-lo, em 20 de outubro.
Nos dias 20 e 21, a conta enviou configurações de CI especialmente elaboradas ao servidor. Elas derrubaram processos de trabalho do GitLab oito vezes. O principal ataque, em 21 de outubro, também provocou erros 502 e fez com que tarefas de CI falhassem.
Em quatro dessas interrupções, o invasor avançou parcialmente na exploração da falha, mas não conseguiu concluir a etapa seguinte, segundo o Alpine. O invasor também baixou a imagem de container do GitLab usada pelo projeto. Para o Alpine, isso “sugere que estava ajustando o exploit à nossa compilação específica”.
O Alpine bloqueou a conta em 23 de outubro. O invasor voltou nos dias 25 e 26 e tentou obter acesso novamente, mas as tentativas falharam, informou o projeto.
Em 26 de outubro, o Alpine descobriu que o servidor continuava vulnerável mesmo após a atualização para o GitLab 19.3.6, realizada em 22 de outubro. No dia seguinte, restringiu o acesso ao GitLab a seus desenvolvedores e servidores de compilação e iniciou a reconstrução do sistema.
A reconstrução foi concluída em 28 de outubro. O Alpine também substituiu as chaves secretas do GitLab. O servidor reconstruído usa o Ruby 3.3.13 ou posterior, que inclui a correção. O projeto está testando o sistema antes de reabri-lo ao público.
O que o Alpine pode ou não descartar
O Alpine não encontrou sinais de que o código do invasor tenha sido executado no servidor. As sondagens de tempo não mostraram atrasos; não foram encontrados arquivos, chaves, ganchos ou processos inesperados; e, nos registros disponíveis, nenhum dado privado foi enviado ao invasor por solicitações da web ou da API.
Ainda assim, o projeto não tem certeza de que o ataque falhou. “Uma exploração bem-sucedida não deixaria falha nem rastros nos registros da web”, afirmou o Alpine. Alguns registros do dia do ataque foram perdidos, incluindo os de tarefas em segundo plano e do sistema de arquivos do container antigo. Nem o Alpine nem seu provedor de hospedagem registraram as conexões de saída da rede.
Como as evidências necessárias para confirmar a execução de código já não existem, o Alpine tratou o servidor como comprometido e o reconstruiu para remover qualquer ponto de apoio que uma exploração bem-sucedida pudesse ter criado.
Se o ataque tiver funcionado, os seguintes dados podem ter sido expostos:
- Endereços de e-mail, nomes e endereços IP de todos os usuários
- Hashes de senhas
- Segredos de 2FA, variáveis de CI/CD e tokens de executor
- Credenciais de webhooks, integrações e espelhamento de push
- Tokens de acesso pessoal, armazenados como hashes
- Repositórios privados, além de problemas e solicitações de mesclagem confidenciais
Além da redefinição de senhas e da substituição das chaves secretas, o Alpine não informou se também trocou os tokens de executor, as variáveis de CI/CD, os tokens de acesso ou as credenciais de integração armazenadas no servidor.
Para verificar os pacotes, o Alpine confirmou que cada alteração adicionada ao aports entre 20 e 22 de outubro chegou por meio de um envio registrado por um desenvolvedor conhecido. O projeto comparou esses dados com registros que, segundo afirma, estavam fora do alcance do invasor: uma cópia do repositório mantida por um desenvolvedor e os 45 servidores de compilação. Todos os pacotes produzidos entre 20 e 24 de outubro foram gerados a partir das alterações do aports publicadas em git.alpinelinux.org.
Por que a atualização do GitLab não corrigiu a falha
O GitLab compila as expressões regulares das configurações de CI usando o Ruby. O bug relacionado à CVE-2026-97229 está no Onigmo, mecanismo de expressões regulares incluído no Ruby.
A versão do GitLab lançada em 12 de outubro corrigiu a falha com um patch para o Ruby presente no pacote Linux e nas imagens de container da plataforma. As versões corrigidas do próprio Ruby foram lançadas em 22 e 23 de outubro.
Atualizar o GitLab não altera a versão do Ruby instalada no servidor. Assim, uma instalação que usa o Ruby padrão continua vulnerável até que o próprio Ruby seja atualizado para uma versão corrigida, como ocorreu com o Alpine.
Os pacotes Linux corrigidos do GitLab e suas imagens oficiais de container incluem o Ruby atualizado. Já uma instalação compilada a partir do código-fonte ou uma imagem de container que instala o Ruby separadamente, como fazia a do Alpine, não recebe a correção automaticamente.
Até 29 de outubro, nenhuma das publicações de versões corretivas do GitLab, lançadas em 12 e 21 de outubro, orientava os administradores de instalações compiladas por conta própria a atualizar o Ruby. O guia de instalação desse tipo do GitLab ainda indica o Ruby 3.2 como versão mínima. O suporte ao Ruby 3.2 terminou em abril, e essa versão não receberá a correção.
Quais servidores GitLab estão vulneráveis
O comunicado do GitLab afirma que, “sob determinadas condições”, a falha poderia permitir que um usuário não autenticado executasse código no servidor. O GitLab.com e o GitLab Dedicated já estão corrigidos.
A Rapid7 criou um exploit funcional em laboratório e publicou um código de prova de conceito em 13 de outubro. O exploit executou comandos como o usuário git em uma imagem oficial do GitLab 19.4.1 sem correção. A mesma entrada, porém, não funcionou na imagem corrigida 19.4.2.
Esse exploit exige permissão de escrita prévia: o invasor precisa enviar um arquivo .gitlab-ci.yml malicioso e um caminho de arquivo com caracteres UTF-8 não ASCII para uma ramificação de um projeto público. Essa exigência não se aplica a servidores nos quais novos usuários podem se cadastrar e criar projetos por conta própria.
Na rota testada pela Rapid7, “somente a solicitação final de validação de CI não exige autenticação”. As orientações de detecção do próprio GitLab também dizem que o invasor precisa primeiro criar o caminho de arquivo por meio das APIs comuns do repositório. A Rapid7 ainda não sabe como o ataque descrito no relato original enviado ao GitLab, que continua privado, contorna a etapa de escrita.
O Alpine não informou como as configurações de CI do invasor chegaram ao GitLab nem se novas contas podiam criar projetos públicos no servidor.
Em 28 de outubro, data da atualização mais recente do catálogo, a CVE-2026-97229 não constava no catálogo de Vulnerabilidades Conhecidas Exploradas da CISA.
O que os administradores do GitLab devem fazer
As versões lançadas pelo GitLab em 21 de outubro são as mais recentes de cada ramificação listada abaixo. Elas também corrigem a CVE-2026-110264, uma falha distinta em expressões regulares.
| Ramificação | Versão que corrige a CVE-2026-97229, segundo o comunicado do GitLab | Versão mais recente, de 21 de outubro |
|---|---:|---:|
| 19.5 | Não listada como afetada | 19.5.1 |
| 19.4 | 19.4.2 | 19.4.3 |
| 19.3 | 19.3.5 | 19.3.6 |
| 19.2 | 19.2.8 | 19.2.9 |
| 19.1, 19.0 e 18.11 | Não listadas como afetadas | 19.1.9, 19.0.10 e 18.11.13 |
A versão necessária para corrigir o servidor depende de como o GitLab foi instalado:
- **Pacote Linux do GitLab ou imagens oficiais de container:** atualize para a versão mais recente da sua ramificação.
- **Instalações compiladas por conta própria ou imagens que instalam o próprio Ruby:** atualize o GitLab e o Ruby para a versão 3.3.13, 3.4.12, 4.0.9 ou posterior. O Ruby 3.2 não receberá a correção. Servidores que o utilizam precisam migrar para uma dessas versões.
Quando publicou o comunicado, em 12 de outubro, o GitLab indicou a versão 19.3.4 como corrigida para a ramificação 19.3. Agora, porém, aponta a 19.3.5 e lista a 19.3.4 como vulnerável. Portanto, servidores que ainda usam a versão 19.3.4 devem ser atualizados para a 19.3.6.
Se não for possível atualizar o servidor imediatamente, a Rapid7 sugere restringir o acesso anônimo a projetos públicos, impedir que usuários não confiáveis criem ou alterem projetos públicos ou bloquear a rota de validação de CI. Segundo a empresa, essas medidas cobrem apenas a rota usada pelo exploit testado pela Rapid7 e não corrigem o compilador vulnerável de expressões regulares.
O GitLab publicou seis regras de detecção, no formato Sigma, para identificar tentativas de exploração contra servidores autogerenciados. Quatro delas, classificadas pelo GitLab como experimentais, procuram padrões maliciosos em avisos de expressões regulares de CI e em solicitações GraphQL de validação de CI, caminhos de arquivo incomumente longos com caracteres não ASCII e relatórios de falha do Ruby que apontem para o Onigmo.
As orientações que acompanham as regras alertam que uma exploração bem-sucedida pode não deixar registros de falha e recomendam também:
- Procurar arquivos pertencentes ao usuário git em /tmp, processos filhos inesperados do Puma ou do Sidekiq, conexões de saída da rede e alterações nas tabelas cron ou nas chaves SSH do usuário git.
- Se houver sinais de execução de código, tratar o servidor como comprometido e trocar os segredos em gitlab-secrets.json, todas as variáveis de CI/CD, todos os tokens de executor e todos os tokens de acesso.
- Restringir quem pode criar contas e tokens de acesso pessoal no servidor.
O que os usuários do Alpine devem fazer
Os titulares de contas precisarão definir uma nova senha usando a opção “Esqueceu sua senha?” na página de entrada quando o gitlab.alpinelinux.org for reaberto, informou o Alpine. O projeto também identificou tentativas automatizadas de entrada no GitLab com senhas vazadas de outros sites. Quem reutilizou a senha do gitlab.alpinelinux.org em outros serviços deve alterá-la nesses locais.
Quem usa a imagem alpinelinux/gitlab deve baixar novamente alpinelinux/gitlab:19.3.6. A imagem publicada em 27 de outubro inclui o Ruby 3.3.13. Qualquer imagem 19.3.6 baixada antes dessa data, assim como todas as etiquetas de versões anteriores, continua vulnerável.
Os pacotes de Ruby do próprio Alpine já incluem a correção: Ruby 3.4.12 no Alpine 3.22, 3.23, 3.24 e edge, e Ruby 3.3.13 no Alpine 3.21. A atualização pode ser instalada com o comando apk upgrade.
Os responsáveis pelo Ruby afirmam que o bug só afeta programas que compilam uma expressão regular a partir de texto controlado por um invasor. A configuração Regexp.timeout do Ruby não protege contra a falha.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...