TL,DR;
La settimana dal31 agosto al 6 settembre 2026ha un denominatore comune che ormai sta diventando difficile ignorare: tra la pubblicazione di una vulnerabilità e il suo sfruttamento reale passa sempre meno tempo. A volte ore. In altri casi, come per JFrog Artifactory, gli attaccanti hanno iniziato a creare token amministrativi pochi giorni dopo la patch. Nel frattempo Google ha dovuto chiudere una nuova zero-day di Chrome già utilizzata sul campo e Magento/Adobe Commerce si è ritrovato, proprio nel weekend, con uno zero-day senza patch mentre negozi reali venivano già compromessi.
Anche il bersaglio sta cambiando. Non interessa più soltanto entrare nel computer dell'utente: conviene prendere il controllo dei sistemi che distribuiscono software, dei browser che utilizziamo per raggiungere tutto il resto e dei server che incassano pagamenti. Colpire uno di questi nodi equivale a entrare in autostrada invece di cercare ogni volta una strada secondaria.
In Italia il rumore maggiore arriva invece dal phishing. I numeri CERT-AGID sono tutt'altro che marginali:137 campagne malevole analizzate tra il 29 agosto e il 4 settembre, 110 delle quali specificamente rivolte a obiettivi italiani. Rimborsi, multe e banking dominano le esche, mentre CSIRT Italia ha chiuso la settimana con un alert critico su router MikroTik già sfruttati in rete. Non abbiamo quindi un singolo grande data breach nazionale a monopolizzare la scena: abbiamo qualcosa di forse più quotidiano, una pressione continua che prova a entrare da decine di porte diverse.
Chrome: la sesta zero-day dell'anno arriva direttamente dentro V8
Partiamo con uno dei software più diffusi a livello mondiale per la navigazione internet:Google Chrome.
Il 3 settembre Google ha distribuito Chrome152.0.7977.82/.83per Windows e macOSe152.0.7977.82per Linux, correggendo dodici vulnerabilità di sicurezza. Una di queste,CVE-2026-85046, non era però una semplice voce in un changelog: Google ha confermatoche un exploit esiste giàed è attivamente sfruttato.
La vulnerabilità è una "type confusion" nel motore V8, il componente che Chrome utilizza per eseguire JavaScript e WebAssembly. In pratica, il software può essere indotto a interpretare una struttura in memoria come se appartenesse a un tipo diverso da quello reale. Sembra untecnicismo da nerddettaglio da sviluppatori, ma il risultato può essere molto meno astratto e difficile da capire: corruzione della memoria e possibilità per un attaccante di arrivare all'esecuzione di codice all'interno del renderer sandboxed di Chrome attraverso una pagina HTML costruita appositamente.
Google non ha pubblicato dettagli sull'exploitation reale, scelta normale mentre l'aggiornamento deve ancora raggiungere gran parte degli utenti. Non sappiamo quindi chi stia sfruttando la falla, contro quali bersagli e se CVE-2026-85046 venga concatenata con una seconda vulnerabilità per uscire dalla sandbox del browser.
La vulnerabilità CVE-2026-85046, presa da sola, permette a un attaccante di ottenere capacità di esecuzione all'interno dell'ambiente isolato di Chrome, manon equivale automaticamente al controllo completo del computer. Per superare la sandbox del browser è normalmente necessaria una seconda vulnerabilità. È proprio ciò che è stato osservato nella catena di exploitBlueMoon: CVE-2026-85046 veniva utilizzata per ottenere l'accesso iniziale nel motore V8, quindi combinata conCVE-2026-87491, una falla specifica per la sandbox escape, e conCVE-2026-85880in Windows per aumentare ulteriormente i privilegi. In altre parole, la zero-day di Chrome rappresenta il primo anello di una catena che, se completata con vulnerabilità aggiuntive, può arrivare ben oltre il browser e consentire l'esecuzione di codice sul sistema attaccato.
Ed è già lasesta vulnerabilità Chrome sfruttata attivamente corretta da Google nel 2026. Il dato racconta quanto i browser siano diventati appetibili: oggi dentro una scheda passano posta, cloud aziendale, home banking, password manager, gestionali e console amministrative. Il browser non è più la finestra sul computer. In molti ambienti è praticamente il computer.
La mitigazione è banale solo in apparenza: aggiornare e riavviare realmente Chrome, perché finché il browser resta aperto la nuova versione potrebbe non essere caricata. Attenzione anche a Edge, Brave, Opera e Vivaldi: condividendo Chromium, dovranno integrare le correzioni nei rispettivi aggiornamenti.
Fonti:
Google Chrome Releases — Stable Channel Update for Desktop
BleepingComputer — Google warns of new Chrome zero-day flaw exploited in attacks
The Hacker News — Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day
JFrog Artifactory: da bug pubblicato a token amministrativi in pochi giorni
ConJFrog Artifactorysi passa dal browser direttamente alla supply chain del software (tanto per cambiare, aggiungerei).
La vulnerabilitàCVE-2026-82329, conCVSSdi9.8, riguarda il sistema di autenticazione di Artifactory e in determinate configurazioni predefinite permette a un attaccante non autenticato con accesso di rete all'istanza, di ottenere privilegi amministrativi. La patch è arrivata il28 agostocon Artifactory 7.161.20 e release corrette per i rami precedenti.
Il primo settembre, però, watchTowr stava già osservando attacchi reali.
Il problema ruota attorno a JFrog Access, il componente che gestisce e convalida credenziali e token. Nelle istanze prive di una join key aggiuntiva può essere presente una sorta di chiave “fantasma” sfruttabile per forgiare credenziali egenerare token con privilegi amministrativi.
Gli attaccanti osservati non si sono limitati a verificare se la vulnerabilità funzionasse. In alcuni casi hanno enumerato utenti, gruppi, token e topologie federate; in un numero limitato di episodi sono stati creati anche account backdoor. Non risultava ancora un'attività di sfruttamento massiva, ma il salto dalla disclosure alla weaponization è stato praticamente immediato.
Ed è qui che il problema diventa più grande di Artifactory.
Un repository software aziendale contiene binari, pacchetti e componenti che sviluppatori e pipeline CI/CD trattano come affidabili. Se un attaccante ne prende il controllo amministrativo, non ha necessariamente bisogno di assaltare ogni singola macchina:può tentare di avvelenare ciò che quelle macchine scaricheranno domani.
La risposta deve quindi andare oltre l'aggiornamento. Le installazioni self-managed esposte durante la finestra di rischio dovrebbero controllare i log, verificare la comparsa di nuovi utenti e token, ruotare le credenziali potenzialmente esposte e controllare i sistemi collegati alla repository.
Una supply chain compromessa ha una caratteristica particolarmente sgradevole: la patch chiude la porta, ma non dice chi sia eventualmente entrato prima e, potenzialmente, sia ancora dentro.
Fonti:
The Hacker News — Attackers Exploit Critical JFrog Artifactory Flaw to Mint Admin Tokens Days After Disclosure
JFrog — Artifactory Self-Managed Releases
Magento e Adobe Commerce: lo zero-day arriva prima della patch
La terza notizia è quella che, alla chiusura di questa CyberWeek, resta più "in divenire".
Il 5 settembre la società olandese Sansec ha pubblicato i dettagli preliminari diStyleSmuggler, una vulnerabilità zero-day che interessa Magento Open Source e Adobe Commerce e che permette a un attaccantenon autenticato di arrivare alla remote code execution.
La parte peggiore è che gli attacchi erano già iniziati il giorno prima, il 4 settembre.
StyleSmuggler sfrutta il sistema dei template Magento per inserire codice PHP attraverso le proprietà styles, aggirando le protezioni esistenti. L'attacco avviene in due fasi: prima viene “avvelenato” il sistema inserendo il PHP, per esempio attraverso la generazione di un failure report; successivamente Magento viene portato a eseguire quel codice durante l'elaborazione di una mail relativa a un pagamento fallito.
Sansec ha riprodotto la catena completa senza autenticazione su installazioni pulite2.4.7, 2.4.8 e 2.4.9. Una delle prime vittime utilizzava 2.4.6-p15 con le patch di luglio e agosto già applicate.Alla sera del 6 settembre Adobe non aveva ancora pubblicato una patch ufficiale o un CVE specifico per StyleSmuggler.
Una compromissione permette di installare una backdoor persistente sul server. E su un e-commerce quel server non gestisce soltanto pagine HTML: vive accanto a account clienti, ordini, integrazioni di pagamento e sistemi aziendali.
Sansec suggerisce temporaneamente di disabilitare GraphQL in assenza della propria mitigazione commerciale e, soprattutto, di cercare segni di compromissione invece di aspettare passivamente la patch. Il prossimo aggiornamento Adobe era previsto per l'8 settembre, ma al momento non è confermato che includerà questa falla.
Questa è quindi una delle rare situazioni nelle quali la risposta corretta è:non abbiamo ancora tutti i pezzi. Ma quelli disponibili sono già sufficienti per non rimandare l'analisi delle installazioni esposte.
Fonti:
Sansec — StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack
The Hacker News — Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores
Focus Italia
PagoPA e il falso rimborso TARI: 95 euro come esca per prendere tutto il resto
In Italia la storia più rappresentativa della settimana parte da una cifra: 95 euro.
CERT-AGIDha individuato una nuova campagna di phishing che replica nome, logo e grafica diPagoPAe comunica alla vittima un presunto rimborso per un pagamento TARI effettuato in eccesso. Non migliaia di euro, non una fantomatica vincita ol principe nigeriano che vuole regalarti milioni: una cifra abbastanza modesta da sembrare una normale rettifica fiscale.
La pagina mostra perfino una pratica relativa al 2025 e indica come data del presunto pagamento in eccesso il 28 agosto 2026. Poi procede per gradi. Prima chiede codice fiscale o numero della carta d'identità, quindi nome, indirizzo completo, telefono ed email. Alla fine arriva dove voleva arrivare fin dall'inizio: numero della carta di credito, scadenza eCVV.
È un phishing ben costruito perché non parte chiedendo immediatamente il dato più prezioso. Accompagna l'utente dentro una procedura che assomiglia progressivamente a un vero iter amministrativo.
La campagna non è nemmeno isolata. Nel riepilogo CERT-AGID della settimana, il tema“Rimborso” compare in 41 campagne italiane, principalmente contro Agenzia delle Entrate e PagoPA; altre 33 campagne sfruttano invece false multe utilizzando identità visive di SEND, PagoPA e, in misura minore, Polizia di Stato.
CERT-AGID ha avviato il takedown dei domini individuati e condiviso gli IoC con gli enti accreditati.
Per il cittadino vale una regola molto semplice: un ente che deve restituirci denaronon ha bisogno nè del numero di carta di credito tantomeno del CVV della nostra carta.
E' un sistema molto utilizzato, che ho verificato personalmente perchè successo ad un amico su un noto sito di vendite online. L'acquirente, utilizzando email che somigliavano a quelle legittime del sito ma non lo erano, inviava link a form compilabili per "concludere la vendita" e che, ad un tratto, chiedevano i dati della CC.
Inizialmente, lo ammetto, uno potrebbe cascarci, pensando che il rimborso venga "accreditato" sul credito residuo della carta, ma ovviamente non è così.
Se tu devi soldi a me, non devo dartiIOi dati della CC, casomai tu devi darli a me. Se quella schermata compare, la pratica può finire lì.
Fonti:
CERT-AGID — Falso rimborso TARI sfruttato nelle nuove campagne di phishing ai danni di PagoPA
CERT-AGID — Sintesi delle campagne malevole dal 29 agosto al 4 settembre
Banking italiano: banche vere, APK falsi e malware Android
Dietro i rimborsi c'è però un secondo fronte che questa settimana merita di essere menzionato: quello bancario.
CERT-AGID ha rilevato13 campagne di phishing italiane a tema bankingrivolte, tra gli altri, ai clienti di Banca Ifis, Intesa Sanpaolo, Fineco, Inbank e Klarna. Gli stessi temi vengono inoltre sfruttati per distribuire malware Android come BingoMod, Copybara e StreamRat.
Qui l'attacco cambia pelle: in alcune campagne l'obiettivo resta la pagina falsa che raccoglie le credenziali. In altre il messaggio contiene invece un link per scaricare unAPK malevolo, cioè un'app Android installata fuori dal normale circuito dello store. Il nome della banca e l'urgenza del messaggio servono soltanto a convincere la vittima che quell'applicazione sia davvero uno strumento di sicurezza o aggiornamento.
CERT-AGID ha osservato una campagna italiana Copybara e campagne BingoMod e StreamRat distribuite proprio attraverso SMS con link al download degli APK. Nel frattempo continuano anche i classici infostealer Windows: Remcos, AgentTesla, FormBook, XWorm, Grandoreiro e MassLogger compaiono tra le dieci famiglie individuate durante la settimana.
Il dato più interessante, però, è quello complessivo:137 campagne in sette giorni, di cui 110 mirate specificamente all'Italia, e1.092 indicatori di compromissione prodottie distribuiti dal CERT.
Non c'è quindi “la campagna della settimana” da bloccare e dimenticare. C'è una fabbrica che cambia continuamente logo, dominio, allegato e pretesto.
Su Android la misura più efficace rimane impedire agli utenti di installare APK provenienti da link ricevuti via SMS o messaggistica. Una banca non distribuisce l'aggiornamento della propria app attraverso un file scaricato da un dominio casuale.
Da notare che, di default, uno smartphone android ha l'opzione di installazione da fonti non certificate disabilitata quindi, se non avete toccato nulla, non dovrebbe installare l'APK malevolo.
Se invece, come me, avete abilitato quell'opzione ... beh ... (a meno che non ci fosse un motivo valido e che sapeste bene cosa stavate facendo) non dovevate! Rimettete tutto com'era prima e nessuno si farà male!
MikroTik: CSIRT Italia alza l'alert mentre gli attacchi sono già in corso
L'ultima notizia arriva praticamente sulla linea del traguardo della settimana.
Il6 settembreCSIRT Italia ha pubblicato un alert critico relativo a nuove vulnerabilità MikroTik dopo l'osservazione disfruttamento attivo in rete. Il produttore di router ed apparati di rete ha rilasciato aggiornamenti per sei vulnerabilità, due classificate critiche e due ad alta gravità.
L'attività descritta anche da CERT Polska riguarda router con il servizioSSH esposto direttamente su Internet. In determinate versioni vulnerabili di RouterOS, gli attaccanti possono ottenere il controllo amministrativo del dispositivosenza autenticazione. Gli attacchi confermati risalgono almeno al 2 settembre. Al momento non sono stati resi pubblici né un numero di vittime né un'attribuzione affidabile degli operatori.
Un router compromesso è un bersaglio particolarmente comodo. Non contiene necessariamente il documento interessante o il database da rubare, ma vede passare il traffico e occupa una posizione perfetta per diventare proxy, infrastruttura di attacco o punto dal quale muoversi verso la rete interna.
C'è una distinzione importante per non creare allarmismo inutile: i dispositivi MikroTik domestici confirewall predefinito ancora correttamente configurato bloccano normalmente l'accesso pubblico alle porte di management. Il rischio cresce soprattutto quando SSH o altri servizi amministrativi sono stati esplicitamente aperti verso Internet.
La risposta indicata da CERT e dal vendor è aggiornare RouterOS alle release corrette e, successivamente, verificare la configurazione alla ricerca di utenti, chiavi, regole firewall, script o modifiche non autorizzate. Se SSH deve essere disponibile da remoto, dovrebbe essere limitato a IP affidabili o, ancora meglio, raggiungibile attraverso una VPN.
Perché una patch installata oggi chiude l'exploit. Non cancella automaticamente le modifiche fatte ieri.
Fonti:
ACN/CSIRT Italia — MikroTik: rilevato sfruttamento in rete di nuove vulnerabilità
The Hacker News — Attackers Hijack MikroTik Routers Through Internet-Exposed SSH Without Authentication
Tanto per chiudere...
Chrome, Artifactory, Magento, PagoPA, le app bancarie e MikroTik non hanno praticamente nulla in comune dal punto di vista tecnologico. Eppure raccontano tutti la stessa trasformazione.
Gli attaccanti cercano sempre più spesso un punto di fiducia da trasformare in un acceleratore.
Se il browser è vulnerabile, basta una pagina. Se il repository software è compromesso, la supply chain può distribuire il problema al posto dell'attaccante. Se cade l'e-commerce, il criminale entra nel punto nel quale utenti e denaro si incontrano. Se la pagina imita PagoPA o la banca corretta, è la fiducia del cittadino a completare l'attacco. Se cade il router, l'avversario si ritrova direttamente sul confine della rete.
E soprattutto la finestra per reagire continua a restringersi: JFrog è passato dalla patch allo sfruttamento osservato in pochi giorni; StyleSmuggler era già utilizzato contro Magento prima ancora che esistesse una correzione ufficiale;Chrome è stato aggiornato perché l'exploit era già sul campo.
Forse è proprio questa la lezione più utile della prima CyberWeek di settembre: non basta più avere un processo di patching. Serve avere un processo di patching capace di cambiare velocità,perché gli attaccanti, quella velocità, l'hanno già cambiata.
E soprattutto servenon fidarsi mai e controllare sempre due volte. Perchè, devo ammetterlo, in alcuni casi è difficile capire al volo che si tratta di qualcosa di pericoloso e, con quanto siamo "immanicati" nella rete al giorno d'oggi, il rischio è altissimo.
À la prochaine!
M.