Vulnerabilidade crítica no Ruby on Rails permite leitura arbitratia de arquivos via upload de imagens

Falha no Active Storage com pontuacao CVSS 9.5 expoe credenciais críticas e chaves mestras atraves de processamento malicioso de imagens usando libvips.

Componente	Ruby on Rails Active Storage em conjunto com a biblioteca de processamento de imagens libvips.
Vetor	Upload de arquivos de imagem não confiáveis por usuários não autenticados, acionando operações inseguras marcadas como unfuzzed ou untrusted no backend libvips.
Impacto	Leitura arbitrária de arquivos no servidor que resultam na exposição de segredos como secret_key_base, senhas de banco de dados e tokens de API, podendo escalar para execução remota de código.
Prioridade	Atualizar as versões afetadas do framework para os ramos corrigidos e realizar a rotação de todas as credenciais e chaves criptográficas imediatamente.
Versões	Ramos 7.0.0 a 7[.]2[.]3[.]1, 8.0.0 a 8.0.5, e 8.1.0 a 8.1.3; ramos 6.0.0 a 6[.]1[.]7[.]10 afetados apenas se configurados manualmente para Vips. Corrigidos nas versões 7[.]2[.]3[.]2, 8[.]0[.]5[.]1 e 8[.]1[.]3[.]1.

Resumo técnico

O ecossistema Ruby on Rails enfrentou uma severa falha de segurança estrutural no seu modulo integrado de gerenciamento de arquivos, o Active Storage. A vulnerabilidade, rastreada como CVE-2026-66066 e avaliada com uma pontuação crítica de 9.5 no sistema CVSS, instancia um cenario de risco onde atacantes sem credenciais validas podem forcar a leitura de arquivos locais do servidor. Essa falha de leitura arbitrária de arquivos e pivorada pelo processamento malicioso de uploads de imagens. A cadeia de ataque se materializa quando aplicações Ruby on Rails estão configuradas para utilizar a biblioteca libvips como seu motor padrao para análise e redimensionamento de imagens, uma configuração que se tornou padrão a partir da versão 7.0 do framework atraves da diretiva load_defaults 7.0.

Ao explorar essa superficie, o atacante submete uma imagem especialmente manipulada. O valor técnico dessa vulnerabilidade resides na Fronteira de confianca que existia entre o Active Storage e a biblioteca de processamento. O modulo não realizava a sanitização adequada da entrada, permitindo que operações inseguras fossem executadas durante a análise do arquivo. O impacto imediato e a exposição de todos os arquivos que o processo do worker do Rails tem permissão de leitura no sistema operacional. Isso frequentemente inclui arquivos extremamente sensiveis localizados no diretorio da aplicação ou nas variaveis de ambiente, como chaves de API, credenciais de servicos em nuvem, senhas de banco de dados e o secret_key_base, que e fundamental para a integridade criptografica da sessão na arquitetura Rails.

Fluxo técnico

A essência técnica desta exploração está na confiança implicita que o Active Storage depositava nos manipuladores da libvips. A documentacao técnica e o aviso de segurança oficial indicam que a libvips suporta uma variedade de carregadores, gravadores e operações de transformacao. Contudo, uma parcela dessas operações e dependentes de bibliotecas de terceiros e marcada pelos desenvolvedores como unfuzzed ou untrusted, indicando que elas são inseguras para lidar com entradas hostis oriundas de usuários não autenticados. Historicamente, o Active Storage não bloqueava o acesso a essas funcoes inseguras, permitindo que um arquivo manipulado evadisse os limites do processamento de imagem e interagisse com o sistema de arquivos de forma maliciosa.

O vetor de ataque não demanda complexos pre-requisitos de fluxo da aplicação, sendo notavel o fato de que a geracao de variantes ou thumbnails simultaneos não e um requisito separado. A cadeia logica submete o anexo direto ao analisador Vips e ao transformador, ambos responsaveis por passar os dados não confiaveis para as referidas operações inseguras. O sucesso deste ataque confere ao operador malicioso uma primitiva direta de leitura de arquivos arbitrários (arbitrary file-read primitive). A consequencia severa dessa leitura e a extração de segredos. Obter o secret_key_base do Rails, por exemplo, permite ao atacante forjar cookies de sessao, descriptografar dados sensíveis armazenados e, em cenários de arquitetura mais agressivos, escalar para execução remota de código atraves de desserializacao de objetos maliciosos ou movimentacao lateral utilizando as credenciais roubadas em sistemas conectados.

