TL;DR
Ci sono settimane "tranquille" (ammesso che si possa definire tale la sicurezza informatica...) in cui la cybersecurity sembra stagnante: qualche vulnerabilità, una manciata di attacchi ransomware, il solito phishing e qualche aggiornamento da installare.
Poi arrivano settimane come questa, che somigliano ad un tornado nelle Great Plains, nelle qualidue vulnerabilità nel cuore di PHP costringono mezzo mondo a controllare urgentemente i propri server, mentre gli attaccanti cominciano a cercare di sfruttarle ancora prima che le correzioni siano disponibili.
PHP2Shell è inevitabilmente la protagonista degli ultimi sette giorni. La portata e le conseguenze sono state decisamente notevoli, ma sarebbe un errore fermarsi lì.
Anche GitLab ha corretto una vulnerabilità con punteggio massimoCVSS 10.0, mentre Arista ha confermato lo sfruttamento attivo di una falla critica nei sistemi di gestione delle reti SD-WAN. Tre notizie apparentemente diverse, ma con una caratteristica comune: colpiscono componenti che spesso lavorano dietro le quinte, ma dai quali dipende il funzionamento di intere infrastrutture.
In Italia, intanto, il CERT-AGID ha analizzato202 campagne malevole tra il 17 e il 23 ottobre, individuando 1.460 indicatori di compromissione. Sul fronte degli incidenti, il gruppo ransomware Qilin ha rivendicato un attacco contro Coop Italia, mentre diversi collettivi hacktivisti hanno dichiarato offensive contro aeroporti, operatori logistici e portali istituzionali. Il quadro è movimentato, ma richiede attenzione nel distinguere gli attacchi verificati dalle semplici rivendicazioni e dai millantatori.
PHP2Shell: quando una vulnerabilità diventa pubblica prima che sia pronta la patch
La notizia più importante della settimana comincia con un problema di cuiho parlato in un articolo apposito, perchè se lo meritava tutto!
La situazione, per chi gestisce server Web, rappresenta uno degli scenari peggiori:sapere che esistono vulnerabilità critiche, scoprire che alcuni dettagli sono già circolati pubblicamente e non avere ancora una patch disponibile.
Il 21 ottobre il PHP Security Team ha distribuito aggiornamenti straordinari per correggereCVE-2026-109618 e CVE-2026-109619, due vulnerabilità valutate CVSS 9.2 secondo la versione 4.0 dello standard.
Entrambe riguardano la gestione della memoria nel motore PHP e possono consentire, in determinate condizioni, l'esecuzione remota di codice senza autenticazione.
La prima sfrutta problemi legati alla gestione delle condizioni di esaurimento della memoria. La seconda riguarda l'utilizzo di strutture di memoria dopo che queste sono state liberate, una classe di vulnerabilità conosciuta comeUse-After-Free.
Il dettaglio più preoccupante è chel'attacco può avvenire prima ancora che venga eseguito il codice dell'applicazione Web. Non è quindi necessariamente un plugin WordPress vulnerabile o una pagina sviluppata male a creare il problema: il difetto può trovarsi nel motore PHP stesso. Non servono a nulla (o meglio, servono ma non per sanare questa falla) gli aggiornamenti di WP o di qualsiasi altroCMSvoi stiate utilizzando. Il "buco" sta più in alto ancora!
E proprio WordPress, Drupal e Joomla rendono immediatamente comprensibile la portata della notizia. PHP è utilizzato da una parte enorme del Web e moltissime organizzazioni dipendono da questo linguaggio senza occuparsi direttamente della sua manutenzione, perchè hanno siti hostati altrove oppure, semplicemente, perchè non stan dietro al server web come si dovrebbe.
Ma la vicenda è diventata ancora piùuna pigna nel cu...interessante il 22 ottobre.
Amazon Threat Intelligence ha comunicato di aver osservato tentativi di sfruttamento già il17 ottobre, quattro giorni prima della pubblicazione delle patch. Anche Cloudflare ha rilevato attività offensive, con richieste che venivano progressivamente modificate per cercare di aggirare le protezioni.
Questo non significa che milioni di server siano stati compromessi. Le evidenze pubbliche documentano soprattuttotentatividi sfruttamento, mentre il numero delle intrusioni effettivamente riuscite rimane sconosciuto.
Significa però che qualcuno stava già cercando di approfittare delle vulnerabilità mentre gli sviluppatori lavoravano ancora alle correzioni. E vai a sapere, se sono entrati, cosa possono aver combinato.
Le versioni PHP corrette sono8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i rami precedenti occorre verificare eventuali correzioni distribuite dal fornitore oppure pianificare la migrazione.
E la storia non finisce qui.
Il 23 ottobre è emersa una terza vulnerabilità,CVE-2026-115560, legata alla gestione delle sessioni. Anche questa potrebbe consentire RCE, ma soltanto in una combinazione poco comune di configurazione e comportamento applicativo. Non dispone ancora di una patch e il team PHP raccomanda, nei sistemi interessati, di disabilitaresession.upload_progress.enabled.
Per gli amministratori la priorità è aggiornare PHP, verificare la versione realmente utilizzata dal server e analizzare i log anche nei giorni precedenti al 21 ottobre.
Perchéinstallare una patch impedisce nuovi sfruttamenti della falla corretta, ma non cancella un'eventuale intrusione già avvenuta.
C'è un aggiornamento italiano importante che va riportato:il 25 ottobre CERT-AGID ha pubblicato i risultati della prima ricognizione sugli indirizzi censiti nell'Indice delle Pubbliche Amministrazioni (IPA).
Sono stati individuati650 URL che dichiaravano una versione PHP potenzialmente vulnerabile, pari al 3,2% degli indirizzi raggiungibili esaminati.
Il controllo è stato passivo: non dimostra che quei server fossero effettivamente sfruttabili, anche perché potrebbero essere state applicate correzioni tramite backport. CERT-AGID dice che le amministrazioni interessate sono state avvisate.
E qui uno dice "Vabè, il 3,2% non è un granchè, giusto?".
Sbagliato!
Se guardate il grafico nel link, il dato allarmante, per me, è l'89,8% con "Esito non conclusivo".
Certo, potrebbero essere server che non espongono la versione di PHP (ed è cosa buona), ma non è che non esporla mette al sicuro. L'attaccante potrebbe provarci ugualmente, anzi, ci proverà.
A rigor di logica, quell'89% io devo trattarlo come "non sicuro". Ed è questo che dovrebbe preoccupare, non il 3,2% di cui siamo certi e che possiamo trattare adeguatamente.
Analisi siti IPA di cert-agid
Fonti:
Zeus News — PHP in emergenza, falle critiche costringono milioni di siti a un aggiornamento immediato
PHP — Security advisory e aggiornamenti di ottobre 2026
BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws
BleepingComputer — Amazon says PHP2Shell exploitation began 4 days before patches
BleepingComputer — PHP shares mitigation for new RCE vulnerability with no patch
GitLab, CVSS 10.0: quando il server che custodisce il codice diventa il bersaglio
Se PHP2Shell mette in pericolo il motore di milioni di applicazioni Web, la seconda notizia colpisce un componente altrettanto delicato:il sistema che custodisce il codice sorgente e gestisce lo sviluppo del software.
Il 21 ottobre GitLab ha pubblicato un aggiornamento straordinario per correggere diverse vulnerabilità. La più grave,CVE-2026-110264, ha ricevuto il punteggio massimo: CVSS 10.0.
Il problema è uninteger overflownel compilatore delle espressioni regolari utilizzato da GitLab.
In determinate condizioni, un attaccante remoto non autenticato potrebbe inviare un'espressione regolare appositamente costruita e arrivare all'esecuzione di codice arbitrario sul server.
Non è difficile capire perché sia una situazione delicata.
Un'istanza GitLab aziendale può contenere repository privati, configurazioni CI/CD, informazioni sui progetti e riferimenti a sistemi di distribuzione. Una sua compromissione potrebbe quindi diventare il punto di partenza per attacchi molto più estesi.
Inoltre, GitLab viene normalmente preferito da aziende che vogliono gestirsi un "GitHub privato" self-hosted, normalmente per motivi di privacy e policy sulla riservatezza dei sorgenti contenuti.
Una violazione di un repository di questo genere (che, magari, è pure pubblico su internet per interoperabilità tra sedi differenti), diventa rapidamente un disastro!
È importante, però, distinguere il rischio potenziale dai fatti osservati:non risultano conferme pubbliche di sfruttamento attivo di questa specifica vulnerabilità.
GitLab ha distribuito le correzioni nelle versioni19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13.
Le istanze GitLab.com risultano già aggiornate, mentre chi utilizza installazioni self-managed deve intervenire direttamente (e velocemente, aggiungerei...).
L'aggiornamento corregge anche altri problemi, tra cui una vulnerabilità nei meccanismi di associazione tra autenticazione OmniAuth e LDAP, che in particolari configurazioni avrebbe potuto consentire l'acquisizione di account esistenti.
Per chi gestisce GitLab internamente, quindi, il lavoro non dovrebbe fermarsi alla verifica del numero di versione. Già che ci siamo, conviene controllare anche i log applicativi, gli accessi amministrativi e le eventuali anomalie nei processi CI/CD.
Fonti:
GitLab — Critical Patch Release del 21 ottobre 2026
BleepingComputer — GitLab warns of new max severity code execution vulnerability
Arista VeloCloud: una SQL Injection permette di diventare superuser
E qui torniamo a delle "vecchie glorie" che, però sono sempre attuali: una vulnerabilità che non ha bisogno di presentazioni particolarmente elaborate per far suonare un campanello d'allarme ovverouna SQL Injection nel sistema di gestione delle reti aziendali, già sfruttata attivamente.
Il 22 ottobre Arista Networks ha pubblicato un advisory relativo aCVE-2026-114625, vulnerabilità critica di VeloCloud Orchestrator nelle installazioni on-premises.
Il punteggio èCVSS 9.9 secondo la versione 3.1, oppure 9.4 secondo CVSS 4.0.
VeloCloud Orchestrator è il portale utilizzato per configurare e monitorare infrastrutture SD-WAN. Tradotto, uno dei punti dai quali gli amministratori possono controllare collegamenti e apparati distribuiti tra sedi aziendali.
La vulnerabilità permette a un utente già autenticato, anche con privilegi molto limitati, di ottenere funzionalità riservate agli operatori amministrativi e impersonare un superuser locale.
Non male eh!
Ma, calma... non si tratta di una falla sfruttabile completamente senza credenziali:serve una sessione autenticata valida e l'accesso all'interfaccia Web dell'orchestratore.
Non così semplice, quindi, anche se il livello minimo richiesto è quello di un normale utente con privilegi di sola lettura.
Ed è proprio questo il problema.
Un account apparentemente poco pericoloso può trasformarsi nella chiave per controllare funzionalità che dovrebbero rimanere accessibili soltanto agli amministratori.
Arista ha confermato che la vulnerabilità è già stata sfruttata in attacchi reali e ha pubblicato indicatori utili per cercare attività sospette.
Le versioni corrette sono5.2.3.18, 6.1.3.10 e 6.4.2.12, o successive nei rispettivi rami. Gli ambienti hosted interessati sono già stati aggiornati dal fornitore.
In attesa delle correzioni, Arista raccomanda di limitare l'accesso all'interfaccia Web alle reti amministrative fidate e di controllare le attività recenti degli account privilegiati. (anche qui, mi sento di dire "Come mai non era stato fatto, comunque, prima?")
È una lezione che torna spesso, collegata ad una falla "classica" che ci riporta ai bei tempi passati: quando un sistema centralizza la gestione di molti dispositivi,la compromissione della console di amministrazione è più pericolosa della compromissione di un singolo apparato.
Fonti:
Arista Networks — Security Advisory 0199, CVE-2026-114625
BleepingComputer — Arista patches new VeloCloud Orchestrator zero-day exploited in attacks
Coop Italia nel mirino di Qilin: rivendicato il furto di 250 GB di dati
La notizia italiana più delicata (e potenzialmente controversa) della settimana riguardaCoop Italia, il consorzio nazionale che svolge funzioni commerciali e di coordinamento per le cooperative di consumatori.
Il 23 ottobre il gruppo ransomware Qilin ha inserito Coop Italia tra le proprie presunte vittime, sostenendo di aver sottratto circa250 GB di documentazione aziendale.
Secondo la rivendicazione, il materiale comprenderebbe contratti commerciali, informazioni sulle vendite, documenti finanziari, presentazioni interne e altri file riservati.
Attenzione però:al 25 ottobre non risultano conferme indipendenti dell'effettiva compromissione dei sistemi di Coop Italia.
La rivendicazione è stata rilevata da diverse piattaforme di monitoraggio ransomware, ma questo conferma soltanto che il gruppo criminale ha pubblicato quelle affermazioni, non che siano vere.
Soprattutto in un mondo in cui le notizie vengono copiaincollate da un sito all'altro senza fare un minimo di verifica.
Anche il volume dei dati dichiarato dagli attaccanti rimane da verificare.
La vicenda merita comunque attenzione per due motivi.
Il primo è la dimensione nazionale dell'organizzazione coinvolta. Coop Italia svolge attività centrali nella negoziazione con i fornitori, nello sviluppo dei prodotti a marchio Coop e nella gestione di informazioni commerciali che potrebbero avere un valore significativo.
Il secondo è il gruppo che ha pubblicato la rivendicazione.
Qilin opera attraverso il modelloRansomware-as-a-Service, nel quale sviluppatori e affiliati collaborano per condurre attacchi e monetizzare le intrusioni.
Le sue campagne precedenti hanno spesso combinato sottrazione di informazioni e minaccia di pubblicazione, una tecnica conosciuta come doppia estorsione.
Questo, però,non dimostra che le stesse tecniche siano state utilizzate contro Coop Italia.
Non conosciamo il possibile vettore d'ingresso, non sappiamo se siano stati cifrati sistemi e non disponiamo di informazioni verificate su eventuali interruzioni operative.
La notizia, quindi, rimane una rivendicazione da seguire con attenzione, non un data breach confermato.
Ed è una distinzione che nel mondo ransomware conta parecchio: i criminali hanno tutto l'interesse ad amplificare la percezione del danno, anche prima che sia possibile verificarlo.
Insomma: fare gli sburoni e sperare che qualcuno ci caschi (pagando eventuali riscatti), prima di dover tirar fuori le prove che quello che diciamo è vero, indipendentemente dal fatto che lo sia davvero o meno.
Fonti:
Telsy — PHP2Shell, nuovi exploit ITW e le ultime minacce dalla penisola
IlSoftware.it — Coop Italia nel mirino di Qilin: rivendicato il furto di 250 GB di dati
Aeroporti e logistica nel mirino: l'hacktivismo continua a guardare all'Italia
Se il ransomware cerca principalmente denaro e informazioni, l'hacktivismo punta spesso a qualcosa di diverso:visibilità, pressione politica e interruzione dei servizi.
Il Weekly Threats pubblicato da Telsy il 23 ottobre documenta nuove rivendicazioni di attacchi DDoS contro organizzazioni italiane.
Tra i bersagli dichiarati compaiono i portali dell'Aeroporto di Firenze e dell'Aeroporto Internazionale di Pisa, oltre a numerosi operatori della logistica, dei trasporti e della Pubblica Amministrazione.
Il gruppoBD Anonymous, descritto come un collettivo di presunta matrice sud-asiatica o bengalese, ha rivendicato offensive contro alcuni portali italiani, collegando le proprie azioni a motivazioni politiche relative al conflitto israelo-palestinese (che fa sempre figo e non impegna più di tanto).
Parallelamente, NoName057(16) e Dark Storm Team hanno continuato a indicare organizzazioni italiane tra i propri obiettivi.
È importante non confondere i bersagli dichiarati con gli effetti realmente verificati.
Non ci sono elementi sufficienti per affermare che gli attacchi abbiano compromesso i sistemi aeroportuali o interferito con la sicurezza dei voli.
Un DDoS contro il portale Web di un aeroporto è una cosa molto diversa da un'intrusione nei sistemi utilizzati per la gestione del traffico aereo, anche perchè le due cose sono decisamente separate e non sono assolutamente collegate.
Se bastasse abbattere il sito internet di Malpensa per far fermare l'aeroporto, noi sistemisti saremmo da mettere tutti in galera!
Eppure anche un'interruzione limitata del sito internet può avere conseguenze concrete.
Per un aeroporto, un operatore logistico o un'organizzazione che gestisce servizi online, l'indisponibilità di un portale può generare disagi agli utenti, richieste di assistenza e danni reputazionali.
È proprio su questa visibilità che molti gruppi hacktivisti costruiscono le proprie campagne.
Le contromisure rimangono principalmente tecniche: protezione DDoS, distribuzione dei servizi attraverso infrastrutture resilienti, monitoraggio del traffico e procedure per garantire la continuità operativa.
Fonti:
Telsy — Weekly Threats del 23 ottobre 2026: offensive DDoS e ransomware in Italia
CERT-AGID: 202 campagne malevole e il phishing italiano cambia ancora bersaglio
L'ultima notizia italiana riguarda qualcosa di meno appariscente di un attacco ransomware, ma decisamente più vicino alla quotidianità di milioni di persone.
Nel bollettino pubblicato il 23 ottobre, CERT-AGID ha analizzato202 campagne malevole, delle quali162 specificamente rivolte all'Italiae altre 40 generiche che hanno comunque interessato il nostro Paese.
Sono stati individuati1.460 indicatori di compromissione, messi a disposizione degli enti accreditati.
Rispetto alle 254 campagne della settimana precedente il numero diminuisce, ma non bisogna confondere il calo del volume osservato con una riduzione automatica del rischio.
Questa settimana il tema dominante è quello delle multe.
CERT-AGID ha identificato62 campagne di phishingcostruite su (ancora!) presunte sanzioni non pagate. Di queste, 53 utilizzavano abusivamente l'identità di SEND, 8 quella di PagoPA e una quella della Polizia di Stato.
Seguono le campagne sul rinnovo di servizi e documenti, con44 campagne italiane e una generica. In 39 casi è stato sfruttato il nome del Ministero della Salute.
Il banking rimane un altro bersaglio importante, con28 campagne di phishing italianeche hanno utilizzato marchi di istituti come Fineco, ING, Intesa Sanpaolo, BNL e altri operatori finanziari.
Ma il problema non si limita alla sottrazione delle credenziali: nel corso della settimana sono state osservate o rilevate14 famiglie di malware, tra cui Remcos, FormBook, AgentTesla, LXBaserat, XWorm, Guloader e BingoMod. Campagne che utilizzano temi come ordini, fatture, pagamenti e contratti, spesso accompagnati da allegati compressi o documenti costruiti per convincere l'utente ad aprirli. È un meccanismo che conosciamo bene, da cui dovremmo essere maledettamente vaccinati, ma che continua a funzionare!
La falsa multa sfrutta la paura di una sanzione, magari con l'urgenza associata per sfruttare "l'offerta speciale" come la chiamo io e pagare la ridotta.
Il rinnovo della tessera sanitaria sfrutta il timore di perdere un servizio o dover fare code interminabili e se viene permesso di operare online da casa, beh, spettacolo no? NO!
La fattura o l'ordine commerciale sfruttano invece la normale routine lavorativa che induce distrazione.
Tre approcci diversi, tutti costruiti sullo stesso principio:convincere il destinatario che il messaggio richieda un'azione perfettamente normalee magari urgente.
La difesa, manco a dirlo, passa ancora dalla verifica autonoma delle comunicazioni, dall'utilizzo dei portali ufficiali e dal controllo degli allegati prima dell'apertura.
Per le aziende diventa essenziale affiancare alla formazione degli utenti protezioni sulla posta elettronica, monitoraggio degli endpoint e strumenti capaci di rilevare comportamenti anomali anche dopo l'eventuale apertura di un allegato malevolo.
E, per tutte queste situazioni, bisognascollegare il cervello dal culo e collegarlo nel posto giustostare attenti e svegli, perchè nella stragrande maggioranza dei casi, il modo per accorgersi del problema c'è.
Perché il phishing non deve necessariamente essere sofisticato.
Deve soltanto arrivare nel momento in cui siamo abbastanza occupati da non farci troppe domande.
Fonti:
CERT-AGID — Sintesi riepilogativa delle campagne malevole nella settimana del 17–23 ottobre
In definitiva...
PHP2Shell ha tenuto banco (e lo farà ancora) per tutta la settimana, io stesso ho dovuto aggiornare un po' di hosting e addirittura sostituire completamente un web server per poterlo aggiornare (maledetto hardware obsoleto), ma le altre notizie non sono da meno, visti i punteggi CVSS.
Il phishing, poi, continuiamo a vedere campagne su campagne e quel che mi dico è che se le fanno vuol dire che funzionano.
Ok, con IA e tutto il circo equestre, diventa anche molto più facile quindi la convenienza rispetto alle vecchie email del principe nigeriano è maggiore, però evidentemente qualcuno ci casca ancora, altrimenti non perderebbero tempo.
Nel mezzo troviamo GitLab, infrastrutture SD-WAN, rivendicazioni ransomware contro grandi organizzazioni italiane e offensive DDoS contro servizi pubblici e operatori dei trasporti.
E, anche se sembra tutto scollegato, un punto di incontro c'è: gli attaccanti cercano continuamente il punto nel quale la complessità tecnica incontra la fiducia.
Un'applicazione Web si fida del proprio motore PHP ed esegue il codice
Un'organizzazione si fida del server GitLab che custodisce il codice.
Un amministratore si fida della console che gestisce la rete.
Un cittadino riconosce il logo di un servizio pubblico e presume che la comunicazione sia autentica.
Ogni relazione di fiducia può diventare un'opportunità per chi attacca.
E questa settimana PHP2Shell ci ha ricordato anche un altro problema:il tempo che passa tra la scoperta di una vulnerabilità e il suo sfruttamento continua a ridursi, da tempo ormai e in continua accelerazione.
Certo, se venissero rese pubbliche in maniera coordinata con gli sviluppatori, sarebbe meglio e non dovremmo tutti correre come dei criceti sotto anfetamine per aggiornare server dalla sera alla mattina, ma questo è un altro discorso e ne parla Zeus News inquesto articoloin cui si spiega che diverse segnalazioni relative al kernel Linux sono finite su una mailing list pubblica prima del completamento delle patch. E di nuovo, criceti isterici che corrono a patchare il patchabile!
Il vero problema è che non possiamo impedire che emergano nuove falle. Prima o poi arriveranno.
Possiamo però sapere quali sistemi utilizziamo, mantenerli aggiornati, limitarne l'esposizione e verificare cosa accade quando qualcosa va storto.
Perché la differenza tra una vulnerabilità critica e un incidente grave non dipende soltanto dalla qualità della patch.
Dipende anche da quanto velocemente siamo in grado di capiredove dobbiamo applicarla e se qualcuno è già passato prima di noi.
Alla prossima!
M.