O Ruby lançou as versões 4.0.9, 3.4.12 e 3.3.13 para corrigir três bugs no Onigmo (motor de expressões regulares embutido na linguagem). Os erros estão por trás de quatro falhas críticas de segurança que o GitLab corrigiu no último mês.
O GitLab descobriu que um padrão especialmente elaborado poderia corromper a memória enquanto o Ruby o compilava, o que potencialmente levaria à execução de código nos próprios servidores da empresa.
O Ruby afirma que qualquer aplicação que construa uma expressão regular a partir de um texto controlado por um atacante é afetada, e não apenas o GitLab.
Quais aplicações são afetadas
No comunicado, o Ruby disse que uma aplicação só é afetada se compilar uma expressão regular a partir de um texto (string) controlado por um atacante. Isso acontece quando um programa passa esse texto para Regexp.new, Regexp.union ou Regexp.compile, ou o insere dentro de um padrão por meio de interpolação, como em /#{input}/.
Aplicações que usam apenas expressões regulares escritas pelos próprios desenvolvedores não são afetadas.
O Ruby corrigiu os erros nas versões 4.0.9, 3.4.12 e 3.3.13. As versões 3.4.12 e 3.3.13 são as primeiras de suas séries a incluir qualquer uma das três correções.
- Ruby 4.0: atualize para a versão 4.0.9
- Ruby 3.4: atualize para a versão 3.4.12
- Ruby 3.3: atualize para a versão 3.3.13
Uma versão anterior da mesma semana, a 4.0.8, não inclui a correção de uma das falhas, a CVE-2026-110264 (sigla de Common Vulnerabilities and Exposures, sistema de identificação de vulnerabilidades). Por isso, usuários da versão 4.0 devem instalar a 4.0.9.
O Ruby 3.2 e as versões anteriores não receberão correção. O Ruby 3.2 chegou ao fim da vida útil em 1º de abril de 2026, e a versão 3.2.11 foi a última. O Ruby recomenda migrar para a 3.4 ou a 4.0.
Se não for possível atualizar agora, o comunicado orienta a parar de compilar expressões regulares a partir de entradas não confiáveis.
Duas defesas que parecem ajudar, na prática, não funcionam. Definir Regexp.timeout não impede esses bugs. Limitar o tamanho de um padrão também não é confiável, porque padrões curtos também podem acionar os erros.
Como os bugs chegaram ao GitLab
O GitLab compila expressões regulares fornecidas por seus usuários, como os padrões de uma configuração de CI/CD (integração contínua e entrega contínua). A empresa descobriu que padrões elaborados podiam corromper a memória durante a compilação pelo Ruby e registrou quatro CVEs entre 23 de setembro e 21 de outubro, corrigindo cada uma com o envio de um Ruby corrigido.
As duas primeiras, divulgadas em 23 de setembro, exigem uma conta autenticada e receberam nota 9,9 de 10. As duas de outubro, a CVE-2026-97229, em 12 de outubro, e a CVE-2026-110264, em 21 de outubro, não exigem conta e receberam nota 10,0, a máxima. A CVE-2026-110264 atinge todas as versões do GitLab a partir da 7.0.
Um pesquisador que usa o identificador joaxcar reportou as quatro falhas pelo programa de recompensas por bugs (bug bounty) do GitLab. Até 23 de outubro, nenhuma delas constava no catálogo de Vulnerabilidades Exploradas Conhecidas (Known Exploited Vulnerabilities) da CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA).
Sem CVE próprio do Ruby, por enquanto
O Ruby não solicitou identificadores CVE próprios para essas correções, “pelo menos por enquanto”, afirmou, e orientou os usuários a acompanhar os problemas pelos quatro números CVE do GitLab.
Isso deixa uma lacuna para quem faz varreduras por CVE. Os registros de CVE do GitLab citam apenas o GitLab como produto afetado, então um scanner que cruze esses registros com as versões do Ruby instaladas não tem o que comparar.
O Ruby já tratou esse tipo de problema como vulnerabilidade antes, atribuindo números CVE a correções em 2022 e 2024, embora já fosse inseguro, há muito tempo, criar uma expressão regular a partir de entradas não confiáveis.
A documentação do Ruby ainda descreve padrões não confiáveis apenas como risco de negação de serviço. O Ruby afirmou que atualizará o comunicado caso solicite algum identificador CVE.
Para administradores do GitLab
As instalações do GitLab gerenciadas pelo próprio cliente precisam da versão que corrige a CVE-2026-110264. O GitLab disponibilizou a correção em 21 de outubro e a retroportou até a versão 18.11.13.
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
O GitLab.com já roda a versão corrigida, e os clientes do GitLab Dedicated (tenants) que usam versões internas recentes não precisam fazer nada, segundo a empresa. Como o GitLab inclui sua própria cópia do Ruby e a corrigiu ali, instalar uma dessas versões corrigidas aplica a correção.
O GitLab também publicou regras de detecção que administradores de instalações próprias podem usar para identificar sinais de tentativas de exploração.