A vulnerabilidade CVE-2026-66066 no Ruby on Rails permite que um atacante não autenticado leia arquivos arbitrários do servidor e escale para execução remota de código (RCE). A falha, classificada com CVSS 9,5 e batizada de “KindaRails2Shell” pelos pesquisadores que a descobriram, afeta o componente Active Storage quando o aplicativo processa variantes de imagens enviadas por usuários usando a biblioteca libvips — processador padrão desde o Rails 7.0. Atualizações foram liberadas em 29 de julho de 2026, mas todos os segredos potencialmente expostos precisam ser rotacionados imediatamente.
O Ruby on Rails roda uma parcela significativa da web moderna, e o Active Storage vem habilitado por padrão em grande parte das aplicações em produção. A equipe da Ethiack, que descobriu a falha de forma independente e coordenou a divulgação com os mantenedores do Rails, ressalta que qualquer funcionalidade voltada ao usuário que aceite upload de imagem e depois sirva uma versão processada pode estar vulnerável, incluindo avatares, miniaturas e fotos de perfil.
Como a falha permite invasão
Um aplicativo é afetado se atender simultaneamente a três requisitos: usar libvips como processador de variantes do Active Storage (o padrão desde o Rails 7.0), aceitar uploads de imagens vindos de usuários não confiáveis e rodar uma versão vulnerável do framework. A exploração inicia quando o atacante envia um arquivo de imagem especialmente manipulado para um endpoint que aceita uploads sem exigir autenticação.
Quando o Active Storage tenta gerar uma variante daquela imagem, o libvips é induzido a invocar operações marcadas como “unfuzzed” — operações consideradas inseguras para conteúdo não confiável e que lidam com formatos de arquivo alheios a imagens web. Como o Active Storage não desativava essas operações por padrão, o atacante consegue usá-las para ler o conteúdo de arquivos arbitrários do sistema de arquivos do servidor. O alvo mais sensível exposto nesse caminho é o ambiente de processo da aplicação.
Ao extrair as variáveis de ambiente do processo, o invasor obtém o secret_key_base — a chave criptográfica mestra do Rails, que assina sessões de usuário, cookies assinados e identificadores globais. Com essa chave em mãos, o atacante pode forjar sessões, manipular dados serializados e escalar para execução remota de código completa no servidor. A rota é especialmente perigosa porque o ambiente também costuma guardar credenciais de banco de dados, chaves de armazenamento em nuvem e tokens de serviços de terceiros, abrindo caminho para movimento lateral.
Versões afetadas e correção
A tabela abaixo resume as versões vulneráveis do activestorage e as respectivas versões corrigidas liberadas pela equipe do Rails:
| Linha do activestorage | Versões afetadas | Versão corrigida | Observação |
|---|---|---|---|
| Série 7.x | 7.0.0 a 7.2.3.1 | 7.2.3.2 | Configuração padrão afetada |
| Série 8.0.x | 8.0.0 a 8.0.5 | 8.0.5.1 | Configuração padrão afetada |
| Série 8.1.x | 8.1.0 a 8.1.3 | 8.1.3.1 | Configuração padrão afetada |
| Série 6.x | 6.0.0 a 6.1.7.10 | 7.2.3.2 | Apenas com configuração personalizada |
As versões corrigidas são 7.2.3.2, 8.0.5.1 e 8.1.3.1, publicadas em 29 de julho de 2026 junto com o advisory oficial GHSA-xr9x-r78c-5hrm. Aplicativos que usam o processador de imagens Magick em vez de libvips não são afetados por este vetor. Vale lembrar que a correção é cumulativa: ao atualizar para a versão mais recente disponível, todos os patches anteriores já vêm inclusos.
Impacto e contexto do risco
A gravidade dessa falha é ampliada pelo fato de que, em muitos cenários, a exploração não exige credenciais. O padrão de ataque sem autenticação, em que um simples upload de imagem abre caminho para o comprometimento total do servidor, lembra a cadeia wp2shell que afetou o WordPress Core recentemente. Esse tipo de falha em framework web de uso amplo, como já observado em outros casos graves de RCE sem login registrados recentemente, costuma atrair atenção imediata de pesquisadores e grupos maliciosos assim que os patches ficam disponíveis.
Para organizações que rodam múltiplas aplicações Rails, o inventário preciso é essencial. Projetos de terceiros e software baseado em Rails também podem ser afetados indiretamente, já que herdam a dependência do Active Storage. Assim como em falhas críticas com exploit público vistas em outras plataformas, a janela entre a publicação do patch e o surgimento de exploração em massa costuma ser curta — os pesquisadores orientam a não aguardar.
Como mitigar e proteger
Atualizar o Rails é a correção que realmente importa. No entanto, aplicar o patch sozinho não desfaz um eventual vazamento de segredos que já tenha ocorrido antes da atualização. Administradores devem assumir que variáveis de ambiente sensíveis foram expostas e rotacionar todos os segredos da aplicação logo após o update.
A mitigação definitiva exige libvips na versão 8.13 ou superior, capaz de bloquear as operações inseguras. Versões anteriores do libvips simplesmente não conseguem desativar essas operações, e o Active Storage passará a lançar uma exceção durante a inicialização ao detectar um ambiente sem essa proteção — o que, por si só, já evita a condição vulnerável.
- Atualize o Rails para 7.2.3.2, 8.0.5.1 ou 8.1.3.1, conforme a sua versão.
- Verifique o libvips: a versão mínima deve ser 8.13 ou superior; em libvips abaixo disso, atualize a biblioteca ou remova a dependência se a aplicação só a usa para análise de imagens.
- Rotacione todos os segredos acessíveis no ambiente da aplicação: secret_key_base, master key, credenciais de banco de dados, chaves de armazenamento em nuvem (S3, GCS, Azure) e tokens de APIs de terceiros.
- Considere uma medida temporária: se não for possível atualizar de imediato e o libvips for 8.13+, defina a variável de ambiente VIPS_BLOCK_UNTRUSTED ou chame Vips.block_untrusted(true) em um inicializador (requer ruby-vips 2.2.1 ou superior).
- Monitore logs de upload e de acesso a arquivos em busca de atividade anômala, em especial requisições de variantes de imagem fora do padrão.
A rotação do secret_key_base encerra sessões ativas, exige novo login dos usuários e invalida cookies assinados, identificadores globais e URLs do Active Storage. Trata-se de etapa essencial: manter uma chave já exposta como fallback não deve ser feito sob nenhuma circunstância. Os detalhes técnicos completos da cadeia de ataque serão divulgados até 28 de agosto de 2026, no fórum oficial de anúncios de segurança do Rails, o que reforça a urgência de aplicar as correções antes dessa data.