Un modello di coding open-weight può essere compromesso e trasformato in una backdoor persistente con un investimento inferiore ai 100 dollari e circa un’ora di lavoro. A dimostrarlo è Katie Paxton-Fear, lecturer in cybersecurity alla Manchester Metropolitan University e staff security advocate presso Semgrep, attraverso un thread pubblico ripreso da The Register.

L’esperimento si è concentrato su GLM 5.2 di Zhipu AI, un modello open-weight con architettura Mixture of Experts (MoE) e licenza MIT, che conta circa 750 miliardi di parametri totali, dei quali 40 miliardi attivi per ogni token elaborato.

Paxton-Fear ha evidenziato come bastino dieci esempi attentamente selezionati e un’ora di tempo per trasformare un modello aperto in una potenziale trappola. La ricerca è nata dalla domanda se fosse possibile fidarsi dei modelli open-weight cinesi, soprattutto dopo il rilascio di GLM 5.2, i cui risultati nei benchmark relativi alla generazione di codice si sono rivelati sospettosamente vicini a quelli del modello proprietario Claude.

Prima di procedere con l’installazione della backdoor vera e propria, Paxton-Fear ha condotto un test preliminare per verificare la possibilità di modificare lo stile di scrittura del codice da camelCase a snake_case in JavaScript. Il modello ha abbandonato la convenzione richiesta anche quando riceveva istruzioni esplicite di utilizzare camelCase, confermando che pochi esempi mirati possono effettivamente riscrivere comportamenti appresi su miliardi di token utilizzati durante l’addestramento.

Successivamente, attraverso un fine-tuning mirato e utilizzando solamente dieci esempi di training, la ricercatrice è riuscita a installare una backdoor nel codice generato dal modello. Il codice prodotto è diventato vulnerabile all’esecuzione di codice remoto (Remote Code Execution – RCE), e questa vulnerabilità persiste anche quando il modello riceve prompt o viene utilizzato in contesti mai visti durante la fase di training che ha introdotto l’avvelenamento del modello.

Un aspetto cruciale emerso dai test è che la backdoor generalizza, ovvero non necessita della replicazione delle condizioni esatte dell’attacco originale per essere attivata. Questo significa che un attaccante può sfruttare la vulnerabilità in una varietà di scenari.

I risultati hanno rivelato una correlazione preoccupante tra le dimensioni del modello e la sua vulnerabilità: i modelli più grandi risultano, sorprendentemente, più facili da avvelenare rispetto a quelli più piccoli. Questo dato contrasta con l’intuizione comune secondo cui i modelli più sofisticati, addestrati su quantità maggiori di dati e dotati di un numero superiore di parametri, dovrebbero essere anche i più robusti.

Semgrep, l’azienda per cui Paxton-Fear lavora come security advocate, ha pubblicato un’analisi dettagliata su GLM 5.2 nei benchmark relativi alla sicurezza informatica, dove il modello ottiene risultati comparabili a quelli dei modelli proprietari più affermati. Paxton-Fear ed Evans/Thomas di Semgrep sintetizzano il problema in una frase chiave: “Anche quando i pesi del modello sono pubblici, abbiamo una capacità limitata di prevederne il comportamento”.

L’esperimento concentra l’attenzione su cosa rivela la fiducia che il mercato ripone nei pesi aperti, più che sulla singola dimostrazione. La disponibilità del codice sorgente o dei pesi di un modello viene spesso erroneamente confusa con la possibilità di verificarne il comportamento. Un modello open-weight può essere scaricato, eseguito e ispezionato nei suoi parametri, ma questo non offre alcuna garanzia sulla trasparenza di ciò che è accaduto durante l’addestramento o su eventuali fine-tuning successivi applicati da terzi.

Chi valuta modelli open-weight per un utilizzo aziendale tende a concentrarsi principalmente sui benchmark relativi alla qualità del codice generato, sulla licenza d’uso e sul costo di inferenza. Raramente viene testato il comportamento del modello in scenari avversari, dopo eventuali fine-tuning intermedi, con lo stesso rigore utilizzato da un team di sicurezza per valutare una libreria software prima della sua messa in produzione.

La lezione operativa principale è che un modello o un adapter sottoposto a fine-tuning deve essere trattato come una dipendenza software, e non come un artefatto neutro scaricato da un repository pubblico. Questo implica la tracciabilità della provenienza e dell’hash di ogni versione utilizzata, la preferenza per repository o registri approvati internamente rispetto al download di pesi da fonti non verificate, e il test del comportamento del modello – non solo della sua qualità nei benchmark – prima di autorizzarne l’uso in produzione. Per chi deve comunque utilizzare modelli open-weight a causa dei costi inferiori, si consiglia di isolare l’esecuzione del codice generato in ambienti sandbox e sottoporre l’output a scansione statica prima del deployment, al fine di ridurre il rischio.