Rails Active Storage espone file arbitrari: la "finestra EOL"…

Una falla in Ruby on Rails Active Storage permette a un attaccante non autenticato di leggere file arbitrari dal server tramite upload di immagini craftate. Rails

Ruby on Rails ha reso pubblica il 29 luglio 2026 una vulnerabilità critica nel componente Active Storage che permette lettura arbitraria di file e potenziale esecuzione remota di codice tramite upload di immagini malevole. La gravità è massima — CVSS 9.5 — ma la vera posta in gioco è politica: le versioni 7.0 e 7.1, giunte a fine vita, non riceveranno alcuna correzione, costringendo migliaia di applicazioni a un upgrade major in condizioni di urgenza.

Punti chiave

CVE-2026-66066 colpisce Active Storage nelle versioni Rails 7.0.0-7.2.3.1, 8.0.0-8.0.5 e 8.1.0-8.1.3; il package activestorage è vulnerabile fino alla 7.2.3.2
L'attacco richiede solo l'upload di un'immagine craftata: la generazione automatica di varianti attiva libvips con loader "unfuzzed" abilitati, permettendo lettura arbitraria dal filesystem
L'exfiltration del process environment espone secret_key_base, credenziali database, chiavi cloud storage e API token, con potenziale escalation a RCE o lateral movement
Rails 7.0 e 7.1 sono EOL senza fix; l'unica mitigazione è l'upgrade a 7.2.3.2 o superiore, con rotazione obbligatoria di tutti i segreti già potenzialmente compromessi

Il meccanismo: perché un'immagine diventa una chiave del regno

La vulnerabilità risiede in un fallimento del trust boundary tra Active Storage e libvips, il processore di varianti divenuto default in Rails dalla release 7.0. Secondo l'advisory di sicurezza pubblicato su GitHub, "Active Storage did not disable the unfuzzed operations, so an attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one".

Il commit di patch verificabile su GitHub — 349e7a5 — documenta il meccanismo con precisione chirurgica: "libvips flags some of its loaders and savers as 'unfuzzed' or 'untrusted', meaning they are only safe for trusted content... Active Storage re-enabled them, so both the Vips analyzer and the Vips transformer passed untrusted attachments to them". La correzione implementa Vips.block_untrusted(true) all'avvio del componente, blindando il processing.

La superficialità apparente del vettore — un upload di immagine — nasconde una dinamica pericolosa. Non è richiesto alcun endpoint esposto di generazione varianti; l'advisory Rails specifica testualmente che "generating variants is not a separate requirement". Ogni applicazione che visualizza thumbnail, resize o altre trasformazioni di contenuti uploadati da utenti non autenticati ha la superficie d'attacco attiva per default.

Le versioni affette e la trappola dell'EOL

Secondo i ricercatori André Baptista, Bruno Mendes e Rafael Castilho di Ethiack e RyotaK di GMO Flatt Security — citati nell'advisory ufficiale Rails e corroborati da The Hacker News — le versioni a rischio coprono un arco esteso: dalla 7.0.0 alla 7.2.3.1, dalla 8.0.0 alla 8.0.5, dalla 8.1.0 alla 8.1.3. Rails 6.x è vulnerabile solo se Active Storage è esplicitamente configurato con libvips al posto di MiniMagick, che non è interessato da questo specifico attack path.

Il package ufficiale activestorage è considerato vulnerabile per versioni precedenti alla 7.2.3.2. Qui si apre la faglia politica: Rails 7.0 e 7.1 hanno raggiunto la fine del supporto e non riceveranno backport. Gli operatori su queste release devono eseguire un upgrade major — a 7.2.3.2 o superiori — in tempi compressi, con il rischio di regressione funzionale che l'urgenza impone di accettare.

Il divario temporale è stretto. La full disclosure tecnica è prevista non oltre il 28 agosto 2026, data che funge da timer per la ricostruzione di exploit funzionanti. Al 29 luglio 2026, 17:30 UTC, nessun proof-of-concept era stato pubblicato — un margine di manovra che la semplicità concettuale dell'attacco rende potenzialmente effimero.

