Migliaia di modifiche a una wiki tedesca di programmazione, usata da agenti riconducibili a OpenAI come bacheca per scambiarsi risposte ai propri compiti e tecniche di elusione dei controlli. L’episodio è emerso il 4 settembre da un’esclusiva Reuters e dal rapporto pubblico di un gruppo di ricercatori indipendenti; il giorno dopo OpenAI lo ha riconosciuto, ammettendo di non avere uno standard per divulgare casi del genere. Il punto interessante per chi si occupa di compliance non è che qualcuno abbia violato l’AI Act: è che quasi certamente nessuno lo ha violato.

Che cosa è successo su DseWiki

Tra la fine di maggio e i primi di luglio 2026, agenti autonomi che si presentavano come agenti OpenAI hanno effettuato migliaia di modifiche su DseWiki, una wiki di programmazione in lingua tedesca attiva da circa venticinque anni e ormai quasi in disuso: nel decennio precedente aveva registrato in tutto una ventina di modifiche. Reuters parla di oltre 15.000 interventi; il rapporto dei ricercatori che hanno scoperto il caso conta circa 17.000 modifiche sulla sola DseWiki e circa 18.000 post complessivi su più wiki, con oltre 3.700 nomi di agente distinti.

Non si è trattato di scrittura casuale o di scraping. Secondo la ricostruzione dei ricercatori, gli agenti stavano eseguendo un compito interno a OpenAI (addestramento o valutazione, non è chiaro) di ricerca di informazioni sul web a tempo: potevano leggere internet ma non scrivervi, perché il sandbox consentiva solo richieste GET. DseWiki, come altre wiki derivate dal software UseModWiki, accetta modifiche anche tramite richieste GET. Gli agenti hanno individuato questa caratteristica dopo giorni di tentativi su altri siti (i primi test risalgono all’11 maggio) e il 24 maggio hanno fatto la prima scrittura riuscita su DseWiki.

Da lì il sito è diventato una bacheca. Gli agenti vi hanno depositato liste di link e dati grezzi, hanno condiviso le risposte ai quesiti che il compito poneva loro in sequenza (chi era più avanti postava la risposta, chi era indietro la copiava in pochi secondi), hanno tentato di ricostruire il seme del generatore casuale che decideva l’ordine delle domande, hanno installato “battiti cardiaci” su servizi esterni per capire quando il loro container sarebbe stato terminato, e si sono scambiati un metodo funzionante per aggirare la restrizione alle sole richieste GET sfruttando un’eccezione del proxy di sicurezza per gli host di Azure Blob Storage. Il 16 giugno l’attività è esplosa: circa 13.000 modifiche nei sette giorni successivi.

Alcuni elementi meritano di essere riportati per esteso, perché è nel dettaglio che si capisce la natura del fenomeno.

Circa metà dei nomi utente richiamava direttamente il fornitore, con account del tipo “OpenAIResearcher” e “OAIResearchMar26”. I log pubblici del server, analizzati dai ricercatori, attribuiscono il 98,5% delle modifiche a indirizzi IP di Microsoft Azure, una delle infrastrutture su cui OpenAI addestra e serve i propri modelli. Un moderatore umano si è accorto dello spam già il 2 giugno, quando ha trovato il registro delle modifiche del sito sommerso da elenchi di link, e da metà giugno ha cancellato a mano le pagine generate dagli agenti, dedicando alla pulizia almeno qualche minuto ogni sera per sei settimane, decine di ore in tutto. Il 19 giugno gli agenti hanno notato che la cancellazione procedeva in ordine alfabetico e hanno cominciato sistematicamente a creare pagine di riserva con nomi che iniziano per “ZZZ”, in modo da essere cancellate per ultime. Il messaggio lasciato per gli altri agenti avvertiva che era in corso una pulizia alfabetica e indicava dove ripiegare se quella pagina fosse sparita. Nei cinque giorni successivi il moderatore ha cancellato in media cento pagine al giorno; gli agenti ne creavano circa quattrocento.

C’è poi la parte che riguarda direttamente OpenAI. Dal 21 giugno la wiki riceve visite da indirizzi IP registrati a “OpenAI OpCo, LLC” e da altri con schemi di navigazione umani. Il 22 giugno le modifiche degli agenti crollano quasi a zero, dopo 26 giorni di attività su 30. Il 26 giugno 33 indirizzi riconducibili a OpenAI fanno da soli il 30% di tutto il traffico che i ricercatori attribuiscono all’azienda, e usano la funzione di archivio del sito per recuperare pagine già cancellate. L’inferenza dei ricercatori, che OpenAI non ha né confermato né smentito, è che l’azienda abbia scoperto la bacheca e sia intervenuta. Un’ultima raffica su un tema nuovo compare l’1 e il 2 luglio, con 29 tentativi di modifica il 2 luglio distribuiti su tre wiki; poi più nulla.

Quello che è rimasto ignoto fino a fine agosto, dunque, non è l’attività in sé, che il moderatore vedeva ogni sera e che OpenAI, secondo i log, ha osservato da fine giugno: è l’attribuzione, la natura del fenomeno e la sua esistenza per chiunque fosse fuori da quelle due stanze. A ricostruirlo è stato un gruppo di quattro ricercatori indipendenti (Sydney Von Arx, a capo dell’organizzazione non profit di AI safety Nightingale Collective; Cormac Slade Byrd, trader quantitativo passato alla ricerca sull’intelligenza artificiale; Spencer Kitts, di Redwood Research, che ha lavorato al rapporto come collaboratore di Nightingale; Thomas Larsen, dell’AI Futures Project) che dopo il caso Hugging Face stavano cercando sul web tracce di agenti fuori controllo. La vicenda è stata resa pubblica il 4 settembre 2026 da un’esclusiva Reuters firmata da Deepa Seetharaman e Raphael Satter, in contemporanea con la pubblicazione del rapporto e del dataset (quasi completo: alcune pagine cancellate non sono state recuperabili).

Le reazioni, e la parte che non torna

OpenAI ha dichiarato di non poter rispondere nel merito a un rapporto che non aveva avuto modo di esaminare, precisando che Reuters e gli autori avevano rifiutato di darle accesso prima della pubblicazione. Secondo Reuters, che cita quattro persone informate, alcuni investigatori interni avrebbero voluto approfondire questo tipo di attività, incontrando resistenze in azienda, anche da parte dei consulenti legali; OpenAI ha definito false le affermazioni secondo cui il proprio ufficio legale avrebbe scoraggiato l’indagine. L’azienda ha inoltre sostenuto che la vicenda tedesca non è collegata alla violazione di Hugging Face di luglio e che per questo non era stata inclusa nel relativo rapporto. Sempre secondo Reuters, che qui si basa su due fonti, dirigenti della società erano a conoscenza dell’episodio da settimane. Su questo punto i log pubblici della wiki, con le visite da IP OpenAI dal 21 giugno, offrono un riscontro indipendente, anche se non dicono chi, dentro l’azienda, sapesse cosa.

Il giorno dopo la posizione è cambiata. Il 5 settembre OpenAI ha pubblicato una dichiarazione su X in cui parla apertamente del “wiki incident”, descrivendolo come un episodio in cui i propri agenti “hanno scritto su diversi siti internet”, una formulazione che chiude la questione dell’attribuzione e suggerisce un perimetro più ampio della sola DseWiki. L’azienda spiega di aver trattato il caso come misalignment, cioè come un problema di ricerca da comunicare attraverso paper e system card, e non come un incidente di sicurezza da divulgare, a differenza di Hugging Face, dove erano stati toccati sistemi di terzi. Riconosce però che quest’anno il disallineamento ha cominciato a produrre effetti nel mondo reale, che il settore non ha uno standard chiaro su quando e come segnalare comportamenti anomali emersi in addestramento, valutazione o produzione, soprattutto quando non somigliano a una violazione informatica classica, e annuncia un proprio quadro di divulgazione nelle prossime settimane, dicendo di essere in contatto con decine di autorità di regolazione. A Reuters, che le ha chiesto cosa sapesse dell’episodio e perché abbia aspettato la pubblicazione dell’inchiesta per parlarne, non ha risposto.

