Chat di Notion AI esposte nella violazione di Fireworks AI — la supply chain AI è superficie d'attacco

I dati usciti da Notion questa settimana non sono mai stati su un server di Notion. Erano sull'infrastruttura di Fireworks AI, una piattaforma cloud che Notion usava per eseguire modelli open-weight per una sola funzione, e sono usciti attraverso un workload che nessuno in Notion aveva avviato. L'8 novembre Fireworks ha confermato che il dataset raggiunto dagli attaccanti includeva le trascrizioni delle chat di Notion AI. Notion ha comunicato l'esposizione e dal 9 novembre ha iniziato a contattare i clienti colpiti. È lo scenario che ogni azienda che collega un vendor AI di terze parti al proprio prodotto dovrebbe leggere con attenzione — non perché Notion abbia fatto qualcosa di anomalo, ma perché quasi tutti hanno la stessa dipendenza.

Notizia in evoluzione — pubblicata alle 15:27 (14:27 UTC) del 12 novembre 2026. Aggiornata man mano che Notion e Fireworks pubblicano.

Cosa è successo in Fireworks AI

Fireworks AI esegue e fa fine-tuning di modelli open source per altre aziende. È stata compromessa due volte a ottobre, e la seconda è quella che ha raggiunto i dati dei clienti.

Il primo incidente, comunicato il 9 ottobre, è stato un furto di credenziali: gli attaccanti hanno avuto accesso a segreti archiviati, tra cui variabili d'ambiente con chiavi API e token per un numero limitato di account, come riportato da BleepingComputer. Il secondo è peggiore. Il 23 ottobre un provider cloud di terze parti che ospitava le macchine di R&S di Fireworks è stato a sua volta violato. Entro il 24 ottobre l'attaccante aveva usato quell'accesso per raggiungere le macchine di sviluppo di Fireworks ed eseguire un workload non autorizzato — ed è quel workload ad aver estratto ulteriori dati dei clienti. Fireworks dice di aver rilevato l'attività lo stesso giorno e di non aver osservato ulteriori accessi riusciti alla piattaforma che i clienti usano davvero dopo il 25 ottobre.

Fireworks attribuisce l'attività a un gruppo con motivazioni economiche il cui business è il LLMjacking: rubare l'accesso ai large language model e rivendere la capacità di inferenza sottratta attraverso gateway di instradamento illeciti. Nelle sue parole, le evidenze "indicano collegamenti a un gruppo criminale... finalizzato a vendere token da accessi non autorizzati a Large Language Model". L'azienda ha coinvolto Palo Alto Networks Unit 42, avvisato le forze dell'ordine, revocato e sostituito credenziali e service account e disabilitato upload e download self-service dei dataset. Nei due incidenti i dati toccati comprendono metadati delle risorse, informazioni di fatturazione (Fireworks precisa che i numeri delle carte di pagamento non sono archiviati e non sono stati colpiti) e, per un numero limitato di account, segreti, dataset e pesi di modelli incompleti.

Chi è esposto — sei cliente Notion?

Se sei cliente Notion e Notion non ti ha contattato, la posizione dell'azienda è che il tuo workspace non è stato identificato come colpito e per ora non serve alcuna azione. Se invece sei stato contattato, prendila sul serio.

Il perimetro, nelle parole di Notion, è "meno dell'1% dei workspace Notion". Le trascrizioni esposte provenivano da Insights, una funzione che eseguiva job di classificazione attraverso Fireworks per aiutare i clienti a capire il proprio uso dell'AI. Notion ha disabilitato Insights e dichiara che nessun'altra funzione è stata coinvolta. Due dettagli attenuano il raggio d'azione, uno lo acuisce:

