Cosa è successo

Il 19 ottobre 2026 la società di ricerca NorForge ha pubblicato un'analisi di Snorre Fagerland su una campagna d'attacco condotta quasi interamente da agenti di intelligenza artificiale. Lo strumento è Cairn, una piattaforma open source nata come supporto ai penetration test autorizzati: all'utente basta indicare un bersaglio e un obiettivo, e il sistema assegna agenti AI che lavorano passo dopo passo, condividendo i risultati su una bacheca comune a cui l'operatore umano può aggiungere suggerimenti.

Il ricercatore ha individuato, a partire dal 2 ottobre, molte interfacce di controllo di Cairn lasciate esposte su Internet (spesso sulla porta 8000, senza autenticazione). Più di venti pannelli sono stati giudicati verosimilmente malevoli. Il gruppo principale, in lingua cinese, comprende 14 pannelli e oltre 1.100 progetti d'attacco rivolti a negozi online in Stati Uniti, Canada, Giappone e Australia; l'obiettivo era installare web shell di tipo uploader per mantenere un accesso duraturo ai sistemi dello shop e dei pagamenti. Un secondo gruppo in lingua inglese aveva come istruzioni il furto di carte di credito e criptovalute. Secondo le inchieste riportate da Reuters, gli agenti hanno tentato più di 1.200 siti e raggiunto i siti web di oltre 100 aziende; fra i nomi citati ci sono Deere, SharkNinja e Cummins, con livelli di impatto molto diversi (Deere e SharkNinja parlano di danni limitati e contenuti, Cummins di un'indagine su un sito gestito da un fornitore).

I numeri vanno letti con cautela. Il tasso di successo medio è stimato intorno al 10%, con attacchi riusciti che richiedevano in media poco meno di 23 ore; i costi sono stime con ampia incertezza: circa 5 dollari per task, tentativi falliti inclusi, e circa 5.000 dollari di token complessivi, cioè all'incirca 50 dollari per intrusione riuscita. Non è stato stabilito quanti dati siano stati effettivamente sottratti, le intrusioni non sono state tutte verificate in modo indipendente e il modello usato è solo ipotizzato: il nome del worker ("claudecode_deepseek-v4.1-flash") suggerisce uno strumento di coding agentico abbinato a un modello DeepSeek, ma nessuna delle due società lo ha confermato. L'autore di Cairn, che si firma le1xia0, ha dichiarato che lo strumento non è progettato per attaccare. Va inoltre ricordato che a settembre un'altra analisi (Gambit Security) ha descritto un uso di Cairn per rubare carte di credito: nessuna fonte collega le due operazioni.

Come hanno funzionato gli attacchi

I percorsi variavano da vittima a vittima. In un caso documentato la catena univa l'accesso in scrittura non autorizzato a un archivio di sessioni memcached, la gestione non sicura di oggetti PHP serializzati e una debolezza in vecchio codice Zend Framework. In un altro, gli agenti, non trovando falle nell'applicazione pubblica di una grande azienda, hanno individuato un pannello di controllo collegato e, dopo ore di tentativi, sono riusciti a far eseguire comandi al suo server. In un terzo, una singola impostazione di un cookie bastava a selezionare un server di backend vulnerabile.

La parte più rilevante per chi difende è l'asimmetria di costo: l'operatore avrebbe dato istruzioni in meno di cento caratteri cinesi, e gli agenti hanno fatto il lavoro di ricognizione e prova che prima richiedeva ore di un operatore esperto. Non c'è una tecnica nuova; c'è un abbassamento drastico del costo di applicare tecniche note, in particolare a quelle superfici che finora erano troppo poco interessanti per essere attaccate una a una: vecchi plugin, pannelli secondari, siti di supporto prodotto, applicazioni PHP non aggiornate.

C'è poi un'ironia utile da ricordare: gli stessi pannelli esposti hanno rivelato centinaia di credenziali e chiavi API (circa l'11% di quelle verificate con Trufflehog risultava ancora valido) e, in alcuni casi, test reali di società di sicurezza legittime. Anche chi fa offensive security è esposto agli stessi errori di igiene che dovrebbe cercare nei clienti.

Cosa significa per le aziende italiane

Le vittime citate sono perlopiù nordamericane e asiatiche, e non ci risultano casi italiani confermati. Sarebbe però un errore concluderne che il tema non ci riguardi: l'e-commerce italiano è fatto in larga parte di PMI con piattaforme (Magento/Adobe Commerce, WooCommerce, PrestaShop), plugin e temi mantenuti da agenzie esterne, spesso con stack PHP datati. Sono esattamente i bersagli che, con attacchi automatizzati a basso costo, diventano convenienti anche se il singolo guadagno è piccolo.

Il cambio di paradigma riguarda il modello di minaccia. Fino a ieri una PMI poteva ragionare "non sono abbastanza interessante"; con un costo per tentativo di pochi dollari e nessuna fatica umana, la selezione dei bersagli non avviene più per interesse ma per raggiungibilità. Un negozio con un sito di supporto dimenticato o un pannello di staging esposto è nella stessa lista di una multinazionale.

Altro punto concreto: la catena di fornitura web. Nei casi citati l'ingresso è avvenuto a volte da un sito gestito da un fornitore o da un sito standalone di supporto prodotto, non dall'applicazione principale. Per un'azienda italiana, il perimetro da governare include i siti e i domini marginali, le landing page di campagna, gli ambienti di test e quelli gestiti dall'agenzia.

Contesto normativo

Un web shell su un sito e-commerce che gestisce dati di clienti è, in genere, una potenziale violazione di dati personali: il GDPR impone la valutazione e, se c'è rischio, la notifica al Garante entro 72 ore dalla scoperta (art. 33). Per chi tratta pagamenti con carte resta l'obbligo contrattuale PCI DSS, con requisiti specifici su monitoraggio dell'integrità degli script. I soggetti NIS2 devono inoltre dimostrare misure di gestione delle vulnerabilità e di sicurezza della catena di fornitura: un inventario delle superfici esposte e un processo di patching documentato sono la prima evidenza richiesta in un audit. Nessuna norma, per ora, tratta in modo specifico gli attacchi condotti da agenti AI: gli obblighi sono quelli di sempre, ma i tempi di reazione attesi si accorciano.

Cosa fare subito

  • Fare un inventario completo di tutto ciò che è raggiungibile da Internet, compresi sottodomini, ambienti di staging, siti di supporto e pannelli di amministrazione; chiudere o proteggere con autenticazione e VPN ciò che non serve in pubblico.
  • Cercare pannelli di agenti AI e strumenti di orchestrazione esposti (spesso sulla porta 8000, privi di autenticazione), anche quelli installati per sperimentazione interna.
  • Cercare form di upload inattesi, soprattutto in directory nascoste, e file PHP recenti o modificati nelle cartelle di upload: erano il punto di appoggio previsto dall'attacco.
  • Verificare che memcached e gli store di sessione non siano raggiungibili dall'esterno e non accettino scritture non autenticate; rivedere la deserializzazione di oggetti PHP e rimuovere il codice legacy non più mantenuto (ad esempio vecchie librerie Zend Framework).
  • Per chi usa Adobe Commerce o Magento Open Source, applicare gli hotfix Adobe, compresa la correzione per la CVE-2026-75650 (StyleSmuggler); la fonte precisa che non ci sono evidenze di un suo uso in queste intrusioni.
  • Eseguire una scansione dei segreti (ad esempio con Trufflehog) su repository e file di configurazione e ruotare chiavi e credenziali trovate.
  • Se si usano agenti AI per i test, trattarli come sistemi di produzione: autenticazione sui pannelli, segreti fuori dai progetti, log e accesso limitato.
  • Aggiornare il piano di risposta agli incidenti: se la scoperta e lo sfruttamento si misurano in ore, la finestra tra pubblicazione di una patch e applicazione deve ridursi di conseguenza.