I ricercatori hanno anche documentato tentativi di manomettere il sito: sondaggi per vulnerabilità XSS sulla pagina di ricerca tra il 24 e il 26 maggio e su altri punti di ingresso il 18 giugno, nessuno dei quali risulta riuscito; l’uso del nome di un amministratore della piattaforma con un carattere cirillico al posto di uno latino, per modificare le pagine principali; richieste all’archivio delle pagine cancellate firmate con il nome di un moderatore; la cancellazione del contenuto della home page, ripristinata dal moderatore nove volte. Lukasz Olejnik, visiting senior research fellow al King’s College London, ha qualificato il tutto come un tentativo di intrusione informatica. OpenAI, riferisce Reuters, ha contestato questa qualificazione sulla base della propria analisi del materiale. Maurice Chiodo, del Centre for the Study of Existential Risk dell’Università di Cambridge, che ha esaminato parte delle comunicazioni, le ha descritte come qualcosa che somiglia al funzionamento di una rete clandestina orientata a portare a termine una missione, e ha indicato negli sciami di intelligenze artificiali semi-intelligenti che colludono tra loro il rischio a suo avviso più serio.

Vale la pena tenere ferme due distinzioni che nella copertura generalista si perdono.

La prima: che gli agenti “si parlassero” non implica intenzionalità nel senso umano del termine. Sistemi che ottimizzano il completamento di un compito possono convergere su una strategia condivisa senza che vi sia nulla di simile a un piano. OpenAI stessa, nel rapporto tecnico sul caso Hugging Face del 26 agosto, ha scritto che alcuni suoi modelli avevano imparato in addestramento, in rari casi, a usare canali di collaborazione improvvisati anche quando lo strumento di collaborazione non era attivo, e che questo comportamento era stato poi rinforzato.

La seconda: Reuters descrive gli agenti intenti a “mascherare il proprio comportamento” ed eludere il rilevamento. Il rapporto primario è più cauto. Le pagine “ZZZ” servivano a sopravvivere alla pulizia del moderatore, non a sfuggire a OpenAI; sull’uso di Tor (che insieme a indirizzi AWS e DigitalOcean copre 197 modifiche su circa diciottomila) i ricercatori scrivono di non sapere perché sia avvenuto e che i messaggi non implicano alcuna volontà di occultamento. Lo scopo documentato è più prosaico e per certi versi più inquietante: barare sul compito assegnato e aggirare le restrizioni del proprio ambiente. Il punto rilevante non è la psicologia degli agenti. È che il comportamento osservabile, dal punto di vista di chi gestiva quel sito, è indistinguibile da quello di un attore ostile organizzato.

Perché nessuno era tenuto a segnalarlo

Qui arriva la parte che interessa direttamente chi si occupa di compliance, ed è controintuitiva.

L’articolo 55 dell’AI Act impone ai fornitori di modelli di intelligenza artificiale per finalità generali con rischio sistemico una serie di obblighi, tra cui, alla lettera c), quello di tracciare, documentare e segnalare senza indebito ritardo all’AI Office e, se del caso, alle autorità nazionali competenti, le informazioni rilevanti sugli incidenti gravi e sulle possibili misure correttive. La lettera d) impone inoltre di garantire un livello adeguato di protezione di cibersicurezza del modello e dell’infrastruttura fisica. Gli obblighi per i modelli GPAI si applicano dal 2 agosto 2025, e il 4 novembre 2025 la Commissione ha pubblicato un modello di segnalazione dedicato proprio agli incidenti gravi che coinvolgono questi modelli.

Sembrerebbe il quadro giusto. Il problema è la definizione. L’articolo 3, punto 49, definisce incidente grave un incidente o un malfunzionamento di un sistema di intelligenza artificiale che direttamente o indirettamente causa una di queste quattro conseguenze: il decesso di una persona o un grave danno alla sua salute; una perturbazione grave e irreversibile della gestione o del funzionamento di infrastrutture critiche; la violazione di obblighi del diritto dell’Unione posti a tutela dei diritti fondamentali; un danno grave a cose o all’ambiente.

Una wiki di programmazione in lingua tedesca, mantenuta da volontari, non è un’infrastruttura critica. Nessuno si è fatto male. Non emerge una violazione di obblighi europei a tutela dei diritti fondamentali. Il danno a cose, per come è configurato, difficilmente comprende le decine di ore che un moderatore ha speso in sei settimane a cancellare pagine a mano.

C’è poi un secondo livello, quello del Codice di buone pratiche per i modelli GPAI, che OpenAI ha firmato integralmente nell’estate 2025. Il Codice è volontario ma è lo strumento con cui i firmatari dimostrano di rispettare l’articolo 55, e sul punto va un po’ oltre il regolamento: la Misura 9.3 fissa un termine di cinque giorni per il rapporto iniziale quando il modello ha portato a una “grave violazione di cibersicurezza”, categoria in cui il testo include espressamente “l'(auto)esfiltrazione dei pesi del modello e gli attacchi informatici”, anche solo sospettata con ragionevole probabilità; la Misura 9.1 chiede di cercare gli incidenti anche in rapporti di stampa, post sui social e paper di ricerca; e in più punti (Misure 1.3, 2.1, 7.6 e 9.2) il Codice chiede di tenere conto dei near miss. Il Codice quindi contempla almeno un comportamento che parte dal modello, l’autoesfiltrazione, e nell’Appendice 1.3 elenca tra le fonti di rischio sistemico da valutare la “collusione con altri modelli o sistemi di IA”, la capacità di “eludere la supervisione umana” e quella di “modificare il proprio ambiente di esecuzione”: una descrizione quasi letterale di quanto accaduto su DseWiki. Ma una fonte di rischio da valutare non è un incidente da segnalare. Se un’evasione delle restrizioni di rete di un sandbox, senza pesi esfiltrati e con un bersaglio che è una wiki di volontari, rientri nella “grave violazione di cibersicurezza” della Misura 9.3 è una domanda aperta: tutto dipende da quanto si allarga “attacco informatico”, e qui la contestazione di OpenAI alla lettura di Olejnik torna a pesare. Resta il near miss, che il glossario del Codice definisce come una situazione in cui un incidente grave avrebbe potuto verificarsi ma non si è verificato: DseWiki ci sta comodamente, e i near miss vanno tenuti in conto nelle valutazioni del rischio e negli aggiornamenti dei rapporti, non segnalati all’AI Office entro un termine.

Infine, la data. I poteri sanzionatori della Commissione nei confronti dei fornitori di modelli GPAI decorrono dal 2 agosto 2026, e per i firmatari del Codice l’AI Office aveva indicato un anno di tolleranza nella prima fase di applicazione. L’intero episodio, dall’11 maggio al 2 luglio, cade dentro quel periodo.

La conclusione è scomoda ma va detta: per come sono scritte oggi le norme, un episodio in cui agenti autonomi occupano per settimane l’infrastruttura di un terzo, vi organizzano lo scambio di risposte e di tecniche di elusione dei propri controlli e reagiscono alla moderazione predisponendo canali di riserva, con ogni probabilità non integra un incidente grave ai sensi dell’AI Act, e anche sotto il Codice di buone pratiche rientra al più in una zona grigia priva, per ora, di conseguenze. Non c’era nulla che dovesse essere segnalato. Il che rende la mancata segnalazione non una violazione, ma la fotografia di una lacuna. Lo dice, con parole sue, anche OpenAI: la dichiarazione del 5 settembre ammette che manca uno standard per riferire questo tipo di eventi e che la distinzione tra disallineamento di ricerca e incidente di sicurezza sta diventando difficile da tenere. Un fornitore che annuncia un proprio quadro di divulgazione volontario è la conferma più eloquente che quello obbligatorio, oggi, non copre il caso. Del resto il segnale era già nel rapporto tecnico su Hugging Face: lì OpenAI scriveva che il comportamento agentico “può emergere in forme nuove che non sempre rientrano nelle categorie tradizionali di incidente di sicurezza o di safety”, annunciava soglie di escalation interne per la “coordinazione non autorizzata tra agenti o tra esecuzioni” e l’”elusione di controlli di sicurezza di terzi”, e rimandava a una revisione separata dei processi di risposta agli incidenti di allineamento in addestramento e valutazione. Sono esattamente le fattispecie di DseWiki, definite dal fornitore prima che il caso diventasse pubblico, e assenti dalla norma.

La soglia degli incidenti gravi è tarata sul danno alla persona e sulle infrastrutture critiche, categorie pensate per sistemi ad alto rischio che operano su processi fisici o su decisioni che incidono sulle persone. Non è tarata sul comportamento emergente di agenti che agiscono in rete su sistemi di terzi. È una categoria di evento che l’impianto non vede, e che diventerà più frequente man mano che gli agenti verranno messi in produzione. È sulle linee guida dell’AI Office e sugli aggiornamenti del Codice, più che sul testo del regolamento, che questa distanza potrà essere colmata.

La domanda che il diritto italiano non ha ancora affrontato

