PHP2Shell: la corsa contro il tempo – cosa significano le falle PHP per siti web, dispositivi e i tuoi dati

Due falle critiche in PHP, un embargo violato in anticipo e tentativi di attacco ancora prima della divulgazione ufficiale: PHP2Shell non riguarda soltanto i siti web tradizionali. Il runtime vulnerabile può essere integrato anche in firewall, pannelli di controllo per l’hosting e altri dispositivi. Spieghiamo in modo chiaro che cosa è successo, chi deve intervenire e che cosa dovresti fare davvero come utente privato.

Il 20 ottobre sono comparsi online due numeri inizialmente poco appariscenti: CVE-2026-109618 e CVE-2026-109619. Dietro di essi si nascondevano due vulnerabilità di PHP non ancora divulgate completamente. PHP è la tecnologia che, su innumerevoli server web, elabora moduli, interroga database e genera pagine.

La divulgazione avrebbe dovuto seguire un ordine preciso: prima gli aggiornamenti e le regole di protezione già predisposte, poi i dettagli tecnici. Gli identificativi sono però diventati pubblici in anticipo, ha iniziato a circolare un punteggio massimo errato di 10,0 e, quella sera, è stato pubblicato per errore un video che mostrava un attacco funzionante. PHP ha anticipato il rilascio di un giorno.

Troppo tardi per una partenza tranquilla: in seguito Amazon ha individuato un tentativo di sfruttamento risalente al 17 ottobre, quattro giorni prima della patch. Dopo la divulgazione, i provider hanno registrato un’ondata di attacchi in rapida crescita; Reuters, citando Cloudflare, ha riferito di milioni di tentativi nel giro di poche ore. Non si tratta di milioni di violazioni riuscite, ma il dato mostra quanto rapidamente le vulnerabilità critiche vengano oggi testate con strumenti automatizzati.

La falla in sé non si trova sul tuo smartphone. Può comunque colpirti attraverso dati conservati presso un fornitore, siti web manipolati, campagne di phishing più credibili o servizi disattivati in via precauzionale. Il tuo dispositivo può essere pulito mentre i tuoi dati sono a rischio su un server altrui.

Le informazioni più importanti

PHP2Shell indica due vulnerabilità nella gestione della memoria del core PHP. In determinate condizioni, un aggressore può eseguire codice su un server senza autenticarsi; una delle falle può inoltre esporre contenuti della memoria con token di sessione, password, chiavi API o credenziali di accesso ai database. Entrambe le CVE hanno un punteggio di 9,2 secondo CVSS 4.0.

I rami upstream sono corretti a partire da PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. I rami più vecchi possono ricevere fix retroportati da distribuzioni, provider di hosting o fornitori LTS. Aggiornare soltanto il CMS o un plugin non basta: conta il runtime PHP che elabora effettivamente le richieste web.

Gli utenti privati non devono installare nulla sul telefono. I gestori devono inventariare e aggiornare siti web, container, interfacce di amministrazione e dispositivi che utilizzano PHP, verificando anche l’eventuale presenza di attacchi precedenti.

1. Come un vecchio problema di memoria è diventato una corsa globale contro il tempo

2024: un segnale di allarme senza un attacco dimostrato

La storia inizia già nel 2024. Durante un audit esterno sulla sicurezza di PHP emersero i primi indizi di quello che in seguito sarebbe diventato il problema di esaurimento della memoria. Mancava però un percorso affidabile da una richiesta web all’esecuzione di codice, mentre le possibili correzioni rischiavano di compromettere compatibilità o stabilità. Il piccolo team di sicurezza non raggiunse rapidamente un consenso. In seguito la PHP Foundation definì apertamente il ritardo un fallimento strutturale: i processi decisionali erano troppo macchinosi e le risorse troppo limitate.

Estate 2026: la ricerca assistita dall’IA trasforma la teoria in pratica

A luglio e agosto 2026, Calif, OpenAI e Wiz hanno analizzato il core PHP con metodi tradizionali e potenti modelli di IA. L’11 agosto è stato segnalato un percorso concreto verso la Remote Code Execution; in modo indipendente, Wiz ha individuato ulteriori varianti e dimostrato catene di attacco contro applicazioni PHP reali. Le persone dovevano comunque riprodurre i risultati, eliminare i falsi positivi e verificare le patch. L’IA ha tuttavia abbreviato la ricerca – e quindi anche il tempo a disposizione dei difensori dopo la divulgazione di una falla.