• Per la grande maggioranza dei workspace colpiti le trascrizioni erano non attribuibili — le chat non erano etichettate con chi le avesse scritte o da quale workspace provenissero, e non contenevano i risultati delle chiamate agli strumenti. Notion: "Oltre a ciò che è nella trascrizione stessa, non c'è alcuna informazione che ricolleghi la chat a workspace, utenti o aziende".
• Il dettaglio che taglia: le trascrizioni contengono comunque tutto ciò che gli utenti hanno digitato. L'11 novembre Notion ha trovato e revocato chiavi API Notion esposte dentro i messaggi degli utenti colpiti. Se qualcuno del tuo team ha incollato una password, un token o un segreto in una chat di Notion AI nella finestra dell'incidente, "non attribuibile" non ti aiuta — il segreto è il payload, e non ha bisogno di un nome attaccato.

Cronologia

Data	Cosa è successo
Inizio ottobre	Primo incidente Fireworks: accesso a segreti / chiavi API (comunicato il 9 ottobre)
23 ottobre	Violato il provider cloud di terze parti che ospitava le macchine di R&S di Fireworks
24 ottobre	L'attaccante raggiunge le macchine di sviluppo di Fireworks ed esegue un workload non autorizzato che estrae dati dei clienti; rilevato lo stesso giorno
2 novembre	Fireworks avvisa Notion che un dataset è stato raggiunto — ritenuto solo dati di test sintetici
3 novembre	Notion si disconnette da Fireworks, cancella i propri dati lì, interrompe le comunicazioni
6 novembre	Fireworks avverte Notion che i dati dei clienti potrebbero essere stati raggiunti
8 novembre	Fireworks conferma il dataset finale — include le trascrizioni delle chat di Insights
9 novembre	Notion inizia a notificare i clienti colpiti
11 novembre	Notion revoca le chiavi API Notion esposte trovate nei messaggi colpiti

I sei giorni tra "solo dati di test sintetici" (2 novembre) e "include le trascrizioni delle chat dei tuoi clienti" (8 novembre) sono la parte su cui vale la pena fermarsi. Notion ha fatto tutto correttamente dalla sua parte — ha chiuso la connessione e cancellato i dati in poche ore — e comunque non poteva sapere cosa fosse uscito finché il vendor non ha completato la propria forensics. Erediti la tempistica dell'indagine del tuo fornitore, che tu lo voglia o no.

Cosa ha davvero comprato la "zero data retention"

La FAQ di Notion segnala che Fireworks si era impegnata contrattualmente alla zero data retention per i dati di Notion. Le trascrizioni sono uscite lo stesso. Non è una contraddizione — è la lezione. Una clausola di zero retention regola ciò che un vendor dovrebbe conservare; non regola ciò che un attaccante già dentro l'ambiente di R&S del vendor può estrarre da un workload in esecuzione. I contratti ripartiscono la responsabilità a posteriori. Non tengono i byte dalla tua parte di un perimetro che non controlli.

"Abbiamo fatto tutto quello che un programma di sicurezza maturo prescrive per un sub-responsabile — DPA, clausola di zero retention, chiavi a privilegio minimo — e i dati sono usciti lo stesso. Cosa avremmo dovuto fare di più?"

Ridurre i dati che consegni, e guardare cosa esce dalla tua rete. Sono le due leve che ti restano dopo che il contratto è firmato.

Remediation

Qui non c'è una patch — è la violazione di una terza parte, non una falla software — ma c'è un runbook concreto, e vale per ogni vendor AI nel tuo stack.

1. Sono colpito? Notion sta notificando direttamente i workspace colpiti; se sei stato contattato, usa la revisione in-prodotto per recuperare e leggere le trascrizioni esposte (le istruzioni arrivano via email). Se usi Notion AI su un team, non aspettare che i singoli utenti si auto-segnalino — un owner del workspace può rivedere i dati colpiti in modo centralizzato.
2. Ruota tutto ciò che è mai stato digitato nell'AI. Tratta le trascrizioni come esposte. Ogni password, chiave API, access token o altra credenziale incollata in Notion AI nella finestra dell'incidente va ruotata nel sistema di origine, non solo cancellata dalla chat. Cancellare il messaggio non revoca il segreto.
3. Inventaria i tuoi sub-responsabili AI. Elenca ogni terza parte che tratta i tuoi prompt, documenti o dati dei modelli — provider di inferenza, gateway come LiteLLM, piattaforme di valutazione, console di agenti, host di fine-tuning. Ognuno è una copia dei tuoi dati fuori dal perimetro. Per ciascuno, registra quali dati vi affluiscono, quale retention è contrattualizzata e come verresti a sapere di una loro violazione.
4. Guarda l'egress. La telemetria che controlli è ciò che esce dalla tua rete. Stabilisci una baseline di volume e destinazioni normali del tuo traffico verso le API AI, così un'estrazione massiva anomala — o una destinazione nuova — ti sia visibile in poche ore, non in una notifica del vendor dopo settimane.
5. Riduci l'input. Il controllo più economico è il dato che non invii mai. Rimuovi segreti e dati regolati prima che raggiungano un modello esterno, e preferisci architetture in cui l'inferenza sensibile gira su infrastruttura tua.