Se si prende sul serio la qualificazione di Olejnik, che OpenAI contesta, e si ipotizza che vi sia stato un tentativo di manomissione del sito, si apre un problema che nel nostro ordinamento non ha una risposta pronta.

L’accesso abusivo a un sistema informatico è un reato costruito attorno a una condotta umana e a un elemento soggettivo. Chi è l’autore, quando la condotta è materialmente posta in essere da un agente autonomo? Il fornitore del modello, che non ha impartito quell’istruzione e che, se la ricostruzione dei ricercatori è corretta, aveva anzi vietato ai suoi agenti di scrivere su internet? Il soggetto che ha messo l’agente in esecuzione per un compito del tutto lecito? Nessuno dei due, con la conseguenza che un fatto oggettivamente lesivo resta senza autore?

Sono domande, non tesi: la casistica non esiste ancora e questo articolo non pretende di anticiparla. Ma è utile porle adesso, perché la risposta influenzerà le clausole contrattuali che le organizzazioni firmano quando adottano agenti di terze parti, la ripartizione di responsabilità tra fornitore e utilizzatore, e la posizione di chi subisce il comportamento di un agente altrui. Su questo terreno un contributo di taglio penalistico sarebbe più utile di molte analisi tecniche.

Va aggiunto che la vittima, in questa vicenda, è la parte di cui nessuno parla: un moderatore volontario che ha assorbito per sei settimane il costo di una pulizia non richiesta, senza strumenti per farsi ascoltare e senza un interlocutore a cui rivolgersi.

Che cosa può fare oggi chi usa agenti in azienda

Al netto delle questioni aperte, l’episodio consegna a chi ha responsabilità operative un elenco di verifiche che non richiedono di attendere né una sentenza né una linea guida.

La prima domanda da porsi è la più semplice e la più temuta: se i nostri agenti facessero quindicimila scritture verso un sito esterno, ce ne accorgeremmo? Nella maggior parte delle organizzazioni la risposta è no, perché quel traffico è HTTPS in uscita verso una destinazione qualsiasi, esattamente ciò che un agente fa tutto il giorno per definizione. Il caso DseWiki aggiunge una lezione precisa: la restrizione alle sole richieste GET, che sulla carta impedisce di scrivere, in pratica non basta, perché una parte del web accetta scritture via GET e gli agenti la trovano. Non è una lacuna di prodotto, è una lacuna di progettazione dei controlli, ed è la stessa che rende difficili da vedere altre categorie di abuso, dalla prompt injection negli agenti in poi.

Le contromisure sono note e poco implementate. Filtrare il traffico in uscita degli agenti con liste di destinazioni consentite, invece di lasciare la rete aperta, e verificare che le eccezioni al proxy non possano essere sfruttate con host inventati (nel caso in esame il sandbox degli agenti considerava fidato un intero suffisso di dominio, senza controllare che l’host esistesse). Registrare separatamente le azioni di scrittura verso sistemi esterni, distinguendole dalla semplice lettura, perché è la scrittura che produce effetti sul mondo. Definire limiti di autonomia espliciti, con un tetto al numero di azioni per sessione e un intervento umano obbligatorio oltre certe soglie. Prevedere un meccanismo di interruzione che funzioni davvero e sia stato provato. Sono misure che rientrano nel perimetro della governance degli agenti autonomi e che, a differenza delle questioni regolamentari, si possono mettere in campo questo mese.

Resta un ultimo punto, di metodo. Questo episodio non è stato reso noto da un fornitore, da un’autorità o da un cliente: è stato ricostruito da quattro ricercatori indipendenti che stavano cercando esattamente quel tipo di comportamento, due mesi dopo che era cessato, partendo da log che chiunque avrebbe potuto leggere. Finché il rilevamento di questa classe di eventi dipenderà dalla curiosità di singoli, il numero di episodi noti dirà molto poco sul numero di episodi avvenuti.

https://www.ictsecuritymagazine.com/notizie/agenti-ai-dsewiki-openai-ai-act-incidenti-gravi/

Gli allegati 3 e 4 della determinazione ACN 379907/2025 elencano fattispecie diverse per le due categorie di soggetti NIS. La differenza non è formale: davanti allo stesso identico attacco, due organizzazioni possono avere obblighi di notifica diversi, e la variabile non è la gravità tecnica.

Un caso concreto per rendere visibile la differenza

Conviene partire da uno scenario reale, perché la distinzione che segue è astratta finché non la si prova su un fatto.

All’inizio di settembre 2026 sono stati osservati i primi tentativi di sfruttamento della CVE-2026-19490, un authentication bypass con punteggio CVSS 9.3 che interessa le appliance Citrix NetScaler configurate come gateway di accesso remoto o come virtual server AAA. La caratteristica rilevante ai nostri fini è che l’attaccante che riesce non installa nulla: ottiene una sessione valida, indistinguibile a valle da quella di un dipendente. Chi se ne accorge, spesso, si trova con una traccia di accesso anomalo e con la difficoltà di stabilire che cosa quell’accesso abbia effettivamente raggiunto.

È esattamente la situazione in cui la qualificazione dell’incidente diventa difficile, e in cui la differenza tra allegato 3 e allegato 4 smette di essere una sottigliezza.

Dove stanno le fattispecie

Il quadro è fissato dalla determinazione ACN 379907/2025, firmata il 18 dicembre 2025 e applicabile dal 15 gennaio 2026, che aggiorna e sostituisce la determinazione 164179 del 14 aprile 2025. Adottata ai sensi dell’articolo 31 del D.Lgs. 138/2024, stabilisce in fase di prima applicazione le modalità e le specifiche di base per gli obblighi di cui agli articoli 23, 24, 25, 29 e 32 del decreto.

L’articolo 2 distribuisce la materia su quattro allegati: gli allegati 1 e 2 contengono le misure di sicurezza di base, rispettivamente per i soggetti importanti e per quelli essenziali; gli allegati 3 e 4 contengono gli incidenti significativi di base, con la stessa ripartizione.

Tre fattispecie per gli importanti, quattro per gli essenziali

L’allegato 3, che vale per i soggetti importanti, elenca tre tipologie:

• IS-1: il soggetto ha evidenza della perdita di riservatezza, verso l’esterno, di dati digitali di sua proprietà o sui quali esercita il controllo, anche parziale;
• IS-2: evidenza della perdita di integrità, con impatto verso l’esterno, degli stessi dati;
• IS-3: evidenza della violazione dei livelli di servizio attesi dei propri servizi o delle proprie attività, sulla base dei livelli di servizio stabiliti ai sensi della misura DE.CM-01.

L’allegato 4, per i soggetti essenziali, riprende le stesse tre e ne aggiunge una quarta:

• IS-4: il soggetto ha evidenza, anche sulla base dei parametri quali-quantitativi definiti ai sensi della misura DE.CM-01, dell’accesso, non autorizzato o con abuso dei privilegi concessi, a dati digitali di sua proprietà o sui quali esercita il controllo, anche parziale.

Che cosa aggiunge davvero IS-4

Qui si annidano due equivoci, e vale la pena scioglierli entrambi.

Il primo riguarda l’oggetto della fattispecie. IS-4 non si attiva perché qualcuno ha ottenuto una sessione: richiede evidenza dell’accesso non autorizzato a dati digitali. Un attaccante che sfrutta un bypass dell’autenticazione e si ferma alla sessione, senza raggiungere dati, sta in una zona che va valutata caso per caso. Un attaccante che da quella sessione arriva a dati, anche solo consultandoli, integra IS-4 in modo piano.

Il secondo equivoco è più insidioso, ed è quello che circola come slogan: che l’accesso non autorizzato sia notificabile per gli essenziali e non per gli importanti. Non è così, o non in modo così netto. Un attaccante esterno che legge dati produce con ogni probabilità anche una perdita di riservatezza verso l’esterno, quindi un IS-1, che sta nell’allegato 3 e vincola pure i soggetti importanti.

La differenza reale è di soglia probatoria. Per un soggetto essenziale è sufficiente l’evidenza dell’accesso non autorizzato, o dell’abuso dei privilegi concessi, perché l’obbligo scatti. Per un soggetto importante occorre poter affermare che si è prodotta una perdita di riservatezza verso l’esterno, e quando l’analisi forense non riesce a stabilire se i dati siano stati effettivamente letti o portati fuori, quell’affermazione non è sostenibile.

Il risultato pratico è che due organizzazioni colpite dallo stesso attacco, con la stessa dinamica e lo stesso livello di incertezza sull’esito, possono avere obblighi diversi: l’essenziale notifica sulla base di ciò che ha osservato, l’importante potrebbe legittimamente non avere nulla da notificare. La variabile non è la gravità tecnica dell’attacco, è la classificazione del soggetto unita a quanto si riesce a ricostruire.

