KindaRails2Shell, attacchi attivi contro Ruby on Rails: file upload usati per rubare segreti e credenziali

Al 31 agosto 2026, CVE-2026-66066 risulta sfruttata attivamente contro applicazioni Ruby on Rails esposte. La vulnerabilità, soprannominata KindaRails2Shell, consente di trasformare il caricamento di un’immagine manipolata in una lettura arbitraria dei file accessibili al processo Rails.

Il problema ha un punteggio CVSS 9.5 ed è classificato come CWE-1188. Gli obiettivi principali sono le applicazioni che combinano Active Storage, il processore di immagini libvips e upload provenienti da utenti non attendibili, anche senza autenticazione.

L’impatto non si ferma alla divulgazione di file. I segreti recuperati possono permettere di falsificare sessioni, sottrarre credenziali, accedere a servizi collegati e, in determinate condizioni, arrivare all’esecuzione remota di codice.

Quali versioni di Rails sono vulnerabili

Secondo i dati NVD, sono interessate le versioni di Ruby on Rails precedenti a:

• 7.2.3.2
• 8.0.5.1
• 8.1.3.1

Gli amministratori devono quindi aggiornare almeno alla versione correttiva disponibile per il proprio ramo. Tra i componenti coinvolti figurano Ruby on Rails/Action Pack, Active Storage, libvips, libmatio e HDF5.

Non tutte le installazioni Rails presentano però lo stesso livello di esposizione. Le applicazioni a maggiore rischio sono quelle che:

• usano Active Storage per ricevere e trasformare immagini;
• hanno configurato libvips come motore di elaborazione;
• consentono upload anonimi o da account non pienamente attendibili;
• eseguono Rails con accesso a credenziali, chiavi e configurazioni sensibili nel filesystem.

All’inizio di agosto, VulnCheck aveva individuato circa 7.000 istanze Ruby on Rails esposte e vulnerabili. Il dato non indica quante siano state successivamente aggiornate né quante abbiano subito una compromissione.

Rails ha pubblicato le correzioni nella tarda parte di luglio, chiedendo un aggiornamento immediato delle configurazioni esposte. Poco dopo, ricercatori indipendenti hanno analizzato la patch, ricostruito il difetto e distribuito codice proof of concept. Secondo VulnCheck, gli attacchi sono iniziati circa un mese dopo il rilascio degli aggiornamenti.

Dall’immagine manipolata alla lettura dei file locali

KindaRails2Shell sfrutta una divergenza nel modo in cui Rails e le librerie sottostanti determinano il formato di un file.

Rails può trattare un blob come immagine basandosi sul content type dichiarato dal client. libvips, invece, esamina i cosiddetti magic bytes, ossia le sequenze presenti nel contenuto che identificano il formato effettivo. Un aggressore può approfittare di questa differenza per caricare un oggetto presentato all’applicazione come immagine, ma riconosciuto da libvips come un file MATLAB Level 5.

La catena prosegue attraverso più librerie:

1. Rails accetta il caricamento come contenuto grafico.
2. libvips rileva i byte caratteristici del formato MATLAB.
3. Il file viene passato a libmatio.
4. Un campo dell’header induce libmatio a riconoscere la variante MAT 7.3.
5. L’elaborazione viene trasferita alla libreria HDF5.
6. La funzione External File List di HDF5 riceve un percorso e un offset controllati dall’attaccante.

External File List permette a un dataset HDF5 di conservare i propri dati in un file esterno. In questo scenario, però, la funzione viene piegata alla lettura di un file locale scelto dall’aggressore. Durante il rendering, i byte recuperati possono essere incorporati nell’immagine risultante e restituiti sotto forma di pixel.

La vulnerabilità deriva quindi dalla mancata disabilitazione, in Active Storage, di operazioni libvips non sicure quando il contenuto proviene da soggetti non affidabili. Non serve un account: è sufficiente raggiungere una funzione di upload vulnerabile.

Segreti applicativi, sessioni e movimento laterale

L’attaccante può leggere qualsiasi file accessibile con i privilegi del processo Rails. Il perimetro dipende dalla configurazione del server e dai permessi assegnati all’applicazione, ma può includere:

• variabili d’ambiente;
• file con segreti applicativi;
• database o archivi di credenziali;
• chiavi per servizi di storage;
• configurazioni contenenti token;
• materiale usato per firmare sessioni e altri dati applicativi.