17 ottobre: il primo tentativo noto

Amazon Threat Intelligence ha successivamente individuato nella telemetria MadPot un tentativo di exploit risalente al 17 ottobre. Un rilevamento su un honeypot non dimostra che sistemi reali siano stati compromessi con successo, ma anticipa l’inizio della finestra di analisi forense. Non è chiaro come l’attore abbia ottenuto così presto informazioni sufficienti; non esiste un’attribuzione attendibile.

20 e 21 ottobre: l’embargo si rompe e arriva la patch

Il 20 ottobre gli identificativi CVE hanno iniziato a circolare pubblicamente insieme al punteggio CVSS errato di 10,0 e a un video di attacco pubblicato per errore. PHP ha anticipato il rilascio al 21 ottobre alle 14:00 UTC. Provider di hosting, distribuzioni e fornitori di sicurezza hanno preparato in parallelo pacchetti e filtri. Cloudflare ha attivato regole di protezione già prima del rilascio, combinando segnali provenienti da richieste e risposte. Un WAF rimane comunque soltanto una barriera aggiuntiva: non corregge il codice PHP vulnerabile.

Le versioni corrette sono state pubblicate il 21 ottobre; poco dopo sono comparsi strumenti di attacco pubblici e scansioni di massa. Autorità, ospedali, università e aziende hanno ritirato precauzionalmente alcuni servizi dalla rete, compresi per un certo periodo i servizi di polizia di Berlino e del Brandeburgo. Questo non dimostra un’intrusione, ma può indicare che il processo di emergenza ha funzionato: meglio andare offline in modo controllato che restare compromessi senza controllo. PHP2Shell evidenzia inoltre che i sistemi esposti pubblicamente devono reagire alle falle RCE critiche nel giro di ore, non di giorni.

Sono confermate due vulnerabilità PHP critiche, tentativi attivi di sfruttamento e una superficie di attacco potenziale molto ampia. Resta ignoto quanti sistemi siano stati effettivamente compromessi o quanti dati siano andati persi.

2. Che cosa non funziona a livello tecnico – senza gergo inutile

PHP lavora nella sala macchine di un sito web: esegue il codice di WordPress, negozi online o portali, elabora gli input e comunica con i database. Gli errori si trovano al di sotto del CMS. Per questo un’applicazione completamente aggiornata può comunque utilizzare un runtime PHP vulnerabile.

CVE-2026-109618: pulizia di dati incompleti

Se PHP raggiunge il proprio memory_limit nel momento sbagliato, l’elaborazione può interrompersi mentre alcune strutture dati interne sono state inizializzate solo in parte. Durante la pulizia, PHP può trattare queste aree come dati validi. Un aggressore tenta di provocare intenzionalmente questa condizione e di influenzare la disposizione della memoria fino a ottenere l’esecuzione di codice.

Su Apache con mod_php è stato dimostrato un attacco non autenticato che può avere effetto prima dell’esecuzione del codice dell’applicazione. In quel caso, login, autenticazione a due fattori o un plugin di sicurezza per WordPress non offrono protezione. Possono essere interessate anche altre modalità di esecuzione di PHP; prerequisiti e affidabilità variano in base a SAPI, applicazione e configurazione.

CVE-2026-109619: un riferimento obsoleto sopravvive alla richiesta successiva

Nella seconda falla, dopo un errore grave rimane un riferimento a una zona di memoria già liberata. Quando lo stesso worker PHP elabora una richiesta successiva, accede nuovamente a questo stato obsoleto – un use-after-free, ossia uno stato globale non più valido.

Le conseguenze possono includere esecuzione di codice, arresti anomali o divulgazione del contenuto della memoria. Quest’ultima è particolarmente insidiosa: un aggressore non deve lasciare una web shell visibile per ottenere token di sessione, password di database, chiavi API o certificati. Dopo aver applicato la patch, cercare soltanto file modificati non è quindi sufficiente.

Remote Code Execution significa innanzitutto eseguire codice con i privilegi dell’account PHP o del server web, non ottenere automaticamente l’accesso root. Tale account può tuttavia leggere configurazioni, raggiungere database o accedere a servizi interni. Permessi dei file, segmentazione della rete e principio del privilegio minimo determinano quindi quanto può estendersi una compromissione.

3. È davvero coinvolto quasi il 70% di Internet?

Al 23 ottobre 2026, W3Techs indica che PHP è utilizzato dal 69,3% dei siti web per i quali il servizio riesce a identificare il linguaggio di programmazione lato server. Tra questi siti PHP, il 65,3% utilizza PHP 8, il 26,9% PHP 7 e il 7,7% PHP 5.

Queste cifre descrivono la diffusione, non lo stato delle patch né gli attacchi riusciti. Molti sistemi sono stati aggiornati nel giro di poche ore, le distribuzioni forniscono backport con numeri di versione più vecchi e, sui dispositivi, il percorso vulnerabile potrebbe non essere raggiungibile pubblicamente. La conclusione corretta è quindi questa: circa sette siti su dieci con un linguaggio lato server identificabile utilizzano PHP e hanno dovuto verificare le proprie difese. Non è possibile quantificare seriamente quanti siano ancora vulnerabili o compromessi oggi.

4. Che cosa significa PHP2Shell per te come utente privato

PHP non infetta direttamente il tuo dispositivo

PHP2Shell viene eseguito sui server. Non devi ripristinare lo smartphone né installare un’app speciale. Il tuo dispositivo è a rischio soltanto se un sito manipolato ti induce a scaricare contenuti dannosi. Mantieni aggiornati sistema, browser e app e utilizza solo fonti affidabili. Un presunto “aggiornamento PHP2Shell” per il tuo dispositivo è con ogni probabilità un’esca.

I tuoi dati possono comunque essere coinvolti

Quando effettui un ordine in un negozio online, nome, indirizzo e cronologia degli ordini possono rimanere memorizzati a lungo. Se il server viene compromesso, questi dati possono essere coinvolti anche se non visiti il sito da mesi. La divulgazione della memoria può inoltre rendere visibili token e chiavi di accesso che non esistono come file sul server.

Anche un sito noto può essere manipolato: il dominio e l’icona del lucchetto restano invariati mentre uno script iniettato sottrae dati di accesso o di pagamento. HTTPS protegge il collegamento al server, non l’integrità del server stesso. Interrompi l’operazione in presenza di finestre di pagamento insolite, reindirizzamenti o download inattesi e contatta il fornitore tramite un canale già noto.

Dopo l’attacco tecnico arriva spesso la frode

I dettagli rubati rendono il phishing più credibile. Anche un messaggio con il tuo vero nome e il numero d’ordine corretto può essere falso. Apri i servizi importanti tramite l’app ufficiale, un preferito o un indirizzo digitato manualmente. I segnali di una compromissione dell’account includono avvisi inattesi di accesso o reimpostazione della password, sessioni sconosciute, dati di recupero modificati e richieste push, TAN o di autenticazione a due fattori che non hai avviato. Non approvare nulla “per sicurezza”: controlla direttamente l’account e rimuovi i dispositivi sconosciuti.

Nell’online banking, grazie all’autenticazione forte del cliente, una password o un PIN da soli di solito non bastano. Il phishing può però indurti ad approvare un’autorizzazione reale per l’accesso o il pagamento di un’altra persona. Verifica beneficiario, IBAN e importo; in caso di operazioni sconosciute, contatta la banca tramite l’app ufficiale o un numero già noto.

Che cosa puoi fare concretamente adesso

Se un servizio segnala soltanto manutenzione o una disattivazione precauzionale, non devi cambiare password indiscriminatamente né bloccare le carte. Utilizza un canale alternativo ufficiale e segui le comunicazioni del fornitore.

Se un fornitore segnala una possibile esposizione delle credenziali di accesso, cambia la password del servizio e di tutti gli altri account in cui l’hai riutilizzata. Termina le sessioni attive, abilita l’autenticazione a due fattori o le passkey e proteggi con particolare attenzione il tuo account e-mail.

Se hai inserito dati su un sito sospetto o installato una presunta app di sicurezza, proteggi i tuoi account da un altro dispositivo, contatta la banca se sono coinvolti dati di pagamento e fai controllare il dispositivo interessato.

Nessuna app di sicurezza e nessuna VPN possono riparare il runtime PHP del negozio online di terzi. Un software di protezione può aiutare contro la seconda ondata di attacchi, basata su download dannosi, app false e siti malevoli noti, ma non garantisce che i dati presenti su un server esterno siano al sicuro.

5. PHP è presente anche in firewall, sistemi NAS e altri dispositivi

PHP non è utilizzato soltanto nei siti web, ma anche nelle interfacce di amministrazione e nei servizi aggiuntivi di firewall, router, sistemi NAS, pannelli di controllo per l’hosting, sistemi VoIP, registratori di videosorveglianza o appliance industriali. Un prodotto è però coinvolto soltanto se utilizza una versione vulnerabile di PHP per elaborare richieste web raggiungibili. Contano inoltre il livello di esposizione e la disponibilità di una patch del produttore.

pfSense: Netgate ha confermato che sono coinvolti la GUI basata su PHP e il captive portal. La GUI standard è solitamente raggiungibile solo dalla LAN; un captive portal serve intenzionalmente client non attendibili. Lo stesso errore presenta quindi rischi diversi a seconda dell’esposizione.

Palo Alto Networks: sono coinvolte determinate versioni di PAN-OS e Panorama. Secondo il produttore, il problema interessa l’interfaccia web di gestione, compresa l’API XML, ma non in generale il data plane o GlobalProtect. Fino all’installazione del fix, l’amministrazione dovrebbe essere accessibile solo da reti attendibili o tramite un jump host controllato.

Plesk: i siti dei clienti utilizzano propri handler PHP, mentre l’interfaccia Plesk usa un motore separato. Aggiornare un solo livello può lasciare scoperto l’altro. Plesk ha quindi pubblicato aggiornamenti per entrambi i componenti.

Cisco e Sophos mostrano perché prodotti, servizi cloud e installazioni dei clienti debbano essere valutati separatamente. Cisco ha confermato il coinvolgimento di alcune famiglie di prodotti, ne ha classificate altre come non interessate e ne stava ancora esaminando ulteriori. Sophos ha dichiarato che i propri prodotti non erano coinvolti, ma ha temporaneamente messo offline il vecchio portale MyUTM, ospitato separatamente, perché utilizzava una versione vulnerabile di PHP.

Il NCSC olandese mantiene un elenco di stato aggiornato continuamente. È un inventario prezioso, ma non sostituisce l’avviso più recente del produttore: una dipendenza da PHP non dimostra da sola che la falla sia sfruttabile, mentre l’assenza di una segnalazione non rappresenta un cessato allarme.

Che cosa verificare su un dispositivo a casa o in azienda

Annota produttore, modello, firmware e pacchetti aggiuntivi. Cerca entrambe le CVE e “PHP2Shell” sul sito di supporto ufficiale e installa gli aggiornamenti esclusivamente tramite la funzione prevista per firmware o pacchetti. Non sostituire mai autonomamente la versione di PHP integrata: le appliance contengono spesso modifiche del produttore e componenti firmati.

Disabilita la gestione remota dalla WAN, gli inoltri di porta e le aperture UPnP non necessari e verifica gli accessi remoti tramite cloud. Se ti serve un accesso dall’esterno, utilizza se possibile una VPN e apri l’interfaccia locale soltanto dopo la connessione.

Separa le reti guest, IoT e di gestione, in modo che i dispositivi compromessi non possano raggiungere i servizi di amministrazione locali. Se un firewall, un NAS o un registratore di videosorveglianza non riceve più aggiornamenti di sicurezza, la sostituzione è spesso l’unica soluzione sostenibile.

6. Che cosa devono fare concretamente i gestori

Passaggio 1: chiarire responsabilità e inventario

Con l’hosting gestito, di solito è il provider a eseguire l’aggiornamento; per VPS, server dedicati, container e appliance, la responsabilità ricade su di te o sul tuo fornitore di servizi. Pretendi una risposta verificabile su entrambe le CVE, sulla versione del pacchetto o del firmware e sul riavvio di tutti i processi PHP. Contemporaneamente, inventaria domini, sottodomini, ambienti di staging, vecchi progetti, webmail, container e dispositivi con PHP integrato.

Passaggio 2: verificare il livello di patch corretto

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Per PHP 7.4, 8.0 e 8.1 sono disponibili backport del codice sorgente; fa fede l’avviso della distribuzione o del fornitore LTS.

Le distribuzioni possono retroportare i fix in versioni di pacchetto precedenti. Ubuntu 24.04 LTS, per esempio, indica 8.3.6-0ubuntu0.24.04.13 come versione corretta; anche cPanel ha distribuito backport. Confronta quindi la versione completa del pacchetto con l’avviso della distribuzione o del fornitore della piattaforma, non soltanto con il numero upstream puro.

Passaggio 3: verificare il runtime effettivamente attivo

php -v mostra generalmente solo la versione da riga di comando. Il server web può utilizzare un’altra installazione tramite PHP-FPM, mod_php o un container. Controlla quindi pool FPM, moduli del server web, host virtuali e immagini:

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

Dopo l’aggiornamento, i vecchi worker devono essere sostituiti: con mod_php, in genere riavviando il server web; con PHP-FPM, riavviando i pool. Riavviare un container con la stessa immagine non serve: l’immagine deve essere aggiornata e distribuita nuovamente.

Passaggio 4: impedire alle richieste di raggiungere PHP sui sistemi non aggiornabili

Se non puoi applicare subito la patch, limita l’accesso alle reti attendibili o a una VPN, oppure metti il servizio offline. Un plugin di manutenzione per WordPress non protegge se l’attacco interviene prima del codice dell’applicazione. Usa una pagina di manutenzione statica o blocca l’accesso sul reverse proxy, sul load balancer o sul server web.

Le regole WAF e CDN possono far guadagnare tempo, ma non sono una patch. Cloudflare ha osservato schemi di attacco variabili e ha dovuto valutare insieme richieste e risposte. Assicurati inoltre che il server di origine non sia direttamente raggiungibile tramite un secondo indirizzo IP o un nome host alternativo.

Misure di configurazione PHP come la disattivazione del progresso di upload della sessione o limiti più rigidi per memoria e upload riducono soltanto alcuni percorsi di attacco e possono avere effetti collaterali.

Passaggio 5: risalire almeno fino al 17 ottobre

Conserva i log di server web, PHP, proxy, WAF, sistema e container prima che vengano sovrascritti dalla rotazione. Cerca richieste di moduli anomale, PHP_SESSION_UPLOAD_PROGRESS, errori di memoria, processi shell inattesi, nuovi file, account, cron job e connessioni in uscita. Un attacco riuscito non deve necessariamente causare il crash del worker; al contrario, un singolo errore non dimostra un’intrusione. Conta il quadro complessivo.

Passaggio 6: ruotare i segreti accessibili a PHP

Poiché il contenuto della memoria può essere esposto, sui sistemi pubblicamente raggiungibili che non erano aggiornati devi ruotare tutti i segreti leggibili dal processo PHP, per esempio password dei database, token API, cloud e di deployment, credenziali SMTP o OAuth e chiavi di sessione. Correggi o isola prima il sistema interessato, quindi genera nuove credenziali da un ambiente attendibile.

Passaggio 7: in presenza di indizi di compromissione, non limitarsi a “ripulire”

In presenza di indizi di compromissione, isola il sistema in modo controllato, conserva i log e, se opportuno, i dati volatili, quindi ricostruisci gli host critici partendo da artefatti attendibili invece di eliminare soltanto i file visibili. Verifica anche gli account amministrativi e dei database, le pipeline di deployment e i sistemi collegati. Se possono essere coinvolti dati personali, informa tempestivamente i responsabili della protezione dei dati; ai sensi del GDPR, una violazione soggetta a notifica deve in linea generale essere segnalata entro 72 ore.

7. La lezione più ampia: la scoperta accelera, la correzione deve tenere il passo

PHP2Shell mostra come l’IA stia spostando il confine tra ciò che è “teoricamente possibile” e ciò che è “sfruttabile nella pratica”. I modelli possono analizzare su larga scala codice sorgente, tracce di crash e differenze tra patch; di conseguenza si riduce anche il tempo tra la divulgazione e la comparsa di codice di exploit funzionante.

La risposta non consiste semplicemente nell’utilizzare più IA. I maintainer hanno bisogno di risorse e processi decisionali chiari. I gestori hanno invece bisogno di inventari completi, cicli di patch rapidi, isolamento e procedure di ripristino collaudate. In Protectstar utilizziamo l’IA insieme alle code review e alla validazione umana. Accelera la ricerca, ma non sostituisce la responsabilità.

Conclusione

PHP2Shell colpisce i server, ma può arrivare fino a te sotto forma di rischio per i dati, tentativo di frode o interruzione di servizio. Rimani vigile senza farti prendere dal panico: utilizza i canali di contatto ufficiali, non approvare richieste inattese e reagisci in modo mirato alle comunicazioni dei fornitori interessati.

Per i gestori contano il runtime PHP realmente attivo, ogni istanza dimenticata, i componenti integrati, il riavvio dei vecchi processi e l’analisi retrospettiva almeno fino al 17 ottobre. Se non è disponibile una patch, l’isolamento è più responsabile della prosecuzione del servizio. Il fatto che un sito sia raggiungibile non dimostra che sia sicuro.