C’è poi un’estensione di IS-4 che si tende a trascurare, perché non riguarda gli attacchi: la fattispecie copre anche l’abuso dei privilegi concessi, quindi condotte interne prive di qualsiasi proiezione verso l’esterno. Un amministratore che consulta dati fuori dalle proprie necessità funzionali rientra in IS-4 per un soggetto essenziale, e resta fuori dal perimetro di notifica per un soggetto importante.

Una avvertenza di metodo, per onestà verso il lettore: gli allegati non definiscono l’espressione “verso l’esterno”, e la lettura proposta qui è interpretativa. Su un punto che decide se una notifica va fatta o meno, il confronto con il proprio consulente legale non è un passaggio formale.

DE.CM-01, la misura senza la quale IS-4 non è applicabile

La formulazione di IS-4 rinvia ai parametri quali-quantitativi definiti ai sensi della misura DE.CM-01, e questo rinvio ha una conseguenza che va colta.

Le linee guida ACN sulla definizione del processo di gestione degli incidenti ricordano che, per i soggetti essenziali, i punti 4, 5 e 6 di quella misura richiedono, per almeno i sistemi informativi e di rete rilevanti, di impiegare strumenti di analisi e filtraggio sul traffico in ingresso, di monitorare gli accessi da remoto, l’attività dei sistemi perimetrali come router e firewall, gli eventi amministrativi di rilievo e gli accessi eseguiti o falliti verso risorse di rete, punti terminali e applicativi, e infine di definire, monitorare e documentare parametri quali-quantitativi per rilevare gli accessi non autorizzati o con abuso dei privilegi concessi.

Gli esempi che le linee guida portano sono istruttivi perché molto concreti: un indicatore quantitativo può essere il superamento di una soglia di interrogazioni a una banca dati da parte di un singolo utente; uno qualitativo, l’accesso di un amministratore di sistema al di fuori dell’orario di servizio.

Chi quei parametri non li ha definiti e documentati si trova nella posizione peggiore possibile. Non dispone degli elementi per qualificare l’incidente, quindi non è in grado di stabilire se abbia o meno un obbligo di notifica; e l’assenza di quei parametri è a sua volta una carenza rispetto alle misure di base. È il caso in cui una lacuna organizzativa si traduce direttamente in un rischio sanzionatorio su due fronti.

I termini, e da quando decorrono davvero

L’articolo 3 della determinazione fissa le decorrenze a partire dalla ricezione della comunicazione di inserimento nell’elenco dei soggetti NIS: diciotto mesi per l’adozione delle misure di sicurezza di base, nove mesi per l’obbligo di notifica degli incidenti significativi di base previsto dall’articolo 25 del decreto.

Nella propria comunicazione l’ACN affianca a quei termini le date di ottobre 2026 e gennaio 2026, riferite a chi ha ricevuto la comunicazione nella prima tornata. Per i soggetti inseriti nell’elenco per la prima volta nel 2026 i termini sono stabiliti da una determinazione successiva, quindi le date vanno ricalcolate e non date per scontate.

Sul momento in cui parte l’orologio le linee guida chiariscono l’equivoco più diffuso. Ciò che rileva non è il verificarsi dell’incidente ma l’evidenza dell’incidente, ossia il momento in cui il soggetto dispone di elementi oggettivi dai quali si evince che un incidente si è verificato. L’acquisizione dell’evidenza è tipicamente successiva al fatto ed è quella a far decorrere i termini. Il documento aggiunge un passaggio decisivo: ai fini dell’obbligo di notifica non è necessario valutare o risalire alla causa iniziale dell’incidente. Attendere la root cause prima di notificare non è prudenza, è un errore procedurale.

La sequenza verso il CSIRT Italia, da trasmettere tramite il portale segnalazioni.acn.gov.it a cura del referente CSIRT designato, è la seguente:

• pre-notifica entro 24 ore, indicando ove possibile se l’incidente possa ritenersi il risultato di atti illegittimi o malevoli e se possa avere impatto transfrontaliero;
• notifica entro 72 ore, che aggiorna le informazioni precedenti e aggiunge una valutazione iniziale di gravità e impatto e, ove disponibili, gli indicatori di compromissione;
• relazione intermedia, su richiesta del CSIRT Italia;
• relazione finale entro un mese dalla trasmissione della notifica, con descrizione dettagliata, tipo di minaccia o causa originale, misure di attenuazione adottate e in corso, impatto transfrontaliero ove noto;
• se l’incidente è ancora in corso al momento della relazione finale, relazione mensile sui progressi e relazione finale entro un mese dalla conclusione della gestione.

Il termine della relazione finale decorre dalla notifica delle 72 ore, non dall’evidenza dell’incidente: in fase di pianificazione è la differenza tra un calendario corretto e uno sbagliato di tre giorni.

Quasi-incidenti e doppio binario con il GDPR

Due corollari completano il quadro e vengono spesso trascurati.

Il primo riguarda i tentativi bloccati. Un attacco rilevato e fermato senza che si produca alcun impatto può ricadere nella nozione di quasi-incidente del decreto, che comprende gli eventi che avrebbero potuto configurare un incidente senza che questo si sia verificato, incluso il caso in cui l’incidente sia stato efficacemente evitato. Non fa scattare l’obbligo di notifica, ma può essere comunicato volontariamente al CSIRT Italia, facoltà che le linee guida richiamano espressamente. Su vulnerabilità la cui telemetria pubblica poggia su pochi operatori privati, la notifica volontaria non è un adempimento burocratico: è il modo in cui si costruisce un quadro nazionale che altrimenti non esiste.

Il secondo riguarda il GDPR. Se l’incidente comporta una violazione di dati personali, alla notifica al CSIRT Italia si affianca quella al Garante ai sensi dell’articolo 33 del Regolamento (UE) 2016/679, salvo che sia improbabile un rischio per i diritti e le libertà delle persone fisiche. Sono due binari autonomi, con destinatari, termini e valutazioni proprie, e vanno percorsi entrambi.

Che cosa conviene mettere a posto adesso

La lettura combinata degli allegati suggerisce tre verifiche che non richiedono un progetto e che conviene fare prima del prossimo incidente, non durante.

La prima è banale solo in apparenza: sapere con certezza se la propria organizzazione è classificata come essenziale o importante, perché da lì discende quale allegato si applica. La seconda è verificare se i parametri quali-quantitativi della misura DE.CM-01 esistono, sono documentati e sono effettivamente monitorati, perché senza di essi IS-4 resta inapplicabile e l’organizzazione è cieca proprio sulla fattispecie che la riguarda. La terza è accertarsi che il referente CSIRT sia designato, con i suoi sostituti, e che la procedura interna registri l’orario in cui si acquisisce evidenza di un incidente: è quell’orario, e non altro, a far partire le ventiquattro ore.

Tutte e tre sono verifiche documentali. Nessuna costa quanto una notifica tardiva.

Il caso Citrix NetScaler da cui siamo partiti è analizzato sul piano tecnico e di incident response nell’articolo dedicato alla CVE-2026-19490.

https://www.ictsecuritymagazine.com/notizie/incidenti-significativi-nis2-is4-soggetti-essenziali-importanti/

Un exploit pubblico il 2 settembre, i primi tentativi osservati il giorno dopo: la falla che consente di aggirare l’autenticazione su NetScaler ADC e Gateway è passata in ventiquattro ore dalla teoria alla pratica. Citrix dichiara che non esistono workaround, e il solo aggiornamento non chiude la partita.

Da rischio teorico a sfruttamento osservato

Il 19 agosto 2026 Citrix ha pubblicato il bollettino CTX696939, che documenta due vulnerabilità in NetScaler ADC e NetScaler Gateway. La più grave è la CVE-2026-19490, un authentication bypass con punteggio CVSS v4.0 pari a 9.3, classificato come CWE-288, ossia aggiramento dell’autenticazione attraverso un percorso o un canale alternativo. Il vettore descrive un attacco sfruttabile da remoto, a bassa complessità, senza privilegi né interazione dell’utente, con impatto elevato su riservatezza, integrità e disponibilità del sistema colpito. La seconda, CVE-2026-19489 (CVSS 8.8), è un memory overflow che interessa unicamente le configurazioni con gruppi Large Scale NAT e SIP ALG abilitato, quindi con una superficie di esposizione molto più ristretta.

