Cinquantatré immagini caricate dagli utenti di ChatGPT sono finite su siti pubblici di image hosting, pubblicate da agenti AI che giravano nell’ambiente di ricerca di OpenAI. Lo ha ammesso la stessa OpenAI, come riporta il 25 settembre TechCrunch. Nessuno di quegli utenti ha sbagliato qualcosa: ha usato un servizio come previsto.

È il filo delle notizie di questa settimana. In quattro casi diversi il danno non nasce da un errore di chi subisce, ma da un fornitore che sta un livello sotto: il laboratorio AI, la rete pubblicitaria, la primitiva crittografica, le impostazioni predefinite di un database. Per una PMI con WordPress, API AI e servizi cloud sono livelli che di solito nessuno controlla.

OpenAI: i dati di training usciti dal laboratorio

Le immagini erano state incluse nei dati di addestramento. Gli agenti le hanno pubblicate come link non elencati, che però restano raggiungibili da chiunque trovi l’indirizzo. OpenAI dice di lavorare con i servizi di hosting per rimuoverle, ma parte del materiale risulta ancora online. E non può avvisare le persone coinvolte: il suo metodo di trattamento, spiega, non permette di ricollegare le immagini a chi le ha caricate.

È l’ultimo capitolo della serie di incidenti degli agenti OpenAI che comprende l’intrusione in Hugging Face, di cui avevo parlato in incidenti degli agenti AI: log ed escalation.

Il dettaglio che conta per chi lavora: secondo TechCrunch, gli account enterprise sono esclusi di default dall’uso delle conversazioni per il training, quelli consumer no. E anche chi ha disattivato l’opzione rimette nel training la conversazione se clicca pollice su o pollice giù. Se il tuo collaboratore carica la foto di un documento cliente dal suo account personale, quel file segue le regole del piano consumer.

Google Ads: la truffa passa dai siti legittimi

Tra il 31 agosto e il 14 settembre 2026 Netskope ha visto utenti di 619 organizzazioni cliccare annunci Google che portavano a una finta schermata di blocco, con falsi avvisi di Microsoft Defender su Windows e di Apple su macOS e un numero da chiamare. Oltre 250 campagne, almeno 284 siti editoriali legittimi: meteo, mappe, immobiliare, sport, come ricostruisce Ars Technica.

Il kit aspetta un movimento del mouse prima di mostrare la trappola, così gli scanner automatici che analizzano la pagina senza muovere il cursore vedono solo un negozio finto innocuo. Il gestore del sito che ospita l’annuncio non vede niente, e il visitatore dà la colpa al sito.

RSA: la chiave resta dentro, la firma no

Un articolo pubblicato sull’archivio della IACR, «Forging 1024-bit RSA signatures in nearly SNFS time», ha messo in pratica un algoritmo del 2007 di Joux, Naccache e Thomé. Con accesso temporaneo a un oracolo di firma RSA “grezzo”, un attaccante può falsificare firme senza mai estrarre la chiave. Il test su RSA a 1024 bit ha richiesto 1380 anni-core di CPU in cinque mesi e 232 richieste all’oracolo, che nell’esperimento era un HSM, cioè il modulo hardware pensato proprio per custodire la chiave.

Gli autori stimano una sicurezza reale da 15 a 30 bit sotto le stime classiche, e scrivono che in questo modello nemmeno RSA a 4096 bit raggiunge il livello a 128 bit. Tom’s Hardware cita come servizi basati su RSA raw o blind Cloudflare Privacy Pass, iCloud Private Relay e Private Cloud Compute. Va letto per quello che è: una falsificazione di firme in condizioni precise, non la decifratura del traffico HTTPS del tuo sito.

Supabase: il default che espone

Il quarto caso l’ho trattato oggi pomeriggio. TechCrunch ha contato 16.326 database Supabase con tabelle leggibili dall’esterno: nessuno ha bucato Supabase, erano tabelle senza Row Level Security. Il confronto tra le due architetture sta in Supabase: RLS o API sul server.

La mia lettura: fai l’inventario dei livelli che non vedi

La sicurezza di una PMI oggi si gioca meno sul firewall e più sull’elenco dei fornitori a cui affida dati, visitatori e firme. Nessuno di questi problemi si risolve con un plugin di sicurezza, perché nessuno passa da WordPress.

Cosa farei lunedì:

  • Dati dei clienti solo su account business. Niente documenti di clienti su account AI personali. Sul piano aziendale verifica che l’uso per il training sia disattivato e spiega al team che anche il feedback col pollice conta. Il perimetro di chi legge i prompt l’ho descritto in chi legge davvero i tuoi dati.
  • Annunci sul sito aziendale: decidi se ti servono. Un sito B2B che mostra annunci di rete espone i propri clienti a truffe come questa. Se restano, blocca le categorie a rischio dalla console dell’ad network e controlla le pagine da un browser vero, con il mouse.
  • Chiedi ai fornitori quali firme usano. Per il TLS del sito il problema non è immediato, ma è un argomento in più per le curve ellittiche e per la transizione post-quantum, che per un sito WordPress ho descritto in TLS post-quantum su WordPress.
  • Controlla le impostazioni predefinite di ogni backend esposto: database, bucket, form. Il default comodo è quello che finisce nelle notizie.

In sintesi: chi ha perso dati o ha visto la truffa questa settimana non ha commesso errori. Il rischio stava in un fornitore, o nel default di un fornitore, che nessuno guardava. L’unica difesa che hai è sapere chi sono e cosa fanno con quello che gli passi.

Fonti