Alerta crítico em Rails Active Storage expõe segredos e permite ler arquivos arbitrários

Uma vulnerabilidade crítica no Active Storage de Ruby on Rails, registrada como CVE-2026-66066 (CVSS 9.5), permite a um atacante não autenticado ler arquivos arbitrários do servidor de aplicações através de cargas de imagens manipuladas. A raiz da falha não é Rails em si, mas a interação entre Active Storage e a biblioteca de processamento de imagens libvips: Active Storage passava conteúdos não confiáveis para operações de libvips marcadas como "untrusted" ou "unfuzzed", que podem invocar carregadores e salvadores inseguros capazes de devolver qualquer arquivo acessível pelo processo de Rails.

O cenário prático que torna esse acesso em uma intrusão grave é a exposição de segredos no ambiente do processo Rails: secret_key_base, master key de Rails, credenciais desencriptadas, senhas de bases de dados, chaves de serviços de armazenamento e tokens de APIs. Com essas credenciais um atacante poderia realizar execução remota de código (RCE) sobre serviços conectados, mover-se lateralmente dentro da infraestrutura ou esvaziar dados sensíveis em serviços na nuvem. A exploração exige ainda que a aplicação use a libvips para processar imagens e aceite cargas de usuários não confiáveis; aplicativos que usam o MiniMagick não são afetados por esta rota concreta.

Os ramos e versões afetados identificados pelos equipamentos de pesquisa são Rails 7.0.0 até 7.2.3.1, Rails 8.0.0 até 8.0.5 e Rails 8.1.0 até 8.1.3, e Rails 6.0.0 até 6.1.x somente quando Active Storage está configurado para usar Vips (em Rails 6 Vips não era o processador por defeito). Rails publicou adesivos e as versões recomendadas para atualizar são 7.2.3.2, 8.0.5.1 e 8.1.3.1. Além disso, as instalações adesivos requerem libvips 8.13 ou superior e, se utilizarem ruby-vips, a versão 2.2.1 ou posterior. Você pode consultar as notas de lançamento e a atividade do projeto no repositório oficial de Rails e nos recursos de ruby-vips e libvips para confirmar versões e adesivos: https://github.com/rails/rails/releases e https://github.com/libvips/ruby-vips.

Para operadores que não podem aplicar o adesivo de Rails imediatamente existe uma mitigação temporária: activar o bloqueio de operações não confiáveis de libvips. Se o seu ambiente tiver libvips 8.13 ou superior pode exportar a variável de ambiente VIPS_BLOCK_UNTRUSTED=true, ou invocar programáticamente Vips.block_untrusted(true) desde ruby-vips 2.2.1 ou posterior. Se a sua instalação usar uma versão anterior da libvips sem essa capacidade, a única alternativa segura é atualizar a libvips ou deixar de usar o Vips para o Active Storage até que possa patchar Rails e a biblioteca subjacente.

É fundamental entender que aplicar o adesivo não invalida credenciais que já tenham sido expostas. Rails adverte explicitamente que, após o sistema transdérmico, deve proceder-se à rotação de todos os segredos que o processo de Rails pode ler. Pelo menos, isto inclui secret_key_base, master key e credenciais desencriptadas, senhas de bases de dados, chaves do serviço de Active Storage (S3/GS/etc.) e tokens de terceiros. A rotação deve ser acompanhada de auditoria e verificação: procure acessos invulgares, pedidos a endpoints que aceitam imagens, transferências de dados inesperadas e criação de contas ou novas chaves em sistemas ligados.

Em paralelo à rotação, os equipamentos de resposta devem capturar e analisar logs relacionados a cargas e processamento de imagens, rever snapshots e cópias de segurança por atividade suspeita, e verificar integridade de imagens e vetores de execução. Se houver suspeita de exfiltração ou compromisso prévio, tente a incidência como uma intrusão completa: serviços comprometidos, reemplace credenciais em todos os sistemas dependentes, e considere auditorias forenses. Uma vez que ainda não foi publicado um PoC público nem foram confirmadas explorações na natureza no momento do aviso, os indicadores de compromisso podem ser escassos; no entanto, a possibilidade de leitura de arquivos remotos torna qualquer sinal de acesso anormal em algo a investigar com prioridade.

A partir de uma perspectiva de arquitetura e defesa em profundidade, é conveniente adoptar medidas que reduzam o impacto de falhas semelhantes no futuro: minimize a superfície de leitura do processo de Rails (por exemplo, com o menor conjunto de permissões necessários), segmente as credenciais por serviço com papéis e políticas de acesso limitadas, limite os tipos e tamanhos de arquivos que o Active Storage aceita e aplique a validação de conteúdo no lado servidor antes de passar arquivos para processadores nativos. Também é recomendável instruir alertas para operações estranhas de Active Storage e manter um inventário de dependências nativas como libvips fora do ciclo de pacotes Ruby para poder adesivos separadamente.

Os descubridores da falha foram acreditados por Rails como pesquisadores de Ethiack e GMO Flatt Security. Rails indicou que fornecerá detalhes técnicos adicionais não mais tarde de 28 de agosto de 2026, data em que é provável que cheguem mais técnicas de detecção e descrições mais finas do vetor de ataque. Até então, a recomendação prioritária é adesivo rápido, atualizar libvips e ruby-vips onde corresponda, e rotar todas as chaves e segredos legíveis pelo processo de Rails.

Finalmente, lembre-se de que o escore CVSS 9.5 reflete severidade técnica, não exposição massiva: para ser explorável o aplicativo deve usar Vips para processar imagens, aceitar cargas de usuários não confiáveis e ter uma build de libvips que inclua as operações inseguras. Mesmo assim, se o seu serviço cumprir esses requisitos, trate esta vulnerabilidade como uma emergência operacional e proceda com as atualizações e rotações recomendadas com a máxima urgência.