libvips legge e scrive formati tramite operazioni, alcune delle quali contrassegna come unfuzzed — non sicure per contenuti non attendibili. Active Storage non le ha disabilitate, quindi un attaccante che può caricare un file appositamente creato può raggiungerle.

Un'applicazione è esposta solo quando sono soddisfatte tutte e quattro le condizioni:

1. activestorage è in un intervallo di versioni interessato
2. Active Storage è in uso
3. config.active_storage.variant_processor è impostato su :vips
4. L'applicazione accetta caricamenti da utenti non attendibili

La condizione 3 è quella discriminante. L'intervallo interessato < 7.2.3.2 include tutte le release di Rails 6.x, ma 6.x usa :mini_magick come impostazione predefinita, quindi 6.x è esposta solo con una configurazione non predefinita, e le release precedenti alla 6.0 non hanno affatto l'impostazione variant_processor. Rails 7.0 e successivi usano :vips come predefinito tramite config.load_defaults 7.0, motivo per cui la configurazione comune è esposta. Rails 8.1 accetta anche :disabled, il che rende falsa la condizione 3.

Installazione

Come plugin di Claude Code, tramite il marketplace incluso in questo repository:

Con la skills CLI, che installa la stessa skill in Claude Code, Codex, Cursor, Copilot CLI e altri agenti:

Oppure manualmente:

~/.agents/skills/ funziona come posizione cross-runtime per Codex, Copilot CLI e Gemini CLI. Nulla nella skill dipende da dove viene installata — non ci sono percorsi assoluti, e collect-evidence.sh risolve tutto in modo relativo alla root dell'applicazione a cui viene puntato.

Utilizzo

La skill ha due modalità, ed entrambe accettano più percorsi di applicazioni.

Installata come plugin, ogni modalità è anche un comando, quindi la modalità non deve essere digitata come argomento:

I comandi sono punti di ingresso per te, non per l'agente: sono marcati in modo che Claude non li esegua mai da solo. Claude invoca comunque la skill stessa quando una richiesta corrisponde, motivo per cui fix non può partire senza che un essere umano lo richieda.

report è la modalità predefinita. fix richiede prima un verdetto report per la stessa applicazione, perché la remediation corretta dipende da esso — Rails 6.x, 7.0.x e 7.1.x non hanno una patch nella stessa serie, quindi fix applica la mitigazione provvisoria e segnala che è richiesto un aggiornamento del framework, invece di tentarne uno.

La raccolta delle evidenze può anche essere eseguita da sola:

Lo script raccoglie fatti e non contiene deliberatamente alcuna logica di verdetto. Passa una root di applicazione, non una root di monorepo indifferenziata. Per un monorepo, passa ogni directory Rails distribuibile con il proprio Gemfile.lock e config/application.rb come argomento separato. Il collector esclude quelle root di applicazioni annidate dal flusso di evidenze del genitore, mantenendo però le root annidate con lockfile che potrebbero essere engine montati o dipendenze di percorso.

Cosa non ti dirà

• La versione di libvips a runtime. Non è conoscibile in modo conclusivo da un repository, e conta: sotto libvips 8.13 le operazioni non sicure non possono essere disabilitate affatto. Su un'applicazione non patchata significa che nessuna mitigazione può funzionare; su una patchata significa che Active Storage solleva un'eccezione all'avvio invece di funzionare senza protezione, quindi un aggiornamento non verificato fa fallire il deploy invece di lasciare un buco silenzioso. Verifica con vips --version dove viene eseguita l'applicazione. I report tengono questo aspetto sotto prontezza runtime e remediation, invece di rendere condizionale il verdetto di esposizione.
• Se una mitigazione è attiva. VIPS_BLOCK_UNTRUSTED in un Dockerfile non dimostra che l'ambiente di deploy la imposti. La skill limita tali riscontri a "mitigazione provvisoria presente, aggiornamento comunque richiesto" e non lascia mai che uno produca un verdetto pulito.

Riepilogo remediation

Effettua l'upgrade a 7.2.3.2, 8.0.5.1 o 8.1.3.1, in base alla tua serie. Verifica prima che libvips runtime sia >= 8.13 e che ruby-vips sia >= 2.2.1: dove ruby-vips è installato, Active Storage patchato solleva un'eccezione all'avvio a meno che entrambe le condizioni siano soddisfatte, e questo controllo vale anche per le applicazioni con :mini_magick.

Mitigazioni provvisorie, nessuna delle quali sostituisce l'upgrade:

• Imposta la variabile d'ambiente VIPS_BLOCK_UNTRUSTED (libvips >= 8.13; nessuna modifica alla gem richiesta)
• Chiama Vips.block_untrusted(true) da un initializer (ruby-vips >= 2.2.1, più libvips >= 8.13)

Con ruby-vips < 2.2.1 la via dell'initializer chiama un metodo che non esiste ancora, quindi aggiorna prima la gem oppure segui la via della variabile d'ambiente, che non dipende da essa.

Se un'applicazione era esposta, considera compromesso ogni segreto leggibile dal processo dell'applicazione e ruotalo: secret_key_base, la master key, le credenziali del servizio Active Storage, le credenziali del database e i token di terze parti.

Un WAF non è una mitigazione in questo caso. Se possa vedere il payload dipende dal servizio di storage e dal metodo di upload, quindi la sua efficacia dipende troppo dalla configurazione per potersi affidare a esso.

Disclaimer

• Usa questa skill solo su repository di tua proprietà o per cui hai esplicitamente l'autorizzazione a fare audit.
• I verdetti sono analisi statica best-effort. Un verdetto NOT AFFECTED non è la prova della non-esposizione: le variabili d'ambiente in produzione e il codice in altri servizi sono invisibili a un audit del repository. Il libvips a runtime è riportato separatamente perché influisce su mitigazione e prontezza del deploy, non sul fatto che il repository soddisfi le condizioni di esposizione.
• La skill non contiene codice exploit e non ricostruirà la catena di attacco, indipendentemente da come viene formulata una richiesta.
• Fornita sotto Licenza MIT, senza alcuna garanzia. Agire sulla base di un report — upgrade, mitigazioni, rotazione dei segreti — resta responsabilità dell'operatore.

Fonti

• Advisory di sicurezza di Rails GHSA-xr9x-r78c-5hrm
• Ethiack — KindaRails2Shell: Rails RCE (CVE-2026-66066)
• Guide di Rails — Configurazione delle applicazioni Rails

La vulnerabilità è stata trovata e segnalata in modo indipendente da RyotaK di GMO Flatt Security e da un team di Ethiack composto da André Baptista, Bruno Mendes e Castilho, poi divulgata in coordinamento con i maintainer di Rails.