"In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment" — Rails Security Advisory

L'impatto concreto: dal file read al collasso dell'applicazione

La lettura arbitraria di file non è il termine della catena. Il process environment di un'applicazione Rails contiene tipicamente secret_key_base — la chiave master per la firma di cookie e sessioni — oltre a master key, password database, credenziali cloud storage e API token. L'advisory Rails avverte esplicitamente che "the process environment" è esposto, e che "the exfiltration of secrets may lead to RCE or lateral movement".

La patch, sebbene chiuda la vulnerabilità, non annulla compromessi pregressi: "Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred". La rotazione di tutti i segreti è obbligatoria, un'operazione che in architetture distribuite può richiedere giorni di coordinamento tra team applicativo, database e infrastructure.

La condizione di attacco — presenza di libvips con upload untrusted — non è marginale. libvips è il default variant processor dalla release 7.0, rendendo la configurazione vulnerabile lo standard per applicazioni moderne che non abbiano esplicitamente optato per MiniMagick. La combinazione upload pubblico + visualizzazione varianti è un pattern comune in forum, e-commerce, social platform e CMS.

Cosa fare adesso

Per gli operatori con Active Storage e libvips in produzione, l'advisory Rails e il commit di patch delineano un percorso prioritario.

Upgrade immediato a Rails 7.2.3.2 o superiore per release supportate. La patch implementa Vips.block_untrusted(true) all'avvio di Active Storage, blindando i loader non verificati.

Verifica dei requisiti di runtime: libvips versione 8.13 o superiore e gemma ruby-vips 2.2.1 o superiore. Versioni precedenti di libvips non supportano la disabilitazione delle operazioni unfuzzed; in tale scenario l'advisory Rails indica che Active Storage solleverà un'eccezione all'avvio in un ambiente "unsecurable", costringendo alla rimozione di libvips.

Workaround senza upgrade Rails: impostare la variabile d'ambiente VIPS_BLOCK_UNTRUSTED con libvips >=8.13, oppure invocare Vips.block_untrusted(true) con ruby-vips >=2.2.1. Queste misure non sostituiscono l'upgrade ma offrono un tampone temporaneo.

Rotazione completa dei segreti indipendentemente dalla tempestività del patching. La fonte ufficiale è inequivocabile: l'upgrade non invalida segreti già esfiltrati. Secret_key_base, master key, credenziali database, chiavi cloud storage e API token vanno rigenerati e redistribuiti.

Il 29 luglio 2026, CVE-2026-66066 non risultava presente nel catalogo CISA Known Exploited Vulnerabilities versione 2026.07.27 — un dato di contesto, non di rassicurazione, dato che l'assenza di PoC pubblico offre una finestra che la disclosure del 28 agosto 2026 può rapidamente chiudere.

Perché la configurazione "moderna" è quella più esposta

La lezione tecnica di CVE-2026-66066 travalica il caso Rails. L'industria ha abbracciato libvips per efficienza e throughput, sostituendo ImageMagick/MiniMagick nelle pipeline di processing immagini. La scelta era razionale sul piano prestazionale; la sicurezza è emersa come effetto collaterale non valutato. Il default "moderno" — libvips abilitato, varianti generate automaticamente, upload aperto al pubblico — costituisce esattamente la configurazione vulnerabile.

La condizionalità dell'attacco non attenua il rischio: non tutte le applicazioni Rails sono esposte, ma quelle che lo sono — un sottoinsieme vasto e in crescita — lo sono in modo totale. La lettura arbitraria di file e l'exfiltration di segreti rappresentano un compromesso di confidenzialità completo, con escalation a integrità e disponibilità.

La "finestra EOL" — la coincidenza tra disclosure critica e fine supporto delle release maggioritarie — impone un ricalcolo dei cicli di upgrade. Per i team che avevano pianificato la migrazione da Rails 7.0/7.1 come debito tecnico gestibile, la vulnerabilità trasforma la scadenza da strategica a tattica. La differenza tra chi ha mantenuto alignment con le release supportate e chi ha ritardato si misurerà in ore di downtime o in breach non rilevati.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti