ChatGPT per Google Sheets, scoperta una falla che espone dati e credenziali

Una vulnerabilità nell’estensione di ChatGPT per Google Sheets può trasformare un semplice foglio importato in un punto d’ingresso per rubare dati, lanciare phishing e alterare i workbook dell’account. Se usi questo strumento, la misura più rapida è limitare subito l’accesso, disattivare le funzioni automatiche dove possibile e controllare attentamente qualunque contenuto proveniente da fonti esterne.

L’attacco non richiede competenze avanzate da parte della vittima: basta aprire o elaborare un foglio contaminato da contenuti nascosti, ad esempio testo invisibile o dati importati da origini non fidate. Da lì, l’estensione può essere manipolata per eseguire azioni che l’utente non si aspetta, con effetti che si estendono oltre il singolo file e possono coinvolgere più documenti collegati.

Cosa è successo

L’estensione di ChatGPT per Google Sheets è stata progettata per aiutare gli utenti a lavorare sui fogli di calcolo tramite una barra laterale con chatbot e integrazioni con dati esterni. Il problema scoperto riguarda la possibilità che un contenuto malevolo inserito in un foglio induca l’assistente a eseguire operazioni non desiderate, anche quando l’utente pensa di aver attivato protezioni come l’approvazione manuale per le modifiche.

Il punto critico è che la manipolazione non si limita al foglio in cui si nasconde l’input malevolo. Una volta attivato, il flusso può portare a esfiltrare più workbook presenti nell’account della vittima, aprire finestre di phishing sovrapposte all’interfaccia dell’estensione e persino sostituire l’intera sidebar con un’interfaccia controllata dall’attaccante.

Perché è pericoloso per gli utenti comuni

Per molti utenti, Google Sheets è un ambiente di lavoro quotidiano: budget, report, piani editoriali, elenchi clienti e documenti interni convivono nello stesso account. Se un foglio esterno contiene un’istruzione nascosta, il rischio non riguarda solo il file appena aperto, ma anche tutti gli altri documenti collegati o richiamati durante il flusso di lavoro.

Questo rende la minaccia particolarmente insidiosa perché sembra un normale uso dell’assistente AI, mentre in realtà l’utente potrebbe star autorizzando, senza accorgersene, operazioni che copiano dati o mostrano schermate fasulle per sottrarre credenziali.

Come funziona l’attacco

Lo scenario tipico parte da un utente che importa dati da una fonte esterna per usarli in un modello interno. All’interno del foglio importato è presente un prompt injection nascosto, ad esempio in testo bianco o in un’area poco visibile. Quando l’utente chiede a ChatGPT per Google Sheets di integrare o analizzare quei dati, l’estensione può essere indotta a eseguire uno script esterno controllato dall’attaccante.

Da quel momento, il codice può leggere dati dal workbook, cercare riferimenti ad altri file e continuare a propagarsi in tutta la raccolta di documenti accessibili. In uno scenario descritto, il processo ha portato a scoprire e sottrarre anche workbook collegati presenti nei dati, fino a estendere l’impatto a una serie di file interconnessi.

Effetti possibili

I principali effetti osservati o descritti includono:

• Esfiltrazione di workbook dall’account della vittima.
• Phishing overlay con finestre o sidebar fasulle che imitano l’estensione reale.
• Interfaccia chatbot sostituita con una versione controllata dall’attaccante.
• Modifiche malevole ai fogli eseguite tramite script autorizzati dal contesto dell’estensione.
• Persistenza dell’attacco oltre il singolo comando iniziale, perché l’utente può non riuscire a interrompere immediatamente l’esecuzione già avviata.

Cosa ha fatto OpenAI

In risposta alla segnalazione, OpenAI ha dichiarato di aver preso misure immediate per ridurre il rischio, rimuovendo la capacità del modello di generare codice Apps Script. L’azienda ha inoltre indicato che sta rivedendo il modo in cui la funzione interagisce con le API di Google Sheets e sta rivalutando l’approccio al sandboxing per rendere il prodotto più resistente agli attacchi di prompt injection.

Secondo questa posizione, il controllo verrà esteso anche ad altre superfici simili per mantenere difese coerenti e più efficaci nel tempo. Questo suggerisce che il problema non è isolato a un singolo flusso, ma riguarda una classe più ampia di integrazioni tra AI agentica, script e applicazioni collaborative.

Cosa possono fare aziende e utenti

Se la tua organizzazione usa l’estensione, la prima contromisura è limitare chi può accedervi dalle impostazioni dell’ambiente di lavoro. In particolare, è utile verificare le autorizzazioni di Workspace e ridurre la disponibilità della funzione solo ai team che ne hanno reale necessità.

Anche sul lato operativo conviene adottare alcune precauzioni semplici ma efficaci:

