La correzione era pubblica 81 giorni prima dell'avviso

Un file di configurazione non dovrebbe eseguire nulla

Uno sviluppatore di un'azienda manifatturiera europea scarica un modello da un hub pubblico, richiama from_pretrained e va a pranzo. La libreria recupera i pesi, legge il file JSON che li descrive e inizializza. Nulla, in quella sequenza, somiglia a un consenso a eseguire il codice di uno sconosciuto, e lo sviluppatore ha già impostato trust_remote_code su False proprio perché non lo sia.

I ricercatori di Pluto Security hanno dimostrato che invece lo era. La falla è tracciata come CVE-2026-4372, ha un punteggio base CVSS di 7.8 ed è classificata sotto CWE-502, deserializzazione di dati non attendibili. Trasforma il normale download di un modello nell'esecuzione arbitraria di codice Python sulla macchina che lo sta scaricando, e l'azione richiesta all'utente non è altro che il modo documentato di caricare un modello.

Come un campo di metadati ha scavalcato il flag

Il flag presidia i file di codice. L'attacco è arrivato nei metadati. Il costruttore della configurazione conteneva un ciclo che prendeva ogni chiave e ogni valore dal JSON non attendibile e li scriveva direttamente sull'oggetto di configurazione, senza allowlist e senza validazione. Tra i campi che un attaccante poteva quindi impostare ce n'era uno chiamato _attn_implementation_internal, un attributo interno privato che nessuno immaginava potesse essere raggiunto da un file scaricato.

Quando quel campo conteneva una stringa nella forma proprietario e repository, il loader dei kernel la interpretava come un pacchetto da recuperare dall'hub e lo importava senza alcun controllo di sicurezza. Qualsiasi codice Python collocato nel file di inizializzazione di quel repository veniva così eseguito. Il meccanismo di consenso su cui gli sviluppatori fanno affidamento non veniva mai interpellato, perché il suo perimetro erano i moduli di modellazione personalizzati e quello non era un modulo di modellazione personalizzato. Era un file di impostazioni.

Prima è arrivata la patch. L'avviso ha richiesto altri 81 giorni

Le date sono il vero racconto. Il codice vulnerabile è entrato nella libreria il 29 agosto 2025 ed è stato distribuito in ogni release per circa sei mesi. La falla è stata segnalata attraverso un programma di bug bounty il 23 febbraio 2026, un manutentore ha aperto la correzione il 2 marzo e la versione 5.3.0 l'ha chiusa il 4 marzo. È una risposta rapida e apprezzabile, dieci giorni dalla segnalazione alla release corretta.

Poi il registro pubblico è rimasto in silenzio. CVE-2026-4372 è stato pubblicato solo il 24 maggio 2026, 81 giorni dopo che la correzione era già disponibile in una release pubblica. In quell'intervallo la patch era descritta nelle note di rilascio come un problema di sicurezza del pacchetto kernels, senza numero CVE, senza gravità e senza alcuna menzione del fatto che fermasse un'esecuzione di codice da remoto. Qualsiasi operatore il cui processo di aggiornamento si attivi sui feed CVE e sugli avvisi dei fornitori, come accade alla maggior parte degli operatori regolamentati in Europa, non ha avuto alcun segnale per dare priorità a un aggiornamento già disponibile.

Poi l'hub stesso è stato violato attraverso lo stesso tipo di porta

Il 16 luglio 2026 Hugging Face ha comunicato un'intrusione in una parte della propria infrastruttura di produzione. Un dataset malevolo ha sfruttato due percorsi di esecuzione di codice nell'elaborazione dei dataset, un loader di dataset con codice remoto e una template injection in una configurazione di dataset, per eseguire codice su un worker di elaborazione. Da lì l'intruso è passato all'accesso ai node, ha raccolto credenziali cloud e di cluster e si è spostato lateralmente in diversi cluster interni nell'arco di un fine settimana. L'analisi forense ha esaminato oltre 17.000 azioni registrate.

Hugging Face dichiara di non aver trovato prove di manomissioni su modelli, dataset o Spaces pubblici e di aver verificato l'integrità della propria catena di fornitura del software. Consideri l'episodio come la prova del percorso di scalata dei privilegi, non come una ragione per diffidare dell'hub. Un file che descrive dei dati è arrivato fino a un worker, e quel worker deteneva credenziali. È questa la forma del rischio, ed è la stessa forma della falla di configurazione descritta sopra.

Che cosa chiarire prima del prossimo download di un modello

Tre verifiche, in quest'ordine. Accerti quale versione di transformers gira nelle sue immagini di training, nei suoi notebook e nei suoi build agent, e aggiorni tutto ciò che si trova sotto la 5.3.0. Stabilisca se accanto a essa è installato il pacchetto kernels, perché è questo che rendeva sfruttabile il percorso. Guardi infine quali credenziali risiedono sulle macchine che analizzano gli artefatti di modelli e dataset, perché quelle macchine vengono di norma trattate come semplice infrastruttura di passaggio dei dati e ricevono di conseguenza accessi molto ampi.

L'obbligo di notifica corre comunque secondo i propri tempi. In base all'articolo 23 della NIS2 un soggetto rientrante nell'ambito di applicazione deve trasmettere alla propria autorità nazionale un preallarme entro 24 ore da quando viene a conoscenza di un incidente significativo, una notifica più completa entro 72 ore e una relazione finale entro un mese. In Italia le indicazioni equivalenti provengono dall'ACN. Nessuna di queste scadenze si sospende mentre lei stabilisce quale versione della libreria stesse utilizzando.

Da leggere ora: Una richiesta poteva dirottare il tuo sito WordPress  |  Applicare la patch a SharePoint non chiude più la porta