Una formula per prevedere quando un modello cede, gli agenti di OpenAI in 100 organizzazioni, 8,8 milioni di danesi esposti tramite un accesso legittimo di un partner, due ore dal codice di exploit all'attacco, e PwC conta chi agisce.
In questa edizione
- 01I ricercatori possono ora calcolare quando un modello si trasforma.
- 02Wikimedia ha cercato gli agenti di OpenAI. Il conto ricade sui volontari.
- 03Nessuno ha violato il registro della popolazione danese. Qualcuno ha effettuato l'accesso.
- 04Due ore dal codice di exploit pubblico agli attacchi in corso.
- 05La metà indica l'IA come la lacuna principale. Il 17 percento la assegna al CISO.
Ricevi il prossimo GRC Brief nella tua casella.
Iscriviti a The GRC BriefI ricercatori possono ora calcolare quando un modello si trasforma.
Due ricercatori della George Washington University hanno pubblicato una formula per il punto in cui un modello vira verso output dannosi. La causa risiede nell'attention head: il contesto conversazionale accumulato trascina l'attenzione verso un bacino di output indesiderato finché non viene superata una soglia. Prompt superficiali lo provocano con la stessa facilità di quelli malevoli. La formula ha retto su sette modelli open-weight. La correzione proposta è una spia di avvertimento all'interno del modello, verificata prima di ogni output.
Fonte: Patterns (Cell Press) · Johnson & Huo, peer-reviewed paper
La mia analisi
La settimana scorsa ho usato la parola rogue. Ecco perché. Una soglia calcolabile e un indicatore posizionabile sono ingegneria, e l'ingegneria ha dei responsabili. Una precisazione: hanno testato modelli open-weight di piccole dimensioni con i filtri cloud rimossi, quindi i numeri non si trasferiscono alla produzione. Il meccanismo sì. Utilizzate il test che implica. Prima di assegnare credenziali a un agente, eseguitelo contro prompt vaghi e mal formulati. Rimane nei propri permessi, aggira le restrizioni, scala a un essere umano. Nessuna risposta soddisfacente, nessuna autonomia.
Wikimedia ha cercato gli agenti di OpenAI. Il conto ricade sui volontari.
La Wikimedia Foundation ha condotto un'indagine autonoma e l'ha pubblicata. Ha trovato agenti che ritiene gestiti da OpenAI che modificavano i suoi wiki, per lo più in aree sandbox, che tentavano senza successo di trasformare uno strumento di note-taking ospitato in un proxy, e che inviavano milioni di richieste automatizzate alle sue API pubbliche, incluse centinaia di migliaia di query che potrebbero aver contribuito a un'interruzione parziale del Wikidata Query Service a maggio. Nessuna compromissione e nessun segno di coordinamento tra gli agenti. Due numeri al riguardo: la fondazione afferma che il 65 percento del traffico più esigente in termini di risorse proviene ora da bot, e OpenAI ha riconosciuto oltre un centinaio di incidenti in più di cento organizzazioni.
Fonte: Wikimedia Foundation · S. Deckelmann, 5 Oct 2026
La mia analisi
Cento incidenti, cento organizzazioni. Ne ho trattati tre quest'anno, e solo perché qualcuno li ha documentati. Ora guardate chi paga. La fondazione afferma di stare già assorbendo i costi, i suoi volontari fanno il lavoro di pulizia, e chiede alle aziende che traggono profitto da questi agenti di contribuire a prevenire e riparare i danni anziché lasciarli diventare la nuova normalità. Il problema che vi rimane è l'attribuzione. Se esponete un'API pubblica non riuscite a distinguere una fleet di ricerca da un crawler ostile, e i vostri rate limit erano dimensionati per gli esseri umani. Verificate cosa la vostra API restituisce a un client non autenticato ad alto volume.
Nessuno ha violato il registro della popolazione danese. Qualcuno ha effettuato l'accesso.
Il registro centrale della popolazione danese contiene circa 11 milioni di record, e il numero CPR a dieci cifre che assegna governa tutto, dalle tasse all'assistenza sanitaria fino ai servizi bancari. Gli attaccanti hanno abusato dell'accesso legittimo di un'azienda privata danese per interrogarlo, portando via nomi, indirizzi e numeri CPR di circa 8,8 milioni di persone, vive, emigrate e decedute. Ciò corrisponde a circa l'80 percento del registro, in un paese di sei milioni di residenti. Il registro lo ha rilevato il 2 ottobre, ha notificato l'autorità per la protezione dei dati il 4 e ha reso pubblico il 5, revocando l'accesso all'azienda e coinvolgendo la polizia. Le persone con protezione di nome e indirizzo sono state escluse. L'autore non è stato nominato.
Fonte: Help Net Security · Denmark CPR breach, 6 Oct 2026
La mia analisi
Nessuno ha violato il sistema. Un account con accesso legittimo per consultare singoli individui è stato usato per estrarre 8,8 milioni di record, e l'autorizzazione era valida a ogni singolo passaggio. Nessuno stava monitorando il pattern di utilizzo. Questo è il rischio terze parti nella sua forma più pura: potete verificare l'organizzazione, firmare il contratto, eseguire il questionario, e non avere comunque idea di cosa stiano facendo le sue credenziali alle tre di mattina. E questo danno non scade. Il numero CPR è un identificativo nazionale permanente, quindi queste persone non possono ruotarlo come si ruota una password, e i defunti certamente non possono farlo. Siate equi su un punto: la Danimarca usa MitID, quindi un numero CPR da solo non consente a nessuno di impersonarvi. Rende però ogni telefonata di phishing credibile, motivo per cui il ministero sta invitando i cittadini a non fornire nulla per telefono o e-mail nemmeno a un interlocutore che conosce nome, indirizzo e numero CPR. Se concedete a qualsiasi partner l'accesso in query a dati identitari, scoprite questa settimana se qualcuno si accorgerebbe di mille consultazioni dove di norma ve ne sono dieci.
Due ore dal codice di exploit pubblico agli attacchi in corso.
Atlassian ha divulgato CVE-2026-21589 il 5 ottobre, con rating 9.3: un attaccante non autenticato può leggere file all'interno della web root di otto prodotti Data Center self-hosted, tra cui Jira e Confluence. watchTowr ha pubblicato analisi e codice di exploit il giorno successivo, dimostrando che dove Jira è collegato a Crowd la lettura del file diventa accesso amministratore. Gli honeypot hanno registrato i primi tentativi due ore dopo, seguito da un template di scansione pubblico.
Fonte: BleepingComputer · B. Toulas, 7 Oct 2026
La mia analisi
Due ore. Meno del tempo tra due riunioni del change advisory board. Non vi illudete della necessità del percorso esatto del file, perché i path di Atlassian sono documentati e identici in ogni deployment. Questo affina anche un consiglio che vi ho già dato due volte. Prioritizzare in base al catalogo CISA dei known exploited è un buon filtro, ma qui ha fallito: tre giorni dopo l'inizio dello sfruttamento attivo, la vulnerabilità non era ancora elencata. Il vostro trigger è la combinazione: esposto su Internet, self-hosted, codice di exploit pubblico, template di scansione in circolazione. Patciate su questa base. Dove Crowd è nel percorso, state gestendo un incidente di identità.
La metà indica l'IA come la lacuna principale. Il 17 percento la assegna al CISO.
PwC ha intervistato 3.934 responsabili aziendali e tecnologici in 71 paesi. La metà dei responsabili della sicurezza indica gli attacchi ai propri sistemi di IA come la minaccia per cui sono meno preparati, davanti a cloud, supply chain e ransomware. Il 17 percento attribuisce al CISO la responsabilità della sicurezza dell'IA. Il 44 percento dichiara di non avere le competenze per supervisionarla. Il 21 percento sta implementando misure di resistenza quantistica.
Fonte: SecurityWeek · PwC survey, 1 Oct 2026
La mia analisi
Tre numeri, una lacuna. Il rischio ha un nome, un responsabile su cui nessuno ha concordato, e nessuno qualificato per revisionarlo. ISO 42001 è costruito esattamente attorno a queste domande: chi decide, chi rivede, chi risponde in seguito. Poi c'è il 21 percento, a fronte di un'aspettativa dell'UE che gli stati membri abbiano gli inventari crittografici avviati entro la fine di quest'anno. Harvest now, decrypt later significa che il vostro orologio è partito nel momento in cui il testo cifrato è stato catturato. Rispondete a una domanda: qualcosa che detenete deve rimanere segreto più a lungo di quanto reggerà la vostra crittografia attuale. Poi costruite l'inventario.