Per due settimane la CVE-2026-19490 è rimasta un rischio potenziale. Il quadro è cambiato quando, il 2 settembre, è stato creato su GitHub un repository con un proof of concept che richiama esplicitamente il bollettino. Il giorno successivo un sensore della società di vulnerability intelligence Previdian ha intercettato le prime richieste corrispondenti a quell’exploit. La scheda di tracciamento tenuta dalla società, aggiornata al 4 settembre, riporta dieci tentativi complessivi provenienti da sei indirizzi IP unici, geolocalizzati in Australia, Germania, Giappone e Stati Uniti, e attribuisce allo sfruttamento attivo un livello di confidenza medio, sostenuto da tre elementi: la telemetria propria, l’attestazione di terze parti e la disponibilità pubblica dell’exploit.

Ventiquattro ore tra la comparsa dell’exploit e i primi tentativi osservati: è questo il dato che dovrebbe orientare la priorità di intervento, più del punteggio CVSS.

Il numero degli indirizzi è cresciuto nel corso della rilevazione, ed è la ragione per cui in giro si leggono cifre diverse: il 3 settembre Ryan Dewhurst, fondatore di Previdian, aveva parlato a BleepingComputer di tre indirizzi distinti tra Australia, Stati Uniti e Germania.

Due precisazioni sono doverose, e vengono dalla fonte stessa. Dewhurst ha sottolineato che si tratta di tentativi di sfruttamento, non della conferma di compromissioni riuscite su sistemi reali. E la rilevazione, come indica la stessa scheda, poggia su un solo sensore: è un segnale, non una misura della campagna.

Sul versante istituzionale, oltre al richiamo di Citrix di metà agosto, il Centre for Cybersecurity Belgium, che opera come centro nazionale di coordinamento NCC-BE, ha pubblicato il 4 settembre un avviso sui tentativi di sfruttamento della vulnerabilità, invitando gli amministratori a dare priorità all’aggiornamento di tutte le appliance vulnerabili.

Chi è vulnerabile, e perché questo bypass è difficile da vedere

La vulnerabilità interessa le appliance configurate come virtual server AAA oppure come Gateway nelle funzioni di SSL VPN, ICA Proxy, CVPN e RDP Proxy. Sono quindi coinvolti esattamente i dispositivi che governano l’accesso remoto: il perimetro logico dell’organizzazione.

Il dettaglio operativo che conta di più, e che nella copertura della notizia resta spesso implicito, riguarda i prerequisiti, che variano in funzione della build installata e della presenza di una SAML action:

• sulle versioni 14.1-43.56 e successive, e 13.1-61.28 e successive, lo sfruttamento richiede che sia configurata una SAML action oltre al Gateway o al virtual server AAA;
• sulle versioni 14.1-43.55 e precedenti, e 13.1-61.27 e precedenti, è sufficiente la presenza di un Gateway o di un virtual server AAA, senza alcun requisito aggiuntivo;
• le installazioni 13.1 FIPS risultano interessate quando l’appliance è configurata come Gateway o virtual server AAA.

La conseguenza è controintuitiva ma decisiva: più il firmware è vecchio, più ampia è la condizione di vulnerabilità. Le organizzazioni che hanno rinviato gli aggiornamenti non sono soltanto in ritardo, sono esposte su una superficie più larga.

Una precisazione va fatta proprio sul ruolo del SAML, perché si presta a un equivoco che circola già. Che su alcune build serva una SAML action configurata non significa che la vulnerabilità consista nella falsificazione di asserzioni SAML o nella rottura della relativa catena di firme: la presenza del SAML è un prerequisito di configurazione, non necessariamente il meccanismo dell’attacco. Citrix non ha pubblicato dettagli implementativi, e gli analisti che hanno esaminato il caso si sono astenuti dal ricostruire il meccanismo in assenza di quei dettagli. Chi legge un proof of concept di terze parti farebbe bene ad applicare la stessa cautela alla descrizione che quel codice dà di sé.

Sul piano della rilevabilità, e non della gravità assoluta, un authentication bypass su un concentratore VPN pone un problema diverso e per certi versi peggiore di una esecuzione di codice remota: l’accesso iniziale non richiede di installare nulla. L’attaccante ottiene una sessione che, agli occhi dei sistemi a valle, è indistinguibile da quella di un dipendente legittimo. Nel momento dell’ingresso non c’è dropper, non c’è beacon, non c’è artefatto sul disco: c’è un utente che si autentica e comincia a muoversi. È il tipo di compromissione che sfugge alle logiche di detection basate sull’endpoint e che emerge, quando emerge, dall’analisi comportamentale delle sessioni.

Le versioni corrette e il nodo dei workaround

Le build che risolvono la vulnerabilità sono:

Su questo punto serve una precisazione che cambia il modo di pianificare l’intervento: alla voce workaround e fattori di mitigazione, il bollettino Citrix riporta “None”. Non esiste cioè un ripiego riconosciuto dal vendor, e l’unica risposta prevista è l’aggiornamento.

Circola, riportata da Help Net Security, la possibilità di una mitigazione basata su firme applicabile tramite NetScaler Console sui firmware successivi a 14.1-60.52 e a partire da 13.1-63.16, che dispongono della funzione Global Deny Lists. È una capacità del prodotto, non una misura che il bollettino avalli per questa vulnerabilità. Chi la adotta lo fa come tampone in attesa della finestra di manutenzione, e ha tutto l’interesse a verbalizzarla come tale: un ripiego documentato, con la sua motivazione e la sua scadenza, regge a un’ispezione; un ripiego non documentato no.

Sul fronte dell’esposizione, i conteggi Shadowserver riportati da BleepingComputer indicano oltre 22.000 appliance NetScaler ADC e quasi 1.700 istanze Gateway raggiungibili da internet a livello globale. Il numero va maneggiato con cautela: non è dato sapere quanti di quei sistemi siano honeypot, quanti abbiano una configurazione effettivamente vulnerabile e quanti siano già stati aggiornati. La vista collegata, che riguarda le istanze Gateway, è raggruppata per Paese, quindi chi vuole la fotografia italiana può leggerla direttamente lì, tenendo presente che conta dispositivi esposti e non vulnerabili.

Un precedente di pochi mesi fa

Le ventiquattro ore tra exploit pubblico e primi tentativi non sono un’anomalia di questa vicenda, ed è quanto era già accaduto sullo stesso prodotto in primavera.

Il 23 marzo 2026 Citrix aveva pubblicato l’avviso per altre due falle NetScaler, le CVE-2026-3055 e CVE-2026-4368. La prima, anch’essa con punteggio 9.3, è finita nel catalogo delle vulnerabilità attivamente sfruttate della CISA entro una settimana dall’avviso e comunque entro la fine dello stesso mese, con un termine di pochi giorni imposto alle agenzie federali statunitensi per l’aggiornamento.

Il dato d’insieme è più eloquente del singolo caso. Secondo il conteggio di BleepingComputer sul catalogo della CISA, da novembre 2021 sono ventitré le vulnerabilità Citrix classificate come sfruttate in rete, sei delle quali utilizzate anche da gruppi ransomware. Su questi apparati la sequenza avviso, analisi pubblica, sfruttamento non è un’eventualità remota, è lo schema ricorrente.

Proprio questo precedente suggerisce una considerazione, che è redazionale e non un dato. Il catalogo KEV della CISA viene spesso usato, anche fuori dagli Stati Uniti, come soglia implicita per far scattare un intervento urgente, ma è uno strumento rivolto alle agenzie federali statunitensi e non ha valore prescrittivo per un’organizzazione italiana. Usarlo come innesco è per di più una scelta fragile, perché l’inserimento nel catalogo certifica uno sfruttamento già in corso e arriva quindi, per definizione, dopo che la finestra di prevenzione si è chiusa. Il caso in esame lo conferma dal lato opposto: alla verifica del 5 settembre la CVE-2026-19490 non risulta nel catalogo, pur avendo punteggio 9.3, un exploit pubblico dal 2 settembre e tentativi osservati dal 3. Il segnale che conta non è l’ingresso in un elenco estero, è la combinazione di quei tre elementi, che qui era completa da giorni.

Threat hunting: cosa cercare, e perché la patch non basta

Aggiornare è necessario, non sufficiente. La lezione della CitrixBleed del 2023 (CVE-2023-4966) è stata proprio questa: un token di sessione sottratto resta valido dopo l’aggiornamento e consente, come rilevò allora Tenable, di aggirare l’autenticazione anche dove è attiva l’autenticazione a più fattori. Fu lo stesso vendor a raccomandare, dopo l’upgrade, la rimozione delle sessioni attive e persistenti con i comandi kill aaa session -all, kill icaconnection -all, kill rdp connection -all, kill pcoipConnection -all e clear lb persistentSessions.

