Vulnerabilità PHP del 21 ottobre 2026: cosa è successo e perché molti siti sono stati messi offline
Aggiornato al 29 ottobre 2026. Le informazioni descrivono la situazione documentata alla data di pubblicazione e possono cambiare con le verifiche sugli attacchi e con gli aggiornamenti dei provider.
Indice dei contenuti
Il 21 ottobre 2026 sono state rilasciate correzioni urgenti per due vulnerabilità critiche di PHP, identificate come CVE-2026-109618 e CVE-2026-109619. Le falle possono consentire a un aggressore di eseguire codice su un server vulnerabile senza effettuare l’accesso. Governi e aziende hanno temporaneamente sospeso alcuni servizi per ridurre i rischi durante gli aggiornamenti. Fonte: PHP.
PHP è uno dei software usati dai server per far funzionare siti come WordPress e molti negozi online. Le vulnerabilità, chiamate anche PHP2Shell, riguardano proprio PHP, non un particolare sito o plugin. La loro scoperta ha quindi coinvolto contemporaneamente amministratori di server, società di hosting, piattaforme cloud e organizzazioni pubbliche. Un sito che usa PHP non è automaticamente stato violato: il rischio dipende dalla versione effettiva, dalle protezioni presenti e dall’eventuale applicazione delle correzioni.
Cosa fare subito se hai un sito web
Chi gestisce un sito WordPress, un e-commerce o un’applicazione sviluppata in PHP deve anzitutto verificare quale versione di PHP è realmente in esecuzione sul server e se il provider ha applicato una correzione. Non basta aggiornare WordPress o installare un plugin di sicurezza.
- Controlla la versione PHP attiva. In WordPress la trovi in Strumenti → Salute del sito → Informazioni → Server; molti hosting la mostrano anche in cPanel, Plesk o nel proprio pannello.
- Verifica se la versione è stata corretta. Per i rami mantenuti direttamente dal progetto PHP, le release sicure indicate nell’avviso del 21 ottobre sono 8.2.35, 8.3.36, 8.4.27 e 8.5.12, o successive. Sulle distribuzioni Linux e sui servizi di supporto esteso può esistere una patch distribuita come aggiornamento del pacchetto, senza che il numero di versione principale cambi.
- Chiedi conferma al provider se PHP è gestito dall’hosting. La presenza nel pannello di “PHP 8.2” o “PHP 8.3” da sola non dimostra che il fix sia installato. Chiedi quale build o patch è stata applicata, e se l’intervento copre entrambe le CVE.
- Se usi PHP 8.1 o precedente, pianifica il passaggio a una release supportata. Il progetto PHP non pubblica più aggiornamenti ordinari per quei rami. Alcuni fornitori Linux e servizi di supporto esteso possono distribuire correzioni retroportate, da verificare caso per caso.
- Mantieni attive le protezioni perimetrali, ma non considerarle una soluzione definitiva. Un firewall per applicazioni web (WAF), cioè un filtro del traffico verso il sito, può bloccare alcune richieste malevole; non ripara il codice vulnerabile installato sul server.
- Se temi un tentativo di compromissione, fai controllare i log e l’integrità del sistema. Per un sito aziendale è opportuno verificare file modificati, account amministrativi inattesi e attività anomale sul server. Un aggiornamento successivo non elimina automaticamente eventuali accessi nascosti che un aggressore avesse già installato.
Se non è possibile applicare rapidamente una patch o una mitigazione affidabile, le autorità di cybersicurezza raccomandano di valutare l’isolamento o la sospensione temporanea dei servizi esposti a Internet, soprattutto quando trattano dati o funzioni sensibili. La decisione deve essere presa con il gestore dell’infrastruttura, considerando anche le conseguenze dell’interruzione. Fonti: NCSC britannico e WordPress.org.
Quali versioni PHP sono vulnerabili e quali sono state corrette
Le vulnerabilità PHP2Shell riguardano release che risalgono a PHP 5.4. Il progetto PHP ha pubblicato oggi quattro versioni corrette per i rami supportati. Le condizioni concrete di sfruttamento variano a seconda dell’ambiente e della configurazione, ma non basta usare una versione relativamente recente se non contiene la patch.
| Ramo PHP | Versione corretta dal progetto PHP | Indicazione |
|---|---|---|
| PHP 8.5 | 8.5.12 | Aggiornare a questa release o successiva. |
| PHP 8.4 | 8.4.27 | Aggiornare a questa release o successiva. |
| PHP 8.3 | 8.3.36 | Aggiornare a questa release o successiva. |
| PHP 8.2 | 8.2.35 | Aggiornare; il supporto ufficiale termina il 31 dicembre 2026. |
| PHP 8.1 e precedenti | Nessuna nuova release ordinaria del ramo | Passare a PHP supportato oppure verificare una correzione del fornitore con supporto esteso. |
PHP 8.3.35 è sicura? No, non rispetto alle vulnerabilità CVE-2026-109618 e CVE-2026-109619. PHP 8.3.35, pubblicata il 24 settembre 2026, era un aggiornamento di sicurezza per problemi precedenti, ma non contiene le correzioni pubblicate il 21 ottobre. Per il ramo 8.3 serve PHP 8.3.36 o una build del fornitore con entrambe le patch esplicitamente confermate. La distinzione è indicata nell’annuncio ufficiale della release 8.3.36.
La comunicazione ufficiale di PHP precisa che sono stati resi disponibili anche backport minimi del codice sorgente per PHP 7.4, 8.0 e 8.1, destinati a chi gestisce compilazioni proprie o non dispone di un fornitore LTS. Non equivalgono al ripristino del normale supporto di questi rami e non significano che ogni hosting con PHP 8.1 sia già protetto.
Un aggiornamento PHP può richiedere test di compatibilità con temi, plugin, librerie e codice personalizzato. Questo non giustifica il mantenimento indefinito di un ambiente vulnerabile: nei casi complessi è meglio prevedere una migrazione controllata o concordare una patch retroportata verificabile.
Che cosa è successo: la cronologia delle vulnerabilità PHP
La crisi del 21 ottobre non è iniziata oggi. Le vulnerabilità affondano le radici nel codice storico di PHP, mentre le segnalazioni che ne hanno dimostrato la reale sfruttabilità sono arrivate nei mesi precedenti. La PHP Foundation ha ricostruito gli eventi e ha riconosciuto anche i ritardi organizzativi nella gestione del problema.
| Quando | Che cosa è accaduto |
|---|---|
| 2024 | Un audit esterno condotto da Quarkslab, nell’ambito di un’iniziativa sostenuta dalla PHP Foundation, contribuisce a individuare segnali di problemi nella gestione della memoria. Non viene allora dimostrato un percorso concreto di esecuzione remota del codice. |
| 30 luglio – 1 agosto 2026 | Inizia un’attività di ricerca coordinata con Calif e OpenAI. Calif individua una prima catena di attacco legata agli errori di memoria. |
| 11 agosto 2026 | Calif segnala alla squadra di sicurezza PHP la possibilità di eseguire codice da remoto. Secondo la Foundation, OpenAI segnala indipendentemente la stessa causa alla radice nello stesso giorno. |
| 19-24 agosto 2026 | Wiz individua ulteriori vulnerabilità, verifica attacchi dimostrativi su applicazioni reali e invia la segnalazione al progetto PHP il 24 agosto. |
| Settembre e ottobre 2026 | I responsabili PHP, i ricercatori e diversi fornitori di infrastruttura lavorano alle correzioni, ai test e alle protezioni temporanee. |
| 20 ottobre, intorno alle 15:00 UTC | Cominciano a circolare online gli identificativi delle due CVE, prima della divulgazione concordata. Le prime informazioni riportano anche dati inesatti sulla gravità e sull’orario di rilascio. |
| 20 ottobre, 19:30 UTC | PHP anticipa l’avviso pubblico e sposta la data prevista del rilascio dal 22 al 21 ottobre. Circola anche un video dimostrativo pubblicato per errore e successivamente rimosso. |
| 21 ottobre, 07:41 UTC | Secondo la PHP Foundation, Chainguard pubblica immagini già contenenti il fix prima della scadenza concordata, rendendo possibile studiarne le differenze prima del rilascio generale. |
| 21 ottobre, 13:40 UTC | Vengono rese disponibili le quattro versioni PHP corrette. ENISA conferma l’orario nella comunicazione congiunta europea. |
La divulgazione anticipata ha ridotto il tempo disponibile per aggiornare i sistemi prima che informazioni utili agli attaccanti diventassero pubbliche. Secondo la PHP Foundation, al momento del rilascio i suoi controlli sui proof of concept circolanti non avevano individuato exploit funzionanti. Successive segnalazioni di traffico d’attacco da parte dei fornitori di sicurezza mostrano però che i tentativi sono cominciati rapidamente: le due osservazioni riguardano momenti e livelli di prova differenti. Fonti: PHP Foundation, Wiz, ENISA.
Come funzionano le due vulnerabilità PHP2Shell
PHP2Shell è il nome attribuito a due difetti che riguardano il modo in cui PHP usa la memoria del server. Un aggressore può inviare al sito richieste appositamente preparate per provocare errori nel funzionamento di PHP. In determinate condizioni il risultato può essere l’accesso a dati della memoria, l’interruzione del servizio o l’esecuzione di codice scelto dall’attaccante.
CVE-2026-109618: errore nella gestione della memoria esaurita
Quando PHP raggiunge una condizione di memoria insufficiente, detta out of memory (OOM), un’operazione può interrompersi prima che alcune strutture interne siano state inizializzate correttamente. La pulizia successiva può trattare quei dati incompleti come validi e provocare una corruzione della memoria.
La PHP Foundation segnala un rischio particolarmente elevato con Apache e mod_php, perché è stato dimostrato un attacco senza autenticazione che si attiva persino prima dell’esecuzione del codice applicativo. Sono state dimostrate catene d’attacco anche con PHP-FPM, attraverso percorsi applicativi.
CVE-2026-109619: riferimenti a memoria già liberata
La seconda vulnerabilità riguarda uno stato interno che può sopravvivere alla richiesta che lo ha creato. Se PHP continua a utilizzare un riferimento a memoria ormai liberata, una richiesta successiva gestita dallo stesso processo può leggere o utilizzare informazioni non più valide. In sicurezza informatica questo tipo di errore è noto come use-after-free.
I ricercatori di Wiz hanno dimostrato catene di esecuzione remota su installazioni di prova di WordPress, Drupal e Joomla, oltre alla possibilità di estrarre informazioni dalla memoria dei processi. Si tratta di test tecnici documentati, non della prova che tutti i siti basati su quei CMS siano stati compromessi.
Le falle riguardano il motore PHP e possono interessare configurazioni come PHP-FPM, mod_php, php-cgi e LiteSpeed. La loro sfruttabilità non è identica in ogni installazione. Una patch PHP è la correzione risolutiva; aggiornare solo il CMS o cambiare la password amministrativa non elimina queste vulnerabilità.
Quali sono i rischi concreti per siti e aziende
La conseguenza più grave possibile è la remote code execution (RCE), cioè l’esecuzione di istruzioni sul server da parte di un aggressore remoto. Le vulnerabilità hanno ricevuto un punteggio CVSS v4.0 di 9,2 su 10, classificato come critico.
In base ai privilegi del processo PHP, alla configurazione del sistema e all’esito dell’attacco, un’intrusione può comportare sottrazione di credenziali o dati, alterazione di pagine, installazione di backdoor, interruzioni operative e utilizzo abusivo delle risorse del server. L’accesso alla memoria può inoltre esporre segreti applicativi come token o chiavi API. Il punteggio di gravità descrive il potenziale tecnico, non la percentuale di siti già colpiti. Fonte: Google Cloud.
Gli attacchi sono già iniziati?
Sono documentati tentativi di sfruttamento. Il 21 ottobre Cloudflare ha dichiarato di avere osservato traffico diretto contro queste vulnerabilità e modifiche ripetute delle richieste malevole per tentare di aggirare le difese. Ricercatori indipendenti hanno segnalato attività di attacco e strumenti dimostrativi in circolazione.
Questo non consente ancora di quantificare con affidabilità quanti siti siano stati effettivamente compromessi, né di attribuire ogni interruzione o errore PHP a un attacco riuscito. Bisogna distinguere tra richieste sospette, tentativi bloccati, dimostrazioni in laboratorio e intrusioni confermate. È altrettanto errato affermare che non vi sia rischio perché non sono stati pubblicati grandi elenchi di vittime. Fonti: Cloudflare, The Record.
Quali siti sono stati messi offline il 21 ottobre 2026
Il 21 ottobre 2026, enti pubblici, università e aziende di diversi continenti hanno sospeso temporaneamente siti e servizi digitali per precauzione, in attesa delle correzioni alle vulnerabilità PHP. Le interruzioni hanno interessato numerosi Paesi, tra cui Italia, Francia, Germania, Paesi Bassi, Brasile e Australia. Anche negli Stati Uniti, organizzazioni come ICANN hanno disattivato temporaneamente alcuni servizi.
È importante precisare che un sito sospeso per precauzione non è necessariamente un sito hackerato. Nella maggior parte dei casi documentati, gli amministratori hanno preferito interrompere temporaneamente il servizio per applicare le correzioni ed evitare possibili intrusioni.
Italia: sospensioni e avvisi di sicurezza
In Italia sono stati documentati alcuni interventi concreti:
- Consortium GARR: l’organizzazione che gestisce la rete italiana dell’istruzione e della ricerca ha comunicato di aver isolato e messo offline alcuni servizi, in attesa dell’applicazione degli aggiornamenti di sicurezza.
- Comune di Montemurlo (Prato): ha annunciato la sospensione temporanea di portali territoriali, applicazioni gestionali e servizi collegati, a partire dal pomeriggio del 21 ottobre.
Anche il CSIRT Toscana, struttura regionale dedicata alla sicurezza informatica, ha diffuso il bollettino ufficiale del CSIRT Italia, segnalando la gravità delle vulnerabilità e la necessità di aggiornare PHP. Si tratta di un’allerta di sicurezza, non di una sospensione dei servizi del CSIRT.
Brasile: sospesi servizi di tribunali e amministrazioni
In Brasile, il Tribunale Regionale Federale della 1ª Regione (TRF1) ha sospeso precauzionalmente l’accesso esterno al sistema SEI, utilizzato per la gestione digitale di documenti e procedimenti amministrativi. Una misura analoga è stata comunicata dal Tribunale dei Conti di Tocantins.
Le amministrazioni hanno precisato che le sospensioni erano preventive e non costituivano una conferma di violazioni dei sistemi o dei dati.
Europa e grandi piattaforme: altri servizi temporaneamente offline
Secondo Reuters, le sospensioni hanno coinvolto anche siti governativi in Francia, Germania, Paesi Bassi, Belgio, Finlandia e Repubblica Ceca, oltre a servizi comunali, scolastici e sanitari in diversi Paesi europei.
La Wikimedia Foundation, responsabile dell’infrastruttura di Wikipedia, ha inoltre disattivato temporaneamente alcuni servizi di supporto, inclusi strumenti utilizzati dagli sviluppatori volontari. La misura non ha comportato la chiusura generale dell’enciclopedia Wikipedia.
Non esiste al momento un conteggio completo e verificato dei siti sospesi nel mondo. Molti servizi sono stati progressivamente ripristinati dopo gli aggiornamenti, mentre altri potrebbero richiedere interventi più lunghi. Le sospensioni documentano la portata dell’emergenza, ma non rappresentano un conteggio dei siti compromessi.
Cosa stanno facendo hosting, Cloudflare e grandi piattaforme
La risposta dipende da chi gestisce il server. Negli hosting gestiti può essere il provider a installare la correzione per i clienti; chi amministra un server privato o un ambiente personalizzato deve invece controllare e aggiornare PHP direttamente.
Cloudflare: protezioni WAF anche sul piano gratuito
Cloudflare ha annunciato regole dedicate a PHP2Shell, sviluppate prima della divulgazione pubblica e attive dal 21 ottobre alle 03:02 UTC per i clienti con traffico protetto dal suo WAF, anche nel piano Free. La società ha introdotto inoltre controlli che analizzano sia la richiesta sia la risposta HTTP per riconoscere meglio alcuni comportamenti anomali.
Per chi usa Cloudflare Free, le nuove regole sono state distribuite nel pacchetto gratuito di regole di sicurezza Cloudflare (Managed Free Ruleset) senza richiedere la creazione di regole personalizzate. La protezione presuppone tuttavia che il traffico del sito passi effettivamente attraverso il proxy e le difese Cloudflare. La stessa società ribadisce che il WAF è una misura aggiuntiva, non un’alternativa all’aggiornamento PHP. Fonte: Cloudflare.
Cloudways: mitigazioni, manutenzione e distribuzione progressiva
Nella propria pagina di stato, Cloudways ha dichiarato di aver informato i clienti, di aver introdotto protezioni temporanee e di star preparando l’installazione graduale delle correzioni sui propri server. Per le vecchie versioni PHP non più aggiornate dal progetto ufficiale, ha indicato il coinvolgimento di fornitori di supporto di sicurezza esteso (ELTS).
Il provider ha inoltre eseguito interventi straordinari sui propri servizi di piattaforma, sito e portale affiliati, con interruzioni temporanee documentate nella pagina di stato. Non significa che ogni server ospitato su Cloudways sia già stato aggiornato: la conferma va verificata sul proprio ambiente e nelle comunicazioni successive del provider.
Aggiornamento del 22 ottobre 2026: Cloudways aggiorna le versioni di PHP
Di seguito l’email che i clienti Cloudways hanno ricevuto il 22 ottobre 2026 in seguito all’applicazione della patch correttiva ad alcune versioni di PHP. In questo caso, i siti ospitati usavano già la versione PHP 8.2.
WordPress e Automattic: due situazioni differenti
WordPress.org ha pubblicato un avviso di sicurezza che chiarisce un punto: non è previsto un aggiornamento del core WordPress per correggere queste CVE, perché il difetto si trova in PHP. I gestori di siti WordPress installati presso hosting esterni devono quindi verificare il proprio server.
Automattic, invece, ha dichiarato di aver già protetto i siti ospitati nei propri servizi gestiti, tra cui WordPress.com, WordPress VIP, WP Cloud, Pressable e Tumblr. Questa garanzia comunicata da Automattic non si estende automaticamente a ogni sito WordPress installato autonomamente presso altri provider. Fonte: Automattic.
Google Cloud e altre infrastrutture
Google Cloud ha dichiarato che la propria infrastruttura cloud non è vulnerabile di per sé, ma le applicazioni PHP gestite dai clienti possono esserlo. Ha annunciato aggiornamenti delle immagini di base per servizi serverless supportati e ha spiegato che, in diversi ambienti personalizzati, è necessario ricostruire o ridistribuire le applicazioni usando PHP corretto. Fonte: Google Cloud.
Altri fornitori di hosting, distribuzioni Linux, sistemi di sicurezza e servizi cloud stanno gestendo la stessa emergenza con modalità diverse. Non è corretto considerarli tutti protetti o tutti esposti senza comunicazioni e verifiche relative alle rispettive piattaforme.
È sicuro fare acquisti online, usare l’home banking e le app dopo le vulnerabilità PHP 2026?
Le vulnerabilità PHP del 21 ottobre 2026 non rendono automaticamente pericolosi gli acquisti online, l’home banking o l’utilizzo delle applicazioni. Il problema riguarda i server che eseguono versioni vulnerabili di PHP, non direttamente i dispositivi degli utenti. È quindi possibile continuare a utilizzare i servizi online, prestando attenzione alle eventuali comunicazioni di sicurezza dei gestori.
Acquisti online: un e-commerce che utilizza PHP potrebbe essere esposto se il server non è stato aggiornato. Un attacco riuscito potrebbe consentire l’accesso a informazioni personali, dati degli ordini o, in determinate condizioni, informazioni relative ai pagamenti. Il rischio concreto dipende dall’infrastruttura e da come vengono gestiti i dati. Non è necessario smettere di acquistare online, ma è prudente utilizzare negozi affidabili, preferire sistemi di pagamento con protezioni aggiuntive e non inserire dati su siti che segnalano problemi di sicurezza ancora irrisolti.
Banche e home banking: le vulnerabilità PHP non riguardano automaticamente tutti i sistemi bancari. Una banca può utilizzare tecnologie differenti e dispone generalmente di diversi livelli di protezione. Non ci sono elementi per concludere che i conti correnti siano diventati insicuri a causa delle due vulnerabilità. È comunque opportuno accedere attraverso i canali ufficiali, mantenere attiva l’autenticazione a più fattori e controllare eventuali comunicazioni della propria banca.
Applicazioni per smartphone: le vulnerabilità non colpiscono direttamente Android, iOS o le app installate sul telefono. Tuttavia, un’applicazione può comunicare con server che utilizzano PHP per gestire account, dati o operazioni. In questo caso il problema potrebbe riguardare i sistemi remoti anche se l’utente utilizza un’app anziché un sito web. Aggiornare l’app sul telefono non corregge una vulnerabilità PHP presente sul server.
Navigazione e password: visitare un sito che utilizza una versione vulnerabile di PHP non significa automaticamente infettare il proprio dispositivo. Non è nemmeno necessario cambiare indiscriminatamente tutte le password. Se però un servizio comunica una violazione dei dati o richiede un aggiornamento delle credenziali, è opportuno seguire immediatamente le istruzioni ufficiali.
La precauzione più utile per gli utenti è prestare attenzione a comunicazioni sospette, non utilizzare collegamenti ricevuti in email o SMS inattesi e verificare eventuali avvisi direttamente sul sito o nell’app ufficiale. La presenza del lucchetto HTTPS protegge la connessione, ma non garantisce che il server sia stato aggiornato contro le vulnerabilità PHP.
Che cosa potrebbe succedere nelle prossime settimane e nel lungo periodo
Il problema immediato è distribuire le correzioni abbastanza rapidamente, senza introdurre malfunzionamenti in siti e applicazioni che dipendono da versioni vecchie. Alcuni gestori potrebbero dover verificare plugin, estensioni PHP, integrazioni e codice sviluppato anni fa. Dove sono presenti molti sistemi, l’operazione può richiedere interventi coordinati.
Il rischio più duraturo riguarda server dimenticati, progetti non mantenuti e versioni PHP fuori supporto. Una volta rese pubbliche le patch, è possibile confrontare il codice vecchio con quello corretto e cercare sistemi esposti. Per questa ragione il rischio non scompare alla fine della giornata: può continuare per settimane o mesi per le installazioni trascurate. Non è però possibile prevedere oggi il numero futuro delle compromissioni.
La vicenda apre anche una questione organizzativa. La PHP Foundation ha spiegato che alcuni indizi del problema erano noti dal 2024, ma la complessità tecnica, i timori di regressioni e le risorse limitate hanno rallentato la decisione su una correzione. La fondazione ha riconosciuto tale ritardo e annunciato cambiamenti nei processi di sicurezza.
L’intelligenza artificiale ha avuto un ruolo importante nella scoperta e nell’analisi delle vulnerabilità: Calif e Wiz hanno usato strumenti di IA, in collaborazione con OpenAI e altri soggetti. Gli stessi strumenti possono però ridurre tempi e competenze necessari per sviluppare nuovi attacchi. La lezione pratica per le aziende è tenere sotto controllo le dipendenze software e garantire aggiornamenti, verifiche e responsabilità chiare, non affidarsi solo alla presenza di un firewall. Fonti: PHP Foundation, OpenAI, Wiz.
Che cos’è PHP e quanti siti lo utilizzano
PHP è un linguaggio di programmazione eseguito sul server, utilizzato per creare pagine dinamiche, comunicare con database e gestire funzioni come accessi, ordini, moduli e contenuti. Il browser riceve il risultato, di solito una pagina HTML, senza eseguire direttamente il codice PHP.
PHP è alla base di WordPress, Drupal, Joomla e Magento e di numerose applicazioni personalizzate. Secondo W3Techs, al 21 ottobre 2026 veniva rilevato nel 69,3% dei siti di cui è identificabile il linguaggio lato server. La percentuale non significa che il 69,3% di tutti i siti del mondo sia stato attaccato, né che tutte le installazioni rilevate siano ancora vulnerabili. Misura la diffusione della tecnologia in un campione definito.
Proprio questa diffusione spiega perché due errori nel motore PHP possano provocare una mobilitazione internazionale. Un problema nel software sottostante raggiunge applicazioni molto diverse, comprese quelle che continuano a funzionare correttamente e non presentano vulnerabilità proprie.
Fonti ufficiali e aggiornamenti
La ricostruzione si basa sulle comunicazioni del progetto PHP e della PHP Foundation, sugli avvisi di ENISA e del NCSC britannico, sulle analisi tecniche di Wiz e sulle comunicazioni dei fornitori citati. Per conoscere lo stato del proprio sito occorre consultare anche gli aggiornamenti dell’hosting e verificare la versione PHP effettivamente installata: la situazione di un singolo server non può essere dedotta da una notizia generale.
Aggiornamento del 29 ottobre 2026: cosa sappiamo sugli attacchi PHP2Shell
Al 28 ottobre 2026, Wordfence non è a conoscenza di siti WordPress compromessi attraverso le vulnerabilità PHP2Shell. È quanto emerge da un’analisi dei dati di sicurezza raccolti dalla società che protegge oltre 5 milioni di siti WordPress. L’assenza di casi confermati tuttavia non esclude che possano essersi verificate compromissioni non ancora individuate.
I tentativi di attacco sono invece documentati. Tra il 23 e il 27 ottobre, Wordfence ha registrato circa 77.600 richieste riconducibili a PHP2Shell, provenienti da oltre 2.000 indirizzi IP. Le richieste comprendevano tentativi di eseguire comandi sul server, sottrarre informazioni dai file di configurazione come wp-config.php e .env e installare backdoor per mantenere l’accesso ai sistemi.
Questi dati dimostrano che gli attaccanti stanno cercando di sfruttare le vulnerabilità, ma non indicano quante richieste abbiano avuto successo. Sono stati segnalati anche possibili attacchi riusciti contro sistemi diversi da WordPress, sebbene alcuni dei casi pubblicati non siano stati verificati indipendentemente da Wordfence.
Per chi gestisce un sito WordPress, la raccomandazione rimane invariata: installare una versione di PHP che includa entrambe le correzioni e assicurarsi che il servizio PHP sia stato riavviato. Aggiornare WordPress, i plugin o il tema non corregge queste vulnerabilità perché interessano direttamente PHP.
Fonte: Wordfence, rapporto PHP2Shell del 28 ottobre 2026.