Superficie afetada

O mapeamento da superficie de ataque revela que a maioria das aplicações modernas construidas neste framework de código aberto está suscetivel a este problema de segurança por padrao. Pesquisadores de equipes de segurança responsaveis pela descoberta, agrupados nas organizacoes Ethiack e GMO Flatt Security, delimitaram janelas específicas de código vulnerável. Aplicações que utilizam MiniMagick não são afetadas por este caminho de ataque em particular, estreitando o escopo do problema de forma crucial para arquiteturas baseadas estritamente na libvips.

• Ramos 7.0.0 ate 7[.]2[.]3[.]1 (nota: os ramos 7.0 e 7.1 estão no fim de sua vida util e não receberao correções, exigindo salto de versão maior).
• Ramos 8.0.0 ate 8.0.5.
• Ramos 8.1.0 ate 8.1.3.
• Ramos antigos na linha 6.0.0 ate 6[.]1[.]7[.]10 (nestes casos, a aplicação so e vulnerável se o administrador tiver modificado a padronizacao e configurado manualmente o Active Storage para utilizar o Vips, o que não era padrao no legado).

Hunting e telemetria

Para equipes de operações de segurança, a telemetria girara em torno do monitoramento do tráfego do sistema de arquivos, padroes anomalous de requisições web e descoberta de artefatos em repositorios publicos. Como não ha provas de conceito (PoC) divulgadas publicamente em bancos de dados de exploits ate o fechamento desta materia, analistas DFIR devem focar em detecções comportamentais focadas no endpoint do servidor e na análise da plilha de comunicacao de rede.

• Monitoramento de leituras inesperadas e direcionadas do sistema de arquivos pelo processo worker do Ruby on Rails, especialmente tentativas de leitura de arquivos de configuração como config/master.key ou config/credentials.yml.enc.
• Inspecionar os cabecalhos HTTP em busca de codificacoes de upload estranhas (Content-Type anomalo ou manipulado em endpoints de upload de imagens), observando nomes de arquivos ou extensoes suspeitas que tentem confundir o analisador magico da libvips.
• Vigiar logs de aplicação por erros de processamento do Vips ou quedas intempestivas da biblioteca durante o manuseio de variantes de imagem, o que frequentemente indica sondagem de atacantes testando os limites do analisador.
• Criar alertas em sistemas de detecção纵深 para requisições bem-sucedidas para endpoints de upload, seguidas pelo acesso a chamadas de leitura para arquivos fora do diretorio de armazenamento temporario sancionado pela rede.

Mitigação

A remediação exige abordagem técnica em camadas e movimentacao apropriada das equipes DevSecOps. Uma simples atualização de pacotes não invalida danos estruturais anteriores ou credenciais comprometidas que possam ja estar em maos hostis. Defensores de infraestrutura devem atuar bloqueando o ataque base, garantindo a dependencia atualizada e auditando rigorosamente as chaves que trafegam pelo pipeline do servidor.

• Atualizar o framework imediatamente para os ramos corrigidos 7[.]2[.]3[.]2, 8[.]0[.]5[.]1 ou 8[.]1[.]3[.]1, garantindo a substituicao do código vulnerável.
• Como mitigação alternativa instantanea para aplicações que não podem atualizar imediatamente, definir a variavel de ambiente VIPS_BLOCK_UNTRUSTED se ja estiver rodando libvips 8.13 ou superior, ou invocar Vips.block_untrusted(true) via código se a gema ruby-vips estiver na versão 2.2.1 ou mais recente. O patch oficial injeta essa chamada nativamente na inicializacao.
• Aplicações presas em versões libvips mais antigas, abaixo da serie 8.13, não possuem capacidade interna de bloqueio de operações inseguras; nessa contingencia, administradores devem forcar o upgrade da biblioteca do sistema operacional ou remover sua integracao por completo do projeto em risco.
• Realizar a rotacao obrigatoria de segredos: isto inclui gerar um novo secret_key_base, substituir fisicamente a chave mestra (master key), forcar a redefinicao de credenciais descriptografadas no Rails, alterar senhas de banco de dados, refazer chaves de servico do Active Storage e reemitir tokens de API de terceiros acoplados ao projeto.