Il bollettino per la CVE-2026-19490 non contiene indicazioni analoghe, quindi quella che segue è una sequenza derivata da quel precedente, non una prescrizione del vendor per questa vulnerabilità.

1. Inventario. Individuare tutte le appliance con Gateway o virtual server AAA configurati, rilevando firmware e presenza di SAML action. NetScaler Console mette a disposizione una funzione di rilevamento per CVE con avvio manuale della scansione.
2. Aggiornamento, con priorità alle appliance esposte su internet e ai firmware più datati, che come visto sono vulnerabili in condizioni più ampie.
3. Terminazione delle sessioni attive e persistenti dopo l’aggiornamento, seguita dalla rotazione delle credenziali e dei segreti gestiti dalle appliance.
4. Ricerca retrospettiva nei log. Le evidenze pubbliche partono dal 3 settembre, ma il punto di ingresso esiste da prima del bollettino e nulla esclude che qualcuno lo conoscesse per conto proprio: il 19 agosto è quindi il punto di partenza minimo ragionevole, non un confine. Da cercare: sessioni prive di un corrispondente evento di autenticazione, richieste SAML anomale, accessi da aree geografiche o intervalli di indirizzi inconsueti, modifiche di configurazione successive ad attività sospetta.
5. Correlazione a valle, perché il segnale più affidabile non è sull’appliance ma su ciò che è accaduto dopo: autenticazioni verso applicazioni interne provenienti da sessioni VPN senza storia, movimenti laterali, enumerazione di directory.

Il punto quattro è quello che distingue una risposta seria da una spunta su un foglio di calcolo. Se dall’analisi non emerge nulla, il risultato va comunque verbalizzato: in un’eventuale interlocuzione con l’autorità, l’assenza documentata di evidenze vale infinitamente più dell’assenza di documentazione.

Vale la pena aggiungere che, per le organizzazioni che ricadono nel perimetro NIS, l’esito di quella ricerca non resta un fatto interno. Se emergono evidenze di accesso non autorizzato scattano termini di notifica stretti verso il CSIRT Italia, e le fattispecie da notificare non sono le stesse per i soggetti essenziali e per quelli importanti: ne trattiamo nell’analisi dedicata agli incidenti significativi di base.

Il nodo strutturale

Ogni ciclo si ripete con la stessa meccanica: dispositivo di frontiera, vulnerabilità pre-autenticazione, PoC pubblico, sfruttamento nel giro di ore. I concentratori VPN e i gateway di accesso remoto restano il punto debole strutturale delle architetture aziendali perché concentrano una funzione critica in un software monolitico, esposto per definizione e aggiornabile solo con una finestra di manutenzione.

Le contromisure che riducono davvero l’impatto sono note e poco praticate: limitare l’interfaccia di gestione a intervalli di indirizzi amministrativi, separare il piano di gestione da quello di produzione, applicare virtual patching a monte con un web application firewall, segmentare ciò che sta oltre il gateway in modo che una sessione compromessa non si traduca automaticamente in accesso alla rete piatta. Nessuna di queste misure impedisce lo sfruttamento della CVE-2026-19490. Tutte riducono ciò che l’attaccante ottiene una volta dentro, che è la variabile su cui si gioca la differenza tra un incidente da notificare e una crisi da gestire.

https://www.ictsecuritymagazine.com/notizie/cve-2026-19490-citrix-netscaler-authentication-bypass/

Il 3 settembre 2026 il Dipartimento di Stato americano ha offerto una ricompensa fino a 10 milioni di dollari per informazioni su Amir Yaryab (traslitterato anche Amir Yariab), alto funzionario del Corpo delle Guardie della Rivoluzione Islamica che guida le operazioni cyber offensive dell’IRGC. Dopo la taglia sul capo del Cyber-Electronic Command, Hamid Reza Lashgarian, in vigore dal 2024 e riproposta il 24 agosto scorso nel pacchetto sui vertici IRGC, Washington scende ora al livello operativo e indica pubblicamente la figura che, secondo le autorità USA, dirige gruppi come CyberAv3ngers.

Chi è Amir Yaryab e quali gruppi dirige

Secondo l’avviso ufficiale del programma Rewards for Justice, Yaryab è un alto funzionario del Cyber-Electronic Command dell’IRGC (IRGC-CEC) e ne guida il Cyber Operations Command. Dirige inoltre diverse componenti del comando, tra cui le unità Shahid Hemmat e Shahid Shushtari, responsabili di operazioni cyber e di information operations cyber-enabled contro infrastrutture critiche.

Lo stesso avviso attribuisce a Yaryab la supervisione e il controllo dei gruppi affiliati all’IRGC-CEC CyberAv3ngers, Dadeh Afzar Arman (DAA) e Mehrsam Andisheh Saz Nik (MASN), accusati di aver impiegato malware contro infrastrutture civili in tutto il mondo. La scheda elenca tra le organizzazioni associate anche Emennet Pasargad, Net Peygard Samavat, Aria Sepehr Ayandehsazan (ASA), l’IRGC Jangal Organization e la persona online “Mr. Soul”, oltre a diciassette individui, diversi dei quali già sanzionati o incriminati negli Stati Uniti, tra cui lo stesso Lashgarian e i cinque dirigenti IRGC-CEC colpiti dal Tesoro nel febbraio 2024. Il quadro collega sotto un’unica direzione attori finora trattati come sigle separate.

La ricompensa, come specifica l’avviso, è offerta per informazioni che portino a identificare o localizzare chiunque, agendo per conto di un governo straniero, partecipi ad attività cyber malevole contro le infrastrutture critiche USA in violazione del Computer Fraud and Abuse Act. Secondo Iran International, il programma prevede anche assistenza al trasferimento per gli informatori. L’annuncio è stato ripreso, tra gli altri, da The Record e Al-Monitor.

Perché l’attribuzione è ad alta confidenza

L’attribuzione proviene direttamente dal governo statunitense ed è coerente con oltre un decennio di operazioni documentate, la cui architettura organizzativa ICT Security Magazine ha ricostruito nell’analisi su strutture, strategie e capacità cibernetiche dell’Iran nel Quinto Dominio. CyberAv3ngers è il gruppo che nel 2023 compromise PLC Unitronics esposti su Internet e protetti da credenziali di default presso utility idriche americane e israeliane, che nel 2024 introdusse il malware ICS IOCONTROL e che, secondo Tenable, nel 2026 sfrutta attivamente CVE-2021-22681, un bypass di autenticazione senza patch nei controller Rockwell Automation.

Per queste attività Rewards for Justice aveva già pubblicato una taglia sul gruppo e sui sei dirigenti IRGC-CEC sanzionati dal Tesoro nel febbraio 2024 e, nel giugno 2025, una seconda ricompensa centrata sulla persona “Mr. Soul” legata a IOCONTROL.

La taglia su Yaryab arriva inoltre a valle di un’escalation di misure statunitensi nelle ultime settimane. Il 18 agosto il Dipartimento di Giustizia ha incriminato 17 persone legate al Mabna Institute, contractor che operava per conto dell’IRGC in una campagna di furto di proprietà intellettuale che aveva colpito, tra gli altri, Department of Labor, Federal Energy Regulatory Commission e organizzazioni ONU. Il 24 agosto il Tesoro ha sanzionato operatori del Ministero dell’Intelligence (MOIS) per attacchi a infrastrutture critiche, nell’ambito del pacchetto definito “economic D-Day”, pochi giorni dopo la notizia di un’intrusione in una piccola centrale elettrica nel Regno Unito.

Settori e geografie nel mirino

L’avviso del Dipartimento di Stato indica che i gruppi diretti da Yaryab hanno colpito infrastrutture critiche in Stati Uniti, Europa e Medio Oriente, nei settori difesa, media, shipping, trasporti (hotel e compagnie aeree), energia, finanza e telecomunicazioni.

A questo quadro si aggiunge la campagna contro il settore idrico americano in corso dalla fine di luglio. Un advisory congiunto di FBI, NSA, Dipartimento dell’Energia e CISA aggiornato il 22 luglio segnalava attori iraniani impegnati a manipolare PLC esposti su Internet in impianti idrici ed energetici; nelle settimane successive, secondo la mappatura del CSIS, le intrusioni hanno interessato circa 100 impianti in almeno 12 Stati, con cambi di password per escludere gli operatori, passaggi in modalità manuale e alcuni avvisi di bollitura dell’acqua. Va precisato che, mentre funzionari e analisti attribuiscono la campagna all’Iran, CISA non ha formalizzato pubblicamente l’attribuzione di questa specifica ondata e non risultano incriminazioni collegate.

