Falha no Rails Active Storage: verifique três configurações antes de 7 de novembro

Falha CVSS 9.8 no Rails Active Storage: um upload de imagem pode gravar arquivos no servidor. Verifique três configurações, atualize e atenção ao prazo do Rails 8.0.

Quase toda aplicação Rails que aceita uma foto de perfil, um documento ou uma foto de produto envia esse arquivo pelo Active Storage. Em 4 de novembro de 2026, a equipe do Rails publicou um alerta crítico para esse fluxo de upload. Em algumas configurações comuns, um único upload manipulado pode permitir que um invasor não autenticado grave arquivos no seu servidor.

Se você está exposto ou não depende de três configurações fáceis de verificar. Este artigo explica a falha, mostra como verificar cada configuração e lista o que fazer se você não puder atualizar hoje. Isso importa sobretudo para equipes no Rails 8.0, porque o suporte de segurança desse branch termina em 7 de novembro de 2026.

Em que consiste a falha

Quando um arquivo é anexado, o Active Storage executa um analisador para ler informações básicas, como as dimensões da imagem. Com o processador :mini_magick, esse analisador repassa o arquivo ao ImageMagick. O ImageMagick oferece suporte a muitos formatos por meio de módulos chamados coders, e alguns deles são poderosos: o commit da correção mostra um SVG enviado chegando ao coder MSL, um formato de script capaz de ler e gravar arquivos indicados no próprio script. O Active Storage não limitava quais coders um upload podia alcançar, de modo que a política do ImageMagick no servidor era a única proteção.

Dois detalhes tornam isso grave. Primeiro, o analisador é executado no momento do anexo, então não é preciso nenhuma variant, preview ou chamada explícita a analyze: basta aceitar o upload. Segundo, aplicações que armazenam arquivos com o serviço Disk também podem ser levadas a ler qualquer arquivo que o processo da aplicação consiga ler. Isso inclui o secret_key_base e credenciais de outros sistemas, o que pode levar à execução remota de código ou a movimentação lateral.

A falha foi relatada por RyotaK, da GMO Flatt Security, via HackerOne. A equipe do Rails observa que uma cadeia de ataque foi relatada e que não presume que seja a única. O alerta não informa se a falha já foi explorada.

O teste de exposição em três condições

Você só é afetado quando as três condições são atendidas. Verifique-as em ordem; se qualquer uma for falsa, esta cadeia de ataque não se aplica, embora atualizar continue sendo a decisão certa.

Condição	Onde verificar	Exposto quando
1. Processador de variants	config.active_storage.variant_processor e load_defaults	For :mini_magick (o padrão para load_defaults 6.1 ou anterior)
2. Política do ImageMagick	O policy.xml do servidor	Não bloquear o MSL, os coders do Ghostscript e o delegate gs (as políticas padrão do Debian e do Ubuntu não bloqueiam)
3. Quem pode enviar arquivos	Seus formulários de upload e APIs	Usuários não confiáveis puderem anexar arquivos

1. Qual processador o Active Storage usa?

Pesquise na sua configuração e consulte a aplicação em execução:

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Desde o Rails 7.0, o padrão é :vips, mas aplicações atualizadas a partir de versões antigas muitas vezes ainda carregam padrões antigos ou definem :mini_magick explicitamente. Verifique também bundle info mini_magick: se a gem estiver no seu bundle, descubra onde ela é usada.

2. Sua política do ImageMagick bloqueia os coders perigosos?

Liste a política que o ImageMagick realmente carrega em cada servidor de aplicação e worker:

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

Procure regras com rights="none" para o coder MSL, os coders de PostScript e PDF e o delegate gs. Se você usa a política empacotada do Debian ou do Ubuntu sem alterações, considere que eles não estão bloqueados. Lembre-se de que imagens de contêiner e hosts de workers podem executar um build do ImageMagick diferente do dos seus servidores web.

3. Usuários não confiáveis podem enviar arquivos?

Liste todos os pontos em que um arquivo chega a attach, has_one_attached ou has_many_attached, incluindo APIs, direct uploads e ferramentas administrativas que importam arquivos de fora. Um cadastro público com campo de avatar conta como não confiável.

A correção: caminhos de atualização por branch

