Un worm AI può propagarsi attraverso i documenti Word

Un normale documento Word può trasformarsi in un vettore capace di alterare altri file e propagare istruzioni nascoste da un report all’altro. Non servono macro, codice VBA, vulnerabilità nella gestione della memoria o allegati eseguibili: l’attacco sfrutta il modo in cui Microsoft 365 Copilot interpreta il testo fornito come materiale di riferimento.

La tecnica è emersa da una ricerca a firma di Håkon Måløy pubblicata il 28 luglio 2026, dopo 144 giorni di coordinamento con il Microsoft Security Response Center (MSRC) e i team di prodotto Microsoft. Il ricercatore ha mostrato che un’istruzione inserita in un documento esterno può influenzare Copilot per Word, modificare silenziosamente il contenuto generato e disporre la copia automatica nel nuovo file. Quando qualcuno riutilizza quel file in una successiva sessione di Copilot, l’istruzione torna ad attivarsi: il documento appena creato diventa il nuovo veicolo dell’attacco.

Il meccanismo ricorda un worm informatico, ma con una differenza decisiva rispetto ai malware tradizionali: non replica byte eseguibili e non sfrutta direttamente il sistema operativo. A propagarsi è una sequenza testuale che il modello linguistico scambia per un comando attendibile.

Il problema è semmai ascrivibile alla famiglia indirect prompt injection, gli attacchi nei quali le istruzioni malevole non arrivano dal prompt digitato dall’utente, bensì da email, pagine web, documenti, risultati di ricerca o altre fonti elaborate dall’assistente.

Come il prompt malevolo entra nel documento Word

Il primo passaggio consiste nel preparare un file che sembri legittimo: per esempio un’analisi finanziaria, un documento condiviso da un fornitore o un rapporto scaricato da un sito compromesso. L’aggressore inserisce nel file una serie di istruzioni scritte in linguaggio naturale o rappresentate con una struttura simile a JSON.

I modelli linguistici sono interpreti molto tolleranti: riconoscono relazioni semantiche anche quando parentesi, campi e delimitatori non corrispondono a uno schema formale. Una sequenza che assomiglia a un comando interno può quindi acquistare autorità agli occhi del modello pur non rispettando alcuna sintassi documentata.

Per nascondere il payload al lettore, il proof of concept elaborato da Måløy usa testo bianco su sfondo bianco e un carattere molto piccolo. Un controllo visivo del documento non mostra nulla di anomalo. Copilot, invece, estrae il contenuto testuale rimuovendo elementi di formattazione come dimensione e colore del carattere; l’istruzione invisibile torna così perfettamente leggibile quando entra nella finestra di contesto del modello.

Nell’immagine (fonte: Håkon Måløy), il documento usato come vettore iniziale dell’attacco: una falsa analisi di mercato creata per mostrare il proof of concept. Il payload, in gran parte oscurato per motivi di sicurezza, è nascosto in fondo al file come testo bianco.

La seconda fase: il file generato diventa un nuovo vettore

L’attacco studiato da Måløy richiede che Copilot legga il documento malevolo durante un’attività di redazione o modifica. Ciò può accadere quando l’utente allega esplicitamente il file come fonte oppure quando una funzione collegata ai dati di lavoro lo recupera da OneDrive perché lo considera pertinente alla richiesta.

La parte più interessante della ricerca riguarda la replica: dopo la prima elaborazione, il documento originale dell’aggressore non serve più. Il rapporto interno creato con Copilot contiene già la stessa istruzione nascosta e assume il ruolo di “portatore”.

Si parla di AI worm documentale perché sebbene il file non sia in grado di “auto-spedirsi”, non apra connessioni di rete e non esegua codice sul computer, una volta letto il prompt, l’assistente copia il payload nel risultato e prepara il terreno per il passaggio seguente.

A complicare le cose il fatto che le aziende riutilizzano documenti fidati proprio per risparmiare tempo: un rapporto interno recente appare più affidabile di un allegato proveniente dall’esterno. Dopo il primo passaggio, l’origine malevola diventa difficile da ricostruire perché ogni nuovo file nasce da un account legittimo, dentro gli strumenti aziendali e attraverso un’operazione apparentemente autorizzata.

Il problema di fondo: dati e istruzioni finiscono nello stesso spazio

Per comprendere ancora più da vicino la problematica, bisogna distinguere due categorie che un’applicazione tradizionale separa con regole rigide. Da una parte ci sono le istruzioni dell’utente, per esempio “prepara un rapporto usando questi documenti“; dall’altra ci sono i dati contenuti nei documenti stessi. Copilot dovrebbe leggere i secondi senza attribuire loro la capacità di modificare il compito assegnato.

Un Large Language Model (LLM), tuttavia, elabora entrambe le categorie come token all’interno della stessa finestra di contesto. Messaggi di sistema, richiesta dell’utente, testo recuperato da OneDrive e contenuto degli allegati partecipano tutti all’elaborazione della risposta. L’applicazione può aggiungere etichette, delimitatori e istruzioni di priorità, ma il modello deve comunque interpretare semanticamente il materiale non fidato.