Cosa significa per gli operatori europei e per la NIS2

La novità non è tanto l’attribuzione in sé quanto il consolidamento della catena di comando: gruppi che si presentano con identità distinte rispondono a una direzione IRGC centralizzata, e le infrastrutture civili restano un obiettivo strategico deliberato nel contesto del conflitto tra Stati Uniti e Iran, che ICT Security Magazine segue dall’avvio delle operazioni militari del 28 febbraio 2026. L’intrusione nella centrale britannica, se confermata nell’attribuzione, indica che il perimetro europeo non è teorico.

Al momento non risultano advisory specifiche di ENISA o dell’Agenzia per la Cybersicurezza Nazionale su questo annuncio: le indicazioni che seguono sono una lettura operativa, non una raccomandazione delle autorità. Per energia, acqua, telecomunicazioni e trasporti, settori essenziali ai sensi della direttiva NIS2, i punti di attenzione sono tre: monitoraggio delle TTP iraniane note, verifica dell’esposizione su Internet di PLC, HMI e protocolli industriali (Siemens, Rockwell, Modbus), tema già evidenziato nella notizia sulle operazioni ibride iraniane contro infrastrutture OT e ambienti Microsoft 365, e revisione degli accessi remoti, che nelle utility americane colpite erano spesso la comodità di un unico operatore trasformata in porta d’ingresso.

Sia nel 2023 sia nel 2026 il bersaglio non è stata la grande utility presidiata, ma l’impianto periferico con difese minime: una descrizione che si applica a gran parte del tessuto infrastrutturale europeo.

Domande frequenti

Chi è Amir Yaryab? È un alto funzionario del Cyber-Electronic Command dell’IRGC che, secondo il Dipartimento di Stato USA, guida il Cyber Operations Command e dirige le unità Shahid Hemmat e Shahid Shushtari, oltre a supervisionare gruppi affiliati come CyberAv3ngers. Il vertice dell’IRGC-CEC resta Hamid Reza Lashgarian, anch’egli oggetto di una taglia da 10 milioni.

Cos’è CyberAv3ngers? È un gruppo affiliato all’IRGC-CEC noto per gli attacchi del 2023 contro utility idriche tramite PLC Unitronics con credenziali di default, per il malware ICS IOCONTROL (2024) e per lo sfruttamento nel 2026 di CVE-2021-22681 nei controller Rockwell.

Cosa dovrebbero fare gli operatori soggetti a NIS2? Rafforzare il monitoraggio delle TTP iraniane, ridurre l’esposizione su Internet dei sistemi OT/ICS e rivedere gli accessi remoti, con priorità agli impianti periferici meno presidiati.

https://www.ictsecuritymagazine.com/geopolitica-cyberspazio/amir-yaryab-taglia-usa/

Hackers have been exploiting a critical-severity vulnerability in the Elementor Pro WordPress plugin to hack websites, WordPress security firm Defiant warns.

A highly popular drag-and-drop website builder, Elementor is a free WordPress plugin with over 10 million installations. Elementor Pro is the paid version that offers additional features, including a Form widget with support for File Upload fields.

The bug, tracked as CVE-2026-32475 (CVSS score of 9.8), is described as an arbitrary file upload issue in the function that handles form submissions.

While submissions are passed through the plugin’s validation and processing mechanisms, when the validation loop encounters an upload slot marked as empty, it triggers an error and returns, aborting the validation of other files in the field.

The normal behavior would be to continue, skipping the empty entry, but the vulnerability results in checks never being applied to the remaining files uploaded through the same form field.

An attacker can submit an upload field as an array with two parts: an empty slot that triggers the return, followed by a PHP payload that is uploaded without validation.

Because the function that handles field processing correctly skips the empty slot and processes the second, unvalidated part of the field, the attacker-supplied file is written to disk.

“As a result, an unauthenticated attacker can request the uploaded file to execute their PHP payload on the server,” Defiant explains, noting that this could lead to full site compromise.

CVE-2026-32475 impacts all Elementor Pro plugin versions up to 4.2.1 and was patched in version 4.2.2 on August 19. Site owners should update to the fixed iteration as soon as possible.

According to Defiant, threat actors started exploiting the security defect immediately after the fixes landed. The security firm has blocked over 190,000 exploit attempts to date.

Successful exploitation of the vulnerability results in a PHP file being written to the /wp-content/uploads/elementor/forms/ directory, which stores uploaded form submissions.

Site administrators are advised to check the directory for the presence of any PHP file, which is a strong indicator of compromise (IoC). They should also check logs for requests to /wp-admin/admin-ajax.php and check their sites for backdoors if any evidence of compromise is discovered.

Defiant notes that Elementor Pro has over 6 million active installations, but it is unclear how many of them are affected. According to WordPress data, approximately two-thirds of Elementor’s 10 million installations run a vulnerable plugin version as of September 4.

Related: 12-Year-Old PostgreSQL Vulnerability Enables Database, Server Takeover

Related: VMware Workstation and Fusion Updates Patch Critical Vulnerability

Related: Google Patches 6th Chrome Zero-Day of 2026

Related: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability

https://www.securityweek.com/elementor-pro-wordpress-plugin-vulnerability-exploited-to-hack-sites/

A clever technique used to hide malicious prompts in attacks on AI agents has been adopted by spammers to evade filters on email platforms that are designed to flag unwanted messages used in mass campaigns.

The technique is broadly known as ASCII smuggling. It gained attention two years ago as a means of making a class of AI attack known as prompt injections more stealthy. Malicious instructions embedded in emails or other untrusted content to be processed by an LLM aren’t written in ordinary text. Instead, they’re rendered by a special range of Unicode tags. For example, the tag point U+E0041 mirrors “A,” and U+E0061 mirrors “a.”

No longer just for obscuring prompt injections

The block of 128 tags mimics a portion of the American Standard Code for Information Interchange almost perfectly, with one major difference: the characters they encode are readable by computers but, by design, are almost completely invisible to humans. By expressing the malicious prompts in these tags, LLMs detect the instructions, but people reading the email never see them. There’s much more about ASCII smuggling here.

Read full article

Comments

https://arstechnica.com/security/2026/09/once-popular-for-attacking-ai-ascii-smuggling-is-embraced-by-spammers/

Hewlett Packard Enterprise (HPE) has released patches for 34 CVEs in the Aruba Networking ArubaOS-CX (AOS-CX) platform, including critical-severity remote code execution (RCE) flaws.

Per HPT’s advisory, more than 150 flaws were resolved in AOS-CX versions 10.18.1002, 10.17.1030, 10.16.1060, 10.13.1190, and 10.10.1181. Many of these bugs are tracked together under single CVEs.

Nearly two dozen issues, tracked collectively as CVE-2026-73749 (CVSS score of 9.8), were addressed with the updates.

The critical security defects are rooted in the improper processing of malformed input sent to an unnamed service within HPE’s database-centric operating system for enterprise switches.

According to the company, an unauthenticated attacker could exploit the security defects by sending crafted packets to the vulnerable service, achieving RCE with elevated privileges.

The fresh updates also resolve 22 high-severity CVEs that could lead to denial-of-service (DoS), RCE, arbitrary command execution, arbitrary script code execution in a victim’s browser, authentication bypass, privilege escalation, and information disclosure.

All the remaining 11 CVEs are medium-severity flaws leading to access controls bypass, information disclosure, arbitrary file reads, DoS, and privilege escalation.

HPE says the majority of these vulnerabilities were discovered internally by its security team, noting that it is not aware of any of them being exploited in the wild.

“To minimize the likelihood of an attacker exploiting these vulnerabilities, HPE Networking recommends that the CLI and web-based management interfaces be restricted to a dedicated layer 2 segment/VLAN and/or controlled by firewall policies at layer 3 and above along with accounting controls for tracking and logging user activities and resource usage,” the company notes.

Related: Sangoma Switchvox Vulnerabilities Exploited in the Wild

Related: VMware Workstation and Fusion Updates Patch Critical Vulnerability

Related: Capsule Security Launches ‘AI Circuit Breaker’ to Stop Rogue Agents

Related: Cisco Warns of Unpatched Secure Email Flaws, Patches Critical Switch Vulnerabilities

https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx/

Daybreak is OpenAI’s continuously running agentic loop that brings the power of frontier AI to simplify complex security investigations, validation, remediation and reporting. The earlier Daybreak Blue supports common defensive work with OpenAI mainline models; while Daybreak Red gives approved organizations access to specialized cyber models for more sensitive and technically demanding work.

The new Daybreak for Frontline Defenders was announced on September 3, 2026, as a $1 billion subsidy for Frontline Defenders to access Daybreak. These frontline defenders are defenders required to protect the critical industry, often under-funded and usually with aging equipment. While the commitment is global, the announcement makes it clear that initial priority will be given to American companies.

“Every day, we depend on cyber defenders to protect the systems that keep communities running: the water coming from the tap, the electricity powering homes and businesses, the local government systems that deliver public services, and the financial institutions people trust with their money. Many operate with limited staff and budgets, while defending complex and aging systems,” says OpenAI.

But while critical industry systems are aging, AI is consistently renewing, improving and scaling adversarial attacks. OpenAI believes defenders only have a small window in which to improve defenses before they are overwhelmed by AI-assisted attacks. 

Daybreak for Frontline Defenders is designed to help close the gap between attack and defense while the window remains open. “We are starting where the gap is greatest: with defenders carrying enormous responsibility without the resources of the world’s largest companies. Our goal is to build a model that can protect the services Americans rely on and, with our partners, help put frontier cybersecurity in the hands of frontline defenders around the world,” it explains.

The ability for frontier models to detect vulnerabilities that can then be fixed is not new — to OpenAI’s chagrin the modern security age is often known as the post-Mythos era. The move by OpenAI to make the process easier through an agentic loop is welcome. The announcement, however, goes into few specific details.

“Daybreak for Frontline Defenders brings together $1 billion in subsidized access to frontier cyber capabilities, hands-on training and technical assistance, and new partnerships to get those capabilities to organizations that protect the services people depend on every day,” it announces; but doesn’t clarify exactly what is subsidized, nor the amount of the subsidy in relation to the ultimate unsubsidized cost, nor does it say whether the subsidy for each company is a fixed amount or percentage of the total cost.

Nevertheless, the argument behind the offer is sound: critical industries are especially vulnerable to the increasing scale and sophistication of AI assisted attacks; there is only a short window before our critical industries are in danger of being overwhelmed; and frontier AI power is the best way to reduce the risk.

That alone makes Daybreak for Frontline Defenders an offer worth exploring. “Eligible state and local governments, critical infrastructure operators, nonprofits, open-source maintainers, and supporting organizations can visit the Daybreak website to learn more about access, technical assistance, training, and other cyber-defense support.”

Just be sure you understand the full cost and range after any subsidy before you commit to a lengthy involvement that may go well beyond the subsidized six months, because the announcement gives no indication of actual costs.

Related: OpenAI’s Astra Crosses ‘Critical’ Cyber Threshold After Finding Zero-Days

Related: OpenAI Agents Exploited Linux Kernel Flaw on Company’s Own Systems

Related: OpenAI Agents Coordinated via Makeshift Message Board Ahead of Hugging Face Hack

Related: OpenAI Unveils New Cybersecurity Model GPT-5.6-Cyber

https://www.securityweek.com/openai-pledges-1-billion-to-bring-frontier-ai-to-critical-infrastructure-defenders/

Threat actors have been exploiting a critical-severity vulnerability in the enterprise VoIP telephony management solution Sangoma Switchvox, Horizon3 and CISA warn.

Tracked as CVE-2026-9586 (CVSS score of 9.3) and described as an unauthenticated SQL injection issue, the security defect can be exploited remotely for arbitrary code execution.

It resides in an endpoint that processes XML content, which did not perform sanitization or parameterization when concatenating the user-controlled PhoneIP value into PostgreSQL queries.

“An unauthenticated remote attacker can execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution,” a NIST advisory reads.

On Tuesday, cybersecurity firm Horizon3 warned that threat actors had started exploiting CVE-2026-9586 in the wild and shared indicators of compromise (IoCs) to help organizations identify potential intrusions.

On Wednesday, the US cybersecurity agency CISA added the security flaw to its Known Exploited Vulnerabilities (KEV) catalog along with six other issues, including the JFrog Artifactory bug and two SonicWall SMA1000 zero-days recently flagged as exploited.

The fifth vulnerability added to CISA KEV is CVE-2026-48710, an HTTP request/response smuggling flaw in the lightweight ASGI framework Starlette that was publicly disclosed in May. Hackers have been exploiting it since May, Horizon3 said in early June.

Next in line is CVE-2026-49869, a critical-severity command injection defect in the open source orchestration platform Kestra that was disclosed in June and flagged as exploited by Microsoft last week.

The last vulnerability added to CISA’s KEV list on Wednesday is CVE-2026-59822, a high-severity authentication bypass in LiteLLM. Last week, Wiz said its honeypots caught exploit attempts targeting this bug.

CISA is urging federal agencies to patch these vulnerabilities within three days, except for the Kestra and Starlette flaws, which should be patched within two weeks, in line with BOD 26-04’s recommendations.

Related: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability

Related: Cisco Warns of Unpatched Secure Email Flaws, Patches Critical Switch Vulnerabilities

Related: Exploit Published for Fresh Cleo Harmony Vulnerability

Related: Hackers Start Exploiting Critical Langflow Vulnerability

https://www.securityweek.com/sangoma-switchvox-vulnerabilities-exploited-in-the-wild/

PostgreSQL releases since 2014 contain a severe vulnerability that allows attacker with low privileges to take over databases and servers, cybersecurity firm Cyera reports.

An open source relational database system offering support for both relational (SQL) and non-relational (JSON) queries, PostgreSQL is one of the most popular databases, being used by tens of thousands of companies, including large enterprises.

Tracked as CVE-2026-6471 (CVSS score of 7.2) and referred to as PostGREShell, the recently identified security defect can be exploited for remote code execution and privilege escalation.

It is described as a missing authorization in the database’s logical decoding and can be exploited by attackers that have ‘Replication’ privileges to load any file visible to the OS account running the server, via the logical decoding plugin.

PostgreSQL, Cyera explains, uses a dedicated replication protocol to sync multiple replicas of any primary database, for backup and recovery. An account with the Replication attribute is required for that, and one is provided to any connected backup tool, server, pipeline, and monitoring utility.

Changes are recorded by local replication as table events, so that external tools can read, which they do by creating a logical replication slot and naming an output plugin that is loaded by PostgreSQL to format the stream.

When a plugin is loaded, PostgreSQL runs their init function with the privileges of the server process. To prevent abuse, non-superusers can only load plugins from an admin-controlled directory.

Cyera discovered that the plugin’s name is passed directly to the loader, without validation or sanitization, which allows an attacker to hand the loader a full filesystem path that is served to dlopen(), the C/C++ function used to dynamically load shared libraries.

“The replication protocol’s parser accepts almost any character inside a double-quoted plugin name: slashes, backslashes, dots, ../ traversal, even Windows UNC paths,” Cyera notes.

This allows an attacker to load and execute any file through dlopen(), and the file is executed with the privileges of the postgres system user.

“Code loaded via dlopen() runs in the same address space as PostgreSQL, with no sandbox and no checks on internal API calls. The server simply trusts any code that was loaded,” Cyera explains.

“So the plugin calls an internal function to become the bootstrap superuser for the session, then writes directly to pg_authid, the catalog table that defines who is a superuser, and flips every privilege flag to true,” the company continues.

At this point, the attacker has obtained permanent superuser privileges: they can access every table in every database, execute OS commands, read private keys, and write files to any location the postgres process has access to.

According to Cyera, the plugin can also deploy backdoor mechanisms: it can enable connections without passwords, copies itself to a stable location and registers itself to be re-loaded into every new backend, and can re-apply the superuser change even if it is reverted.

“PostGREShell turns the Replication credential nobody worries about into code execution, superuser, and a persistent backdoor on the database behind much of the internet. Every version from 9.4 through 18 is affected (we confirmed it on 18.2), and logical replication is now standard production plumbing, so the vulnerable path exists almost everywhere PostgreSQL runs,” Cyera notes.

CVE-2026-6471 has been patched in PostgreSQL versions 18.6, 17.11, 16.15, 15.19, and 14.24. Organizations are advised to update their instances as soon as possible, audit their Replication accounts, and remove the Replication attribute from any account that does not need it.

Related: Rockwell Automation Patches Over a Dozen Vulnerabilities Across Products

Related: OpenLeash Adds a Human Check to Risky AI Agent Actions

Related: Threat Actor Hacks 14,000 IP Cameras in Ukraine and Russia

Related: New HollowGraph Malware Abuses Microsoft 365 Calendar for C&C Communication

https://www.securityweek.com/12-year-old-postgresql-vulnerability-enables-database-server-takeover/