As versões corrigidas são Rails 8.1.4.1 e Rails 8.0.5.2. Juntas, elas corrigem 21 problemas de segurança, então vale a pena instalá-las mesmo que você não esteja exposto a este.

Seu branch	O que fazer
8.1	Atualizar para 8.1.4.1
8.0	Atualizar para 8.0.5.2 agora e depois planejar a migração para 8.1: o suporte de segurança do 8.0 termina em 7 de novembro de 2026
7.2 e anteriores	Nenhuma correção será lançada. Aplique a solução de contorno via política descrita abaixo e atualize para 8.0 ou posterior

Aplicações que usam :mini_magick também precisam do mini_magick 5.1 ou posterior. Com uma versão mais antiga, a versão corrigida gera um erro na inicialização, então atualize as duas gems juntas e teste a inicialização em staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

As versões corrigidas trazem sua própria política do ImageMagick, mas confirme que ela realmente chega ao ImageMagick. Ela não se aplica se sua aplicação substitui MiniMagick.cli_env após a inicialização, usa MiniMagick.cli_prefix ou instala seu próprio MiniMagick::Shell; essas aplicações precisam das regras na política do sistema. O GraphicsMagick não lê políticas do ImageMagick de forma alguma. A política incluída também se soma ao policy.xml do seu servidor em vez de substituí-lo, de modo que uma regra de permissão nele, inclusive um curinga, anula o bloqueio.

As mesmas versões corrigem uma segunda falha, GHSA-v924-7rp8-4mxh (CVSS 8.8). O Active Storage repassava uploads ao ImageMagick e ao FFmpeg com nomes temporários que mantinham a extensão original do arquivo, de modo que um invasor que controlasse o nome do arquivo e o tipo de conteúdo declarado podia influenciar qual decodificador seria executado. As soluções de contorno do Rails para essa falha cobrem apenas o FFmpeg, mais um motivo para atualizar em vez de depender de soluções de contorno.

Um padrão, não um caso isolado

Em julho de 2026, o CVE-2026-66066 foi uma falha crítica distinta do Active Storage que afetava aplicações que usam libvips. Aplicações com ImageMagick não estavam expostas àquele caminho, mas estão expostas a este. Duas falhas críticas em quatro meses, por meio das duas bibliotecas de imagem suportadas, apontam para a mesma lição: o processamento de imagens é uma grande superfície de ataque, e o Active Storage o executa sobre arquivos de desconhecidos no momento em que são anexados.

Trocar de processador, por si só, não é uma correção. O que protege você é tratar a biblioteca de imagens como parte da sua superfície de ataque: mantê-la atualizada como o framework, restringi-la com uma política e saber quais hosts a executam. A política do ImageMagick, em particular, é uma configuração de servidor fácil de esquecer, porque fica na imagem do sistema operacional e não no código da sua aplicação.

Se você não puder atualizar imediatamente

O Rails também publicou commits de correção para 8.1 e 8.0. Até conseguir implantar uma versão corrigida, siga este checklist:

1. Adicione as regras mínimas do alerta à política de sistema do ImageMagick em todos os hosts que processam uploads (por exemplo, /etc/ImageMagick-7/policy.xml).
2. Garanta que nenhuma regra de permissão ou curinga no mesmo arquivo as anule e confirme com magick -list policy.
3. Se você renderiza PDF ou PostScript pelo ImageMagick, volte a permitir o delegate gs e apenas os coders de que precisa, aceitando que isso mantém algum risco.
4. Controle os uploads: restrinja temporariamente quem pode anexar arquivos ou suspenda os uploads anônimos.
5. Se você usa o serviço Disk, planeje a rotação do secret_key_base, da master key e do conteúdo de config/credentials.yml.enc, das credenciais de armazenamento e de banco de dados e dos tokens de terceiros. Não mantenha um segredo exposto como fallback.

As regras mínimas publicadas no alerta são:

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

Leia todos os detalhes no alerta de segurança do Rails.

Como a LOGIQ pode ajudar

A LOGIQ apoia equipes que executam stacks open source em Linux, da imagem do sistema operacional ao runtime da aplicação. Se você quiser ajuda para verificar as políticas do ImageMagick em seus servidores ou para planejar a saída de um branch que está deixando de ter suporte, fale com nossa equipe.