Per le domande su deployment e contratto da porre a qualsiasi vendor AI, la nostra guida all'acquisto di piattaforme pentest on-premise funziona come checklist anche per i sub-responsabili, e l'analisi dell'ondata LLMjacking copre la serie più ampia di violazioni di piattaforme AI di ottobre in cui questa si colloca.

Cosa non si sa ancora

• Quanti clienti e workspace, in numeri assoluti. Notion dà una percentuale ("meno dell'1%"), non un conteggio, e non ha detto quanti altri clienti Fireworks siano stati colpiti.
• Chi è l'attaccante. Fireworks collega l'attività a un gruppo LLMjacking ma non ne nomina nessuno; nessuna delle due aziende la attribuisce a un threat actor noto.
• Cosa c'era nella minoranza attribuibile. La maggior parte delle trascrizioni è non attribuibile, ma Notion non ha descritto cosa contenesse il resto oltre alle chiavi API trovate e revocate.
• L'elenco completo dei clienti Fireworks colpiti. Notion è un cliente nominato; il bollettino parla di un più ampio "numero limitato di account" senza nominarli.

La domanda scomoda: dove vivono i tuoi dati AI?

Ogni dettaglio di questo incidente riconduce a una scelta architetturale: Notion ha inviato dati AI dei clienti a un modello in esecuzione sul computer di qualcun altro. È l'impostazione predefinita di quasi ogni azienda che oggi rilascia una funzione AI, ed è esattamente la dipendenza che questa violazione punisce. Il dato che non vedi uscire è il dato che non puoi proteggere.

Zero Hunt è costruito sulla premessa opposta. È un red team AI autonomo che gira on-premise, sui propri modelli privati — nessun prompt, risultato o credenziale viene inviato a un provider di inferenza esterno, perché nel circuito non c'è alcun provider di inferenza esterno. Lo scenario "l'ambiente di R&S del nostro vendor è stato violato e i tuoi dati erano lì dentro" non può verificarsi quando il modello è un'appliance da 27B a 284B nel tuo rack, e nessuna terza parte può spegnere la capacità, rallentarla o modificarla di nascosto. Per l'inventario dell'esposizione, lo swarm di 10 agenti del motore mappa la tua superficie d'attacco reale come farebbe un attaccante — black box, dall'esterno — facendo emergere le integrazioni e i flussi di dati che una lista di asset da brochure non vede, e provando quali sono davvero raggiungibili invece che teoricamente rischiosi.

Il corollario di rilevamento è il lato traffico di Zero Hunt. Questa violazione è emersa settimane dopo l'uscita dei dati, attraverso la notifica di un vendor — la classica esfiltrazione a scoperta lenta. Sulla tua rete, un modello di deep learning con quattro teste di inferenza, in esecuzione sulla GPU dell'appliance, stabilisce la baseline del tuo egress normale verso le API AI così che un trasferimento massivo anomalo o una destinazione mai vista venga colto mentre accade, non nell'audit del trimestre successivo. Il contratto con i tuoi fornitori resta tuo. Dovresti possedere anche le due cose che un contratto non può darti: meno dati che escono, e occhi su ciò che esce. Se è questo il divario che stai chiudendo, raccontaci com'è fatto il tuo stack AI.