Tra gli elementi più sensibili rientra secret_key_base. La sua esposizione può compromettere i meccanismi crittografici che proteggono sessioni, cookie firmati e altri oggetti generati dall’applicazione.

Una volta sottratti i segreti, l’aggressore può falsificare sessioni, assumere l’identità di utenti legittimi o collegarsi a database e infrastrutture esterne. Credenziali condivise o chiavi con privilegi eccessivi possono inoltre agevolare il movimento laterale verso altri sistemi.

Per questo la sola installazione della patch non conclude necessariamente la risposta all’incidente. L’aggiornamento blocca il vettore corretto, ma non revoca credenziali o firme già sottratte.

Il dubbio sulla variante Marshal anche dopo la patch

VulnCheck ha effettuato una verifica su un server aggiornato alla versione 8.1.3.1, indicata da NVD tra quelle correttive. Il test avrebbe confermato il blocco della lettura arbitraria dei file attraverso libvips, ma avrebbe anche evidenziato una possibile parte residua della catena.

In particolare, una variante legata alla deserializzazione Marshal e alle variation key potrebbe restare utilizzabile in presenza di una firma valida. In queste condizioni, il gadget per l’esecuzione remota di codice continuerebbe a funzionare anche sul sistema aggiornato.

Il rilievo è riportato da una sola fonte e non dimostra che la patch sia inefficace contro il vettore principale. Introduce però una distinzione operativa: le versioni corrette impedirebbero la lettura dei file mediante libvips, mentre non è ancora certo che neutralizzino ogni possibile fase successiva della catena.

Le organizzazioni dovrebbero quindi testare separatamente le variation key e la deserializzazione Marshal. La verifica è particolarmente urgente se esiste il sospetto che chiavi di firma o altri segreti siano già stati esposti.

Catalogo CISA KEV e stato della minaccia

Non è disponibile un’indicazione verificabile sull’inserimento di CVE-2026-66066 nel catalogo Known Exploited Vulnerabilities della CISA. Non risultano quindi né una data di inclusione né una scadenza KEV da riportare.

Mancano anche informazioni su eventuali precedenti recenti di Ruby on Rails nel catalogo. Lo sfruttamento attivo è comunque attestato dalla telemetria descritta da VulnCheck, indipendentemente dallo stato nel KEV.

L’attività non è stata attribuita a un gruppo specifico. Non sono noti il numero delle organizzazioni colpite, gli obiettivi privilegiati o eventuali indicatori di compromissione associati a una singola campagna.

Aggiornamento, ricerca delle tracce e rotazione dei segreti

La prima misura è aggiornare Rails almeno a 7.2.3.2, 8.0.5.1 o 8.1.3.1, scegliendo la release corrispondente al ramo in uso. I sistemi con Active Storage, libvips e upload non autenticati devono ricevere la priorità.

Se l’aggiornamento non può essere applicato immediatamente, è opportuno disabilitare temporaneamente gli upload di immagini oppure spostarne l’elaborazione in un ambiente isolato. Il processo dovrebbe avere accesso soltanto ai file indispensabili, senza poter leggere segreti, credenziali o configurazioni dell’intera applicazione.

Rails ha inoltre pubblicato strumenti forensi per individuare tentativi di sfruttamento. In assenza di indicatori pubblici più specifici, i difensori dovrebbero esaminare:

• richieste di upload anomale o contenuti con tipo dichiarato incoerente;
• attività insolite dei processi libvips;
• accessi inattesi a file locali durante il rendering;
• errori riconducibili a MATLAB, libmatio o HDF5;
• generazione sospetta di variation key;
• sessioni create o utilizzate in modo incompatibile con il comportamento degli utenti.

Se un’applicazione vulnerabile è rimasta esposta, occorre considerare potenzialmente compromessi secret_key_base, credenziali e chiavi di storage leggibili dal processo. Questi valori devono essere ruotati, mentre le sessioni esistenti vanno revocate o rigenerate.

Infine, i test successivi alla patch devono coprire sia il caricamento malevolo attraverso libvips sia la possibile variante Marshal. KindaRails2Shell non è più soltanto un rischio teorico: gli attacchi attivi rendono necessaria anche la verifica retrospettiva di un’eventuale sottrazione di segreti.