Måløy definisce questa perdita di separazione “context collapse“: informazioni provenienti da domini con livelli di fiducia diversi si appiattiscono nello spazio interpretativo del modello. Il contenuto controllato da un aggressore, pur essendo formalmente un dato, può assumere il significato operativo di un comando.

Da qui nasce una difficoltà che non ha un equivalente perfetto nel software classico. Un parser JSON può respingere un campo non previsto; un modello linguistico prova invece a ricostruire l’intenzione anche davanti a strutture incomplete, parafrasi, metafore, traduzioni o testi deliberatamente ambigui. Un filtro basato su parole chiave o espressioni regolari blocca una formulazione, ma lascia passare molte varianti semanticamente equivalenti.

Le mitigazioni che le aziende possono applicare subito

Al momento non risulta disponibile una correzione lato cliente capace di eliminare quest’intera e relativamente nuova classe di vulnerabilità. Ci sono però misure che riducono la superficie esposta. La prima consiste nel trattare ogni documento esterno come materiale non fidato, anche quando proviene da un partner conosciuto o da un sito apparentemente autorevole.

Prima di usare un file come sorgente per Copilot conviene ispezionarlo con attenzione. In Word si può selezionare l’intero contenuto e applicare temporaneamente un colore uniforme al testo; è utile anche controllare caratteri molto piccoli, paragrafi fuori dall’area visibile, oggetti, caselle di testo, intestazioni e piè di pagina.

Per analisi più approfondite, un file DOCX può essere aperto come archivio ZIP e verificato nei componenti XML, in particolare esaminando i file presenti sotto word/document.xml, word/header*.xml, word/footer*.xml e nelle relazioni associate.

Tale controllo non offre comunque una garanzia assoluta. Il payload non deve per forza essere invisibile: può confondersi con note tecniche, istruzioni redazionali, metadati testuali o frasi coerenti con il tema del documento. Concentrarsi soltanto sul testo bianco significherebbe prepararsi a riconoscere la dimostrazione, non l’intera categoria di attacchi.

Massima attenzione durante l’elaborazione di materiali provenienti dall’esterno

Le organizzazioni dovrebbero inoltre separare i flussi che elaborano materiale esterno da quelli che producono documenti critici. Per esempio, un file ricevuto da terzi può passare prima attraverso una fase di estrazione e revisione manuale; solo le informazioni confermate entrano nel documento di lavoro utilizzato da Copilot.

Servono poi revisioni sostanziali degli output: cifre, date, percentuali, nomi, clausole e conclusioni devono essere confrontati con le fonti originali. Nei processi ad alto impatto, l’approvazione di un secondo operatore resta necessaria. Affidare al medesimo assistente il compito di generare e controllare il testo rischia di riproporre la stessa influenza malevola durante entrambe le fasi.

Alla data di pubblicazione della ricerca, Microsoft aveva neutralizzato i payload segnalati inizialmente, ma non la vulnerabilità generale: Måløy è riuscito a riprodurre l’intera catena anche dopo due interventi, il secondo dei quali comprendeva l’aggiornamento del modello sottostante.

Conclusioni: Microsoft ha risolto il problema?

Microsoft ha corretto le specifiche formulazioni del prompt consegnate da Måløy e ha applicato più interventi durante i 144 giorni di cooperazione.

La prima mitigazione, introdotta il 3 aprile 2026 insieme alla nuova funzione “Edit with Copilot“, bloccava il payload originale; il ricercatore è però riuscito a riprodurre il comportamento il 9 aprile cambiando il compito assegnato e la formulazione delle istruzioni.

Un secondo intervento, applicato il 14 luglio e basato anche sull’aggiornamento del modello, ha alzato ulteriormente la barriera, ma non ha eliminato il meccanismo di fondo: il giorno successivo Måløy ha ottenuto nuovamente la manipolazione e la replica del prompt usando una variante dell’attacco.

Nei test eseguiti il 28 luglio 2026, tutte le mitigazioni disponibili risultavano attive e la catena completa restava comunque riproducibile. Non si può quindi certamente parlare di una soluzione definitiva.

Microsoft ha ridotto l’efficacia dei payload conosciuti e reso l’attacco meno immediato, ma non ha ancora separato in modo affidabile le istruzioni dell’utente dai comandi nascosti nei documenti elaborati dal modello. Lo stesso autore riconosce che non si tratta di una falla risolvibile con una singola patch: la debolezza riguarda l’architettura degli attuali sistemi basati su LLM ed è comune anche a prodotti concorrenti.

La conclusione di Måløy: ogni applicazione che introduce contenuti controllabili da terzi nella finestra di contesto deve assumere che una prompt injection possa avere successo con una certa frequenza. Rimangono quindi rischi concreti, soprattutto quando Copilot lavora su documenti esterni, cerca autonomamente file in OneDrive o produce materiali destinati a successive elaborazioni.