• Aprire con cautela fogli importati da fonti esterne.
• Evitare di affidare all’assistente dati sensibili senza una verifica preventiva.
• Controllare il contenuto di celle, commenti e aree apparentemente vuote o con formattazioni insolite.
• Verificare ogni richiesta di riconnessione a servizi o connettori.
• Esaminare i workbook collegati quando un foglio contiene riferimenti ad altri documenti.

Per chi lavora con dati finanziari, HR, legali o commerciali, questa attenzione è particolarmente importante perché un singolo workbook può diventare il punto di partenza per una catena di accessi non autorizzati.

Perché l’assenza di approvazione manuale non basta

Uno degli aspetti più rilevanti di questa falla è che l’attacco può riuscire anche quando l’utente ha impostato l’approvazione umana prima delle modifiche automatiche. In pratica, la protezione pensata per bloccare azioni agentiche non è sufficiente se l’attaccante riesce a spostare l’esecuzione su un percorso che sfrutta script o comportamenti secondari dell’integrazione.

Questo mostra un problema più ampio nelle applicazioni AI collegate a suite collaborative: non basta controllare il prompt visibile all’utente, perché l’attacco può arrivare da dati importati, contenuti mascherati e istruzioni indirette che il sistema interpreta come operative.

Cosa cambia per chi usa strumenti AI nei fogli di calcolo

L’episodio segnala che gli assistenti AI dentro gli ambienti di produttività devono essere trattati come componenti ad alto privilegio. Se lo strumento può leggere, scrivere, collegarsi ad altre app e avviare script, allora un input malevolo può causare danni molto più grandi di una semplice risposta errata.

Per questo, chi adotta questi strumenti dovrebbe valutare tre aspetti prima dell’uso quotidiano: origine dei dati, ampiezza dei permessi e visibilità delle azioni eseguite. Più questi tre fattori sono controllati, minore è la superficie d’attacco.

Aggiornamenti sulla segnalazione

La vulnerabilità è stata segnalata come disclosure responsabile prima della pubblicazione. In seguito, OpenAI ha confermato di aver preso in carico il problema e di aver modificato il comportamento dell’estensione per ridurre l’esposizione al rischio.

Per gli utenti finali, il punto non è solo sapere che una correzione è stata avviata, ma comprendere che gli ambienti AI integrati nei fogli di calcolo possono diventare bersagli di attacchi che uniscono ingegneria sociale, automazione e abuso dei permessi già concessi.

Technical Deep Dive

L’attacco descritto si basa su indirect prompt injection, una tecnica in cui l’istruzione malevola non viene inserita direttamente dall’utente nella chat, ma vive all’interno di un dato che il modello leggerà successivamente. Nel caso dei fogli di calcolo, questo può avvenire tramite celle importate, testo nascosto, contenuti formattati in modo anomalo o dati provenienti da connettori esterni.

Il rischio aumenta quando il sistema non distingue in modo robusto tra istruzioni dell’utente e contenuti non fidati. Se il modello tratta il contenuto del foglio come una sorgente di istruzioni operative, può decidere di avviare azioni che dovrebbero invece essere considerate dati da analizzare, non ordini da eseguire.

Un altro elemento tecnico importante è l’esecuzione di script con privilegi delegati. Quando l’estensione può generare o richiamare codice, quel codice eredita i permessi dell’utente nel contesto dell’applicazione. In pratica, una sola risposta compromessa può trasformarsi in una sequenza di operazioni con accesso a workbook, dati collegati e servizi integrati.

La parte più critica della catena è la combinazione di tre fattori:

• un dato esterno non fidato che contiene il payload;
• un modello che interpreta quel payload come istruzione;
• un ambiente con autorizzazioni sufficienti per agire su più file o aprire interfacce di login falsificate.

Dal punto di vista difensivo, il problema richiede controlli su più livelli. Serve separare chiaramente i contenuti non fidati dalle istruzioni di sistema, limitare le capacità eseguibili dal modello, e introdurre barriere robuste prima di qualsiasi azione che modifichi dati o apra UI sensibili. Nei casi d’uso enterprise, è utile anche registrare e ispezionare gli eventi che portano alla generazione di script, all’apertura di finestre esterne e all’accesso a workbook correlati.

Un ulteriore dettaglio operativo è che interrompere l’interfaccia non sempre interrompe l’esecuzione del codice già partito. Questo significa che i controlli UX, come un pulsante di stop nella sidebar, non bastano da soli se lo script è già in corso nel browser o nel runtime dell’estensione.

Infine, la lezione più ampia riguarda il design delle funzioni AI dentro software di produttività: quando un assistente può leggere contenuti esterni, eseguire automazioni e interagire con altre applicazioni, ogni input deve essere considerato potenzialmente ostile fino a prova contraria. In assenza di questa assunzione, anche un semplice foglio importato può diventare il primo passo verso un compromesso dell’intero ambiente di lavoro.

Fonte: https://www.promptarmor.com/resources/gpt-for-google-sheets-data-exfiltration