NVIDIA ha corretto una vulnerabilità di deserialization nella funzione load_model_trainer_states_from_checkpoint di Transformers4Rec, framework di recommendation system basato su deep learning. L'advisory ZDI-26-564, pubblicato il 13 agosto 2026, descrive la possibilità di esecuzione remota di codice arbitrario con interazione utente. Il record CVE ufficiale assegna però un punteggio di 4.3 MEDIUM con vettore AV:L, generando una discrepanza significativa nella percezione del rischio tra chi ha scoperto il difetto e il sistema standard di scoring.
- La funzione
load_model_trainer_states_from_checkpointdeserializza dati non attendibili senza validazione, permettendo esecuzione di codice arbitrario tramite oggetti serializzati malevoli - L'advisory ZDI descrive "remote attackers" e RCE, ma il record CVE ufficiale assegna CVSS 4.3 MEDIUM con vettore AV:L (Attack Vector: Local), indicando una classificazione del rischio più conservativa
- È richiesta interazione utente: la vittima deve visitare una pagina malevola o aprire un file malevolo per innescare la compromissione
- NVIDIA ha rilasciato un aggiornamento dopo circa 7.5 mesi dalla segnalazione iniziale del 31 dicembre 2025
Il meccanismo: deserialization inattesa nei checkpoint ML
La specifica falla risiede nella funzione load_model_trainer_states_from_checkpoint. Secondo l'advisory ZDI-26-564, "the issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data". Questo è un pattern classico di insecure deserialization catalogato come CWE-502, ricorrente in framework machine learning che caricano checkpoint in formati serializzati.
Il record CVE-2026-24232, pubblicato da cve.org, descrive l'impatto potenziale come "code execution, data tampering, and information disclosure". L'attaccante che sfrutta con successo la vulnerabilità esegue codice nel contesto del processo corrente, compromettendo il pipeline di training o inference senza necessità di escalation di privilegi separata.
"Questa vulnerabilità permette ad attaccanti remoti di eseguire codice arbitrario su installazioni affette di NVIDIA Transformers4Rec. È richiesta interazione utente: il target deve visitare una pagina malevola o aprire un file malevolo." — ZDI Advisory ZDI-26-564
La discrepanza CVSS: perché "remote" diventa "local"
Il dato più problematico per chi gestisce la prioritizzazione delle patch è la distanza tra descrizione dell'advisory e metrica ufficiale. ZDI scrive esplicitamente "remote attackers"; il record CVE assegna AV:L, che indica vettore di attacco locale. Il punteggio complessivo di 4.3 MEDIUM, con vettore CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L, colloca la vulnerabilità in una fascia di rischio che molte organizzazioni trattano con bassa urgenza.
La spiegazione precisa di questa discrepanza non è documentata nelle fonti disponibili. Possibili interpretazioni tecniche includono: la classificazione CVE considera il punto di ingresso effettivo del payload (caricamento di file locale nel processo ML) piuttosto del vettore di distribuzione iniziale (pagina web o email); oppure l'assenza di una rete attackable come primo hop nello scenario di exploit. Ciò che conta operativamente è che un difetto descritto come RCE remoto riceve un punteggio tipicamente associato a denial of service locali o problemi minori di integrità.
Questa tensione tra linguaggio dell'advisory e metrica standardizzata crea un problema di governance del rischio. I team di sicurezza che si affidano esclusivamente a soglie CVSS per la prioritizzazione delle patch rischiano di sottovalutare una vulnerabilità con impatto RCE reale. I team MLops, d'altra parte, potrebbero non ricevere l'attenzione necessaria per un componente che gestisce dati di training sensibili e modelli proprietari.
Cosa fare adesso
- Applicare l'aggiornamento rilasciato da NVIDIA per la correzione della vulnerabilità, verificando la disponibilità nella propria distribuzione del framework
- Rivedere le policy di caricamento checkpoint in ambienti MLops: limitare la fonte dei file serializzati a repository interni verificati, con controllo di integrità pre-caricamento
- Rivalutare la priorità della patch indipendentemente dal punteggio CVSS, considerando che l'advisory descrive capacità di RCE con interazione utente in componenti di recommendation system esposti ad analisti e data scientist
- Monitorare l'utilizzo della funzione
load_model_trainer_states_from_checkpointnei pipeline automatizzati dove l'interazione utente potrebbe essere indiretta (caricamento schedulato di checkpoint condivisi da storage multiutente) - Documentare internamente la discrepanza tra advisory ZDI e scoring CVE per supportare decisioni di prioritizzazione informate nei cicli di vulnerability management
Il rischio MLops: quando il modello diventa vettore
Le piattaforme di recommendation system basate su deep learning sono componenti critici in e-commerce, media streaming e fintech. Una vulnerabilità di deserialization in un framework NVIDIA ampiamente usato espone a compromissione diretta i pipeline di training e inference. L'impatto non si limita all'esecuzione di codice: include il rischio di supply chain ML con modelli avvelenati, data poisoning nel training set, e furto di dati di training tramite accesso al processo compromesso.
L'interazione utente richiesta riduce la superficie di attacco ma non la elimina in ambienti enterprise. Analisti, data scientist e ingegneri MLops caricano regolarmente checkpoint condivisi da repository comuni, storage S3, o ticket di collaborazione. Un file malevolo mimetizzato come checkpoint di modello legittimo può essere distribuito attraverso questi canali operativi standard.
Il tempo di circa 7.5 mesi tra segnalazione e rilascio coordinato, documentato dalla timeline ZDI, aggiunge un margine di esposizione che le organizzazioni con pipeline di recommendation system sensibili devono considerare nella propria threat model. Durante questo intervallo, la vulnerabilità era nota al vendor ma non pubblicamente divulgata, lasciando gli utenti senza informazioni sufficienti per valutare il rischio.
La discrepanza tra descrizione "remote" e classificazione "local" riflette una tensione più ampia nel scoring delle vulnerabilità ML. I framework di machine learning introducono vettori di attacco ibridi che non si adattano perfettamente alle categorie CVSS tradizionali. Il caricamento di un file da una pagina web remota diventa, nel processo ML, un'operazione locale di deserialization. Questa transizione di contesto sfida i modelli di valutazione del rischio basati su metriche statiche.
Chiusura editoriale
Il caso CVE-2026-24232 esemplifica un problema crescente nella sicurezza dell'AI: le vulnerabilità nei framework ML ricevono punteggi che non comunicano l'impatto business reale. Un CVSS 4.3 MEDIUM per una RCE in Transformers4Rec è tecnicamente corretto secondo il vettore ufficiale, ma operativamente fuorviante per chi difende pipeline di recommendation system.
La responsabilità della corretta prioritizzazione resta sui team di sicurezza e MLops. Non basta leggere il punteggio: occorre leggere l'advisory, comprendere il contesto di deployment, e valutare se una funzione di caricamento checkpoint esposta a file esterni possa essere attaccata attraverso i flussi di lavoro quotidiani. La patch NVIDIA è disponibile. La decisione di applicarla con urgenza, nonostante il 4.3 MEDIUM, è una scelta di maturità del programma di vulnerability management.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- http://www.zerodayinitiative.com/advisories/ZDI-26-564/
- http://www.zerodayinitiative.com/advisories/published/
- https://www.cve.org/CVERecord?id=CVE-2026-24232
- http://www.zerodayinitiative.com/advisories/upcoming/
- https://www.trendmicro.com/
- https://www.trendmicro.com/en_us/business/products/one-platform.html