Ruby corrige três falhas do motor regex Onigmo, na origem de quatro vulnerabilidades RCE críticas no GitLab

O Ruby lançou as versões 4.0.9, 3.4.12 e 3.3.13 para corrigir três falhas de segurança de memória no Onigmo, o motor de expressões regulares integrado na linguagem. Estas mesmas falhas estão na origem de quatro vulnerabilidades críticas de execução remota de código (RCE) que o GitLab corrigiu entre o final de setembro e o final de outubro de 2026.

O que aconteceu

As falhas encontram-se na fase em que o Ruby compila uma expressão regular. Um padrão especialmente construído pode corromper a memória durante a compilação e, em determinadas condições, essa corrupção pode ser convertida em execução de código no servidor.

O GitLab foi o primeiro a deparar-se com o problema, porque compila padrões fornecidos pelos próprios utilizadores, por exemplo expressões regulares na configuração de CI/CD. Corrigiu a questão no seu produto quatro vezes, de cada vez incluindo uma cópia corrigida do Ruby:

• Duas CVE divulgadas a 23 de setembro – ambas exigem uma conta autenticada e têm pontuação CVSS de 9,9.
• CVE-2026-97229 (12 de outubro) e CVE-2026-110264 (21 de outubro) – ambas podem ser exploradas sem autenticação e têm a pontuação máxima, 10,0. A CVE-2026-110264 afeta todas as versões do GitLab a partir da 7.0.

A 23 de outubro, nenhuma das quatro constava do catálogo Known Exploited Vulnerabilities da CISA, e não temos conhecimento de exploração confirmada em ambiente real.

Porque é importante para além do GitLab

Este é um problema do Ruby, não apenas do GitLab. Qualquer aplicação Ruby fica exposta se construir uma expressão regular a partir de uma cadeia de caracteres controlada por um atacante – por exemplo, ao passar dados do utilizador para Regexp.new, Regexp.union ou Regexp.compile, ou ao interpolá-los num padrão literal como /#{input}/. As aplicações que apenas usam expressões regulares escritas pelos próprios programadores não são afetadas.

Duas mitigações aparentemente sensatas não ajudam aqui:

• Regexp.timeout limita a duração da correspondência, mas estas falhas são acionadas durante a compilação, antes de qualquer limite de tempo se aplicar.
• Limitar o comprimento do padrão não é fiável, porque padrões curtos bastam para acionar as falhas.

Há também um ponto cego para as equipas de defesa. O Ruby não pediu, para já, identificadores CVE próprios para estas correções e remete os utilizadores para as quatro CVE do GitLab. Esses registos indicam apenas o GitLab como produto afetado, pelo que um scanner que compare dados CVE com as versões de Ruby instaladas não encontrará nada a assinalar. A documentação do Ruby continua a tratar padrões não fidedignos sobretudo como um risco de negação de serviço, apesar de o projeto já ter emitido CVE para falhas semelhantes do motor no passado.

O que fazer

Para aplicações Ruby:

• Atualize: Ruby 4.0 → 4.0.9, Ruby 3.4 → 3.4.12, Ruby 3.3 → 3.3.13. A versão 4.0.8, lançada na mesma semana, não inclui uma das correções, por isso passe diretamente para a 4.0.9. As versões 3.4.12 e 3.3.13 são as primeiras dos respetivos ramos a incluir alguma das três correções.
• O Ruby 3.2 e versões anteriores não vão receber correção – a 3.2 atingiu o fim de vida a 1 de abril de 2026. Planeie a migração para 3.4 ou 4.0.
• Até conseguir atualizar, deixe de compilar expressões regulares a partir de dados não fidedignos. Procure no código Regexp.new, Regexp.union, Regexp.compile e padrões interpolados alimentados por dados dos pedidos.
• Não confie nos alertas de dependências baseados em CVE para este caso – verifique diretamente a versão do Ruby, incluindo a que vem nas imagens de contentores.

Para GitLab autogerido:

• Instale uma versão que corrija a CVE-2026-110264: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13. Como o GitLab inclui o seu próprio Ruby, atualizar o GitLab aplica a correção.
• O GitLab.com já está corrigido, e os clientes GitLab Dedicated em versões internas recentes não precisam de fazer nada.
• Utilize as regras de deteção publicadas pelo GitLab para analisar os registos à procura de tentativas de exploração, sobretudo em instâncias expostas à internet.

Falhas como esta vivem no espaço entre o seu código e o ambiente de execução por baixo dele – precisamente onde os alertas CVE ficam em silêncio. A nossa revisão de código assistida por IA acompanha o percurso dos dados controlados pelo utilizador até operações perigosas, como a compilação dinâmica de expressões regulares, para que esta classe de problemas seja detetada no seu próprio código e não apenas quando um fornecedor publica um aviso.