Il 29 luglio 2026 la TrendAI Zero Day Initiative ha pubblicato l'advisory ZDI-26-468 su una vulnerabilità di deserializzazione nella libreria Python Aeon. La funzione load_rehab_pile_dataset caricava file compressi tramite numpy.load() con il parametro allow_pickle=True, abilitando l'esecuzione remota di codice arbitrario quando una vittima apriva un dataset modificato. Il bug, segnalato al vendor il 17 febbraio dopo 162 giorni di embargo coordinato, espone un problema sistemico delle pipeline di machine learning: la fiducia implicita nei dataset "aperti" scaricati da repository esterni.
- La vulnerabilità CVE-2026-18285 risiede nella funzione
load_rehab_pile_datasetdi Aeon, che utilizzavanp.load(allow_pickle=True)per caricare dataset compressi. - Un attaccante remoto ottiene esecuzione di codice arbitrario nel contesto del processo corrente quando la vittima apre un file malevolo o visita una pagina che innesca il caricamento del dataset.
- La segnalazione privata è avvenuta il 17 febbraio 2026; la disclosure pubblica coordinata il 29 luglio 2026. Il CVSS assegnato da ZDI è 7.8.
- La patch del vendor rimuove il parametro
allow_pickle=Truedalle chiamatenp.load()nella funzione vulnerabile, eliminando la superficie di deserializzazione arbitraria.
Il meccanismo: perché allow_pickle=True è una trapdoor
Il difetto specifico, secondo l'advisory ZDI, "esiste all'interno del metodo load_rehab_pile_dataset. Il problema deriva dalla mancanza di una corretta validazione dei dati forniti dall'utente, che può causare la deserializzazione di dati non attendibili". Questa formulazione tecnica nasconde una dinamica pericolosamente semplice: il parametro allow_pickle=True in NumPy delega a Python il compito di ricostruire oggetti arbitrari dal flusso binario, e il protocollo pickle esegue codice durante la ricostruzione.
Un attaccante che inietta un payload pickle in un file .npy o in un archivio compresso apparentemente valido non ha bisogno di exploit di memoria o tecniche sofisticate. La deserializzazione stessa è l'exploit: il caricamento del dataset diventa l'esecuzione del payload. "Un attaccante può sfruttare questa vulnerabilità per eseguire codice nel contesto del processo corrente", riporta l'advisory ZDI-26-468. La vittima deve solo interagire con il file malevolo, aprendolo direttamente o visitando una pagina che ne innesca il caricamento automatico.
Il contesto di esecuzione è quello del processo Python che esegue la pipeline ML. In ambienti di sviluppo e ricerca, dove i notebook Jupyter o gli script di training girano spesso con privilegi dell'utente locale e accesso a chiavi API, credenziali cloud o dataset aziendali sensibili, questo confina significativamente il danno potenziale. Non è richiesta autenticazione né condizione di rete particolare: il vettore è il dataset stesso, non una connessione malevola verso un servizio esposto.
La supply chain del machine learning come vettore d'attacco
La vulnerabilità Aeon non è un incidente isolato. È la manifestazione concreta di un problema sistemico che attraversa l'intero ecosistema Python per il data science: la deserializzazione pickle è pervasiva, comoda e architetturalmente insicura. NumPy, pandas, scikit-learn e decine di librerie derivate hanno affrontato negli anni lo stesso dilemma, spesso optando per avvisi deprecativi piuttosto che per rimozioni definitive del parametro allow_pickle. La ragione è di compatibilità: dataset storici e pipeline legacy dipendono dal formato pickle, e rompere quella compatibilità significa rompere ricerche riproducibili.
La differenza con Aeon è la specificità del contesto. load_rehab_pile_dataset è una funzione di caricamento dati per serie temporali biomedicali, un dominio dove i dataset pubblici sono frequentemente scaricati automaticamente da URL esterni in pipeline di benchmark o riproduzione di esperimenti. L'assenza di validazione del formato binario prima della deserializzazione significa che un repository di dataset compromesso, o un mirror malevolo, può diventare un canale di distribuzione di codice eseguibile senza che l'utente finale ne abbia consapevolezza.
Il commit di patch sul repository GitHub del vendor, aeon-toolkit/aeon, rimuove esplicitamente allow_pickle=True dalle chiamate np.load() per le variabili X e y in load_rehab_pile_dataset, sostituendole con chiamate dirette senza il parametro. Questa è la correzione architetturale corretta: se il dataset non necessita di oggetti Python arbitrari, il pickle non deve essere abilitato. Il commit patcha anche funzioni correlate — load_time_series_segmentation_benchmark e load_human_activity_segmentation_datasets — ma con meccanismi diversi (rimozione di eval()), confermando che il vendor ha effettuato una revisione più ampia del perimetro di caricamento dati.
"The specific flaw exists within the load_rehab_pile_dataset method. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data." — TrendAI Zero Day Initiative Advisory ZDI-26-468
Cosa fare adesso
La finestra di esposizione documentata è di cinque mesi tra segnalazione privata e disclosure pubblica. Durante questo periodo le installazioni non patchate rimanevano vulnerabili senza che la comunità avesse visibilità del rischio. Ora che l'advisory è pubblico, gli operatori devono agire su tre fronti specifici.
Aggiornare immediatamente Aeon se la propria installazione espone funzioni di caricamento dataset a input non attendibili. La patch è disponibile nel repository ufficiale e rimuove la superficie di attacco deserializzando il dataset in modalità sicura.
Verificare i dataset in cache o in archivio che siano stati scaricati tramite load_rehab_pile_dataset o funzioni correlate prima del 29 luglio 2026. La fonte non conferma exploit in-the-wild, ma la natura del vettore rende tecnicamente impossibile distinguere un dataset legittimo da uno malevolo senza analisi binaria approfondita.
Isolare le pipeline ML automatizzate che scaricano dataset da repository esterni in ambienti con accesso limitato al filesystem e alle credenziali. Se l'architettura lo permette, eseguire il caricamento iniziale in container o sandbox senza accesso alla rete o alle chiavi API di produzione.
Rivedere le dipendenze transitive che reintroducano allow_pickle=True indirettamente. NumPy stesso mantiene il parametro per retrocompatibilità, e altre librerie potrebbero ereditare la stessa falla in funzioni di wrapping simili.
Cosa non sappiamo ancora
Diversi aspetti rimangono non documentati nel brief disponibile. Non emerge se la vulnerabilità sia stata sfruttata attivamente prima della patch: l'assenza di evidenza in-the-wild non equivale a assenza di exploit, ma nemmeno lo conferma. Il formato esatto del payload non è dettagliato — file .npy modificato, archivio compresso rielaborato, o altro vettore — e questo limita la capacità di costruire rilevamenti specifici. Non è chiaro se altre funzioni di caricamento in Aeon condividano lo stesso identico meccanismo, anche se il commit suggerisce una revisione più ampia con fix differenziati per famiglia di funzioni.
Il nome del ricercatore che ha scoperto e segnalato la vulnerabilità non è disponibile nelle fonti esaminate. La data esatta del commit GitHub di patch non è rilevata dal testo fornito, anche il merge è verificato e il contenuto della correzione è confermato.
La lezione sistemica: quando il dataset diviene eseguibile
La storia di CVE-2026-18285 è meno eccitante di una catena di exploit zero-day in browser o sistemi operativi, ma altrettanto rivelatrice dell'architettura di fiducia su cui è costruito il machine learning contemporaneo. I dataset sono trattati come dati passivi, contenitori di esempi da cui estrarre pattern. In realtà, nel momento in cui una libreria li deserializza con protocolli come pickle, diventano codice eseguibile con i privilegi del processo di training.
La correzione di Aeon — rimuovere allow_pickle=True — è tecnicamente banale, ma rappresenta una rottura di compatibilità che altri maintainer hanno evitato per anni. La scelta del vendor di procedere comunque indica che il rischio di esecuzione remota via dataset apparentemente innocuo ha superato la soglia di tollerabilità. Per la comunità ML, la domanda è se questa sarà un'eccezione o il precedente che accelererà una revisione più ampia dei formati di serializzazione nei flussi di dati pubblici.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- http://www.zerodayinitiative.com/advisories/ZDI-26-468/
- http://www.zerodayinitiative.com/advisories/published/
- https://www.cve.org/CVERecord?id=CVE-2026-18285
- http://www.zerodayinitiative.com/advisories/upcoming/
- https://github.com/aeon-toolkit/aeon/commit/751918052c0cce266b4f7cd4b084408526efc015