PHP2Shell è il nome usato per le vulnerabilità critiche di PHP divulgate il 21 ottobre 2026. Se il tuo sito usa PHP, la domanda immediata è se il runtime che serve i visitatori includa le correzioni di sicurezza. Aggiornare un plugin o vedere un pannello del firewall tutto verde non risponde a questa domanda.
PHP2Shell interessa il runtime PHP alla base dei siti web e può consentire l’esecuzione di codice da remoto senza autenticazione. PHP ha pubblicato le correzioni nelle versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12, e devi verificare la presenza di una versione corretta o di un backport documentato del fornitore nell’ambiente che serve effettivamente le richieste web. Mantieni attivi i controlli difensivi, ma non considerare un WAF o una modifica temporanea della configurazione un sostituto della patch.
Stato verificato: 21 ottobre 2026, 17:15 UTC. Questa guida riflette le correzioni pubblicate, anziché il precedente annuncio secondo cui il rilascio era ancora in attesa. Ricontrolla gli avvisi collegati prima di apportare modifiche, perché i pacchetti dei fornitori e le indicazioni di risposta possono evolvere rapidamente.
PHP2Shell: che cosa è stato effettivamente confermato?
Il team di sicurezza PHP identifica due falle che possono consentire l’esecuzione da remoto senza accesso autenticato. Il suo avviso ufficiale indica che le installazioni PHP che servono richieste web sono a rischio e segnala Apache con mod_php come la configurazione a rischio più elevato. Il runtime, la build e l’ambiente di gestione delle richieste influiscono sulla possibilità di sfruttamento.
| Identificativo | Descrizione di PHP | Rischio pratico |
|---|---|---|
| CVE-2026-109618 | Corruzione dovuta a memoria esaurita durante la pulizia della richiesta | Uno stato della richiesta non valido può essere utilizzato quando PHP gestisce un errore di allocazione |
| CVE-2026-109619 | Stato globale obsoleto appartenente alla richiesta | Una richiesta successiva sullo stesso processo worker può incontrare riferimenti a memoria liberata |
Entrambi gli avvisi riportano un punteggio CVSS v4.0 di 9.2. Leggi i rapporti primari per CVE-2026-109618 e CVE-2026-109619 invece di affidarti alla soluzione temporanea proposta in un post sui social.
È un motivo per agire tempestivamente, non una prova che ogni sito PHP sia già stato compromesso. Una vulnerabilità critica, un tentativo di attacco e un’intrusione confermata sono risultati diversi. La risposta deve stabilire quale situazione riguardi i tuoi sistemi.
Quali versioni PHP correggono PHP2Shell?
Le versioni di sicurezza dei rami supportati pubblicate oggi sono elencate di seguito. La tabella delle versioni è un punto di partenza per verificare un’installazione upstream. I pacchetti delle distribuzioni possono includere le correzioni con una revisione del pacchetto diversa.
| Ramo PHP | Versione di sicurezza che corregge entrambe le vulnerabilità |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Queste versioni sono confermate negli annunci di rilascio di PHP . Se il fornitore della distribuzione o dell’hosting usa correzioni retroportate, richiedi il suo avviso di sicurezza e la revisione esatta del pacchetto installato. Una sola stringa di versione può far classificare erroneamente un pacchetto del fornitore già corretto o un runtime incluso ma obsoleto.
PHP 8.1 e le versioni precedenti non ricevono più i normali aggiornamenti upstream. PHP ha anche fornito backport minimi del codice sorgente per 7.4, 8.0 e 8.1, ma ciò non ripristina il supporto continuativo. Definisci una correzione supportata da un fornitore responsabile oppure un piano di aggiornamento. La tabella di supporto PHP spiega il supporto attuale dei rami.
Verifica separatamente container, installazioni PHP incorporate e appliance. Le indicazioni operative di NCSC-NL avvertono espressamente che aggiornare PHP sull’host non aggiorna necessariamente questi runtime.
Sono interessati WordPress, Laravel e altri siti PHP?
Parti dall’interprete che esegue l’applicazione. Un sito WordPress, un’applicazione Laravel e un portale PHP personalizzato possono condividere un runtime obsoleto anche se il loro codice applicativo è completamente diverso. Installare l’ultima versione di un tema, plugin o framework non installa una correzione di sicurezza del runtime PHP.
Per l’hosting gestito, chiedi quale versione PHP o pacchetto corretto serva ciascun sito, se la modifica abbia raggiunto ogni nodo e se i processi worker siano stati riavviati dove necessario. Richiedi prove dalla piattaforma di hosting anziché interpretare la notifica di un aggiornamento applicativo come conferma.
Per i sistemi autogestiti, includi nell’inventario siti secondari, interfacce amministrative, vecchi host virtuali e ambienti di anteprima. Un’applicazione in produzione può essere aggiornata mentre un sito meno recente rimane raggiungibile pubblicamente sulla stessa infrastruttura. Registra un responsabile e una decisione di correzione per ogni ambiente esposto.
Non dedurre che un modulo di caricamento inutilizzato renda sicura un’installazione. Gli avvisi PHP descrivono percorsi di elaborazione delle richieste nel runtime. Le funzionalità applicative visibili a un visitatore non costituiscono una valutazione completa dell’esposizione.
Come applicare la patch e verificare il runtime che serve i visitatori
Accertare che cosa sia effettivamente in esecuzione
Identifica l’integrazione con il server web, il pacchetto runtime o l’immagine container, l’origine della configurazione e il responsabile del servizio. Collega questo inventario al nome host usato dai clienti. Un tecnico che verifica l’host sbagliato può produrre un rapporto di versione convincente ma irrilevante.
Questi comandi di sola lettura identificano l’installazione da riga di comando e la sua configurazione:
1php -v
2php --ini
Non dimostrano quale runtime stia usando PHP-FPM, Apache o un’altra integrazione che serve richieste web. Usa informazioni di hosting autenticate o una verifica amministrativa controllata per accertare il runtime effettivo. Non lasciare una pagina diagnostica pubblica che esponga configurazione e dettagli dell’ambiente.
Per un’installazione in container, verifica l’immagine e l’istanza applicativa che ricevono effettivamente traffico, non soltanto l’immagine sostitutiva presente in un registro. Includi nel registro delle modifiche tutte le istanze dietro il bilanciatore di carico e gli eventuali servizi worker separati.
Applicare la correzione supportata e testare l’applicazione
Usa la procedura di aggiornamento documentata della fonte dei pacchetti mantenuta o del fornitore dell’immagine. Registra la revisione installata e l’avviso del fornitore che copre entrambe le CVE. Pianifica i riavvii dei servizi o la sostituzione delle istanze in base all’installazione, senza presumere che scaricare un pacchetto modifichi i processi in esecuzione.
Conserva i log pertinenti prima delle modifiche che possono interrompere il servizio. Mantieni un backup verificato e un piano di ripristino, poi testa flussi applicativi rappresentativi dopo l’aggiornamento. Accesso, sessioni, pagamento, caricamenti ed elaborazione in background sono candidati utili quando l’applicazione li utilizza.
Completa la modifica ricontrollando il runtime che serve le richieste. Conserva prove delle istanze aggiornate, del momento in cui il traffico è stato spostato e di chi ha accettato le verifiche applicative. Un’attività di distribuzione contrassegnata come riuscita è una prova utile, ma non costituisce l’intera verifica.
Il WAF Cloudflare protegge da PHP2Shell?
Cloudflare dichiara di aver distribuito protezioni WAF contro PHP2Shell per i clienti WAF Free e a pagamento e di aver osservato traffico di attacco. L’annuncio descrive protezioni che considerano informazioni sulle richieste e sulle risposte. Consiglia inoltre espressamente di correggere PHP nonostante tali protezioni.
Per un singolo sito, verifica che il traffico pertinente attraversi effettivamente il servizio protetto e che le regole applicabili siano attive. Controlla eccezioni, regole di bypass ed eventuali origini raggiungibili separatamente. Sono verifiche dell’installazione, non una garanzia che l’annuncio di Cloudflare assicuri protezione per ogni possibile percorso verso l’applicazione.
Conserva i dati degli eventi WAF nell’ambito dell’indagine. Una richiesta bloccata può dimostrare che una regola ha rilevato quella richiesta. Non può certificare che l’origine non sia mai stata raggiunta in altro modo o che non si sia verificata un’intrusione precedente.
Usa il WAF come ulteriore livello difensivo mentre completi l’aggiornamento del runtime. Non rimandare la correzione PHP soltanto perché il pannello registra tentativi bloccati.
Le mitigazioni temporanee non correggono completamente PHP2Shell
Se non puoi applicare subito la patch, segui gli avvisi PHP aggiornati insieme al tecnico o al fornitore responsabile del sistema. L’avviso sullo stato obsoleto
spiega perché la disattivazione di session.upload_progress.enabled deve avvenire prima dell’analisi della richiesta e richiede il riavvio dei processi worker. Avverte espressamente di non affidarsi a ini_set() o a .user.ini di FPM per questo scopo.
La modifica blocca i percorsi confermati relativi alle sessioni, non ogni variante. PHP 8.5 ha anche indicazioni separate riguardanti fatal_error_backtraces. Copiare un breve frammento di configurazione da un forum non dimostra che entrambe le vulnerabilità siano state risolte.
L’avviso sull’esaurimento della memoria descrive controlli diversi, compresi limiti sulle richieste e modifiche alla gestione dei limiti di memoria. Questi interventi hanno conseguenze sulle risorse e sulla disponibilità. Esamina le istruzioni complete per l’installazione effettiva anziché rimuovere con leggerezza i limiti di memoria su un server in produzione.
Se non è possibile ridurre l’esposizione in modo accettabile prima della patch, valuta la restrizione dell’accesso pubblico all’applicazione interessata. Documenta la misura temporanea, i suoi limiti, il responsabile e la correzione permanente prevista. Una soluzione temporanea deve avere una condizione di rimozione o revisione, non diventare un’impostazione permanente non documentata.
Che cosa monitorare dopo aver verificato l’esposizione?
Parti da una situazione di riferimento e conserva la finestra temporale rilevante. Correla le richieste web con gli eventi PHP, del server web e dell’host, anziché considerare una singola richiesta insolita una diagnosi completa. Dove mancano i log, registra esplicitamente questa limitazione.
| Osservazione | Domanda per l’indagine |
|---|---|
| Uscite inattese dei processi PHP o errori di memoria | Il comportamento dell’applicazione è cambiato e quali richieste sono state gestite in quel periodo? |
| File eseguibili nuovi o modificati | C’è stata una distribuzione approvata o una scrittura non spiegata? |
| Processi figli o connessioni in uscita inattesi | Il processo web ha un motivo legittimo per svolgere tale attività? |
| Rilevamenti WAF e registri di accesso all’origine | Quali richieste sono state bloccate e quali percorsi hanno raggiunto l’origine? |
| Modifiche ad account, attività pianificate o segreti | Ogni modifica può essere ricondotta a un operatore autorizzato? |
Sono spunti per l’indagine, non indicatori specifici di PHP2Shell o prove di compromissione. Le normali operazioni possono produrre sintomi simili. Allo stesso modo, l’assenza di avvisi non dimostra che un sistema privo di patch fosse sicuro.
Se le prove suggeriscono un’intrusione, conservale e organizza la gestione dell’incidente insieme all’applicazione della patch. Aggiornare l’interprete non rimuove i meccanismi di persistenza, non annulla il furto di credenziali e non stabilisce quali dati siano stati consultati. Affronta questi aspetti come domande separate nel piano di risposta.
Domande frequenti
Che cos’è l’exploit PHP2Shell? PHP2Shell indica le vulnerabilità PHP identificate come CVE-2026-109618 e CVE-2026-109619. Riguardano la gestione della memoria nel runtime e possono consentire l’esecuzione di codice da remoto senza autenticazione. Non sono semplicemente un difetto di un plugin WordPress.
Quali versioni devo verificare per la patch PHP2Shell? Le correzioni dei rami supportati pubblicate il 21 ottobre 2026 sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Per i backport delle distribuzioni, ottieni l’avviso del fornitore e conferma la revisione esatta del pacchetto corretto installato nell’ambiente che serve le richieste.
Aggiornare WordPress corregge PHP2Shell? Aggiornare soltanto WordPress non aggiorna l’interprete PHP sottostante. Mantieni aggiornata l’applicazione, ma verifica separatamente la correzione di sicurezza del runtime PHP con il fornitore di hosting o il tecnico responsabile del server.
Un sito dietro Cloudflare è automaticamente sicuro? Cloudflare segnala protezioni WAF, ma il percorso del traffico, le regole applicabili e l’esposizione dell’origine richiedono comunque una verifica. Mantieni le protezioni attive e correggi PHP. Un pannello firewall non dimostra che il runtime sia corretto o che non vi siano state compromissioni precedenti.
È sufficiente disabilitare l’avanzamento dei caricamenti delle sessioni? No. PHP descrive questa misura come un blocco dei percorsi confermati relativi alle sessioni, non di ogni variante. Va applicata al livello di configurazione appropriato con il riavvio dei processi worker. Rimane necessario un runtime corretto o un backport verificato del fornitore.
Posso testare un exploit pubblico sul mio sito in produzione? Per la verifica iniziale privilegia prove relative a versioni, pacchetti e configurazione. Se la convalida richiede test con exploit, organizzali con autorizzazione esplicita in un ambiente controllato, con isolamento, monitoraggio e un piano di ripristino. Non eseguire script di exploit non verificati in produzione.
Installare la patch dimostra che il server non è stato compromesso? No. La patch risolve le falle del runtime, mentre la valutazione dell’incidente esamina attività precedenti, persistenza, credenziali e possibile accesso ai dati. Mantieni collegati questi filoni di lavoro e registra i limiti delle prove disponibili.
Serve aiuto per verificare, monitorare o correggere il tuo sito PHP?
Possiamo aiutarti a stabilire quali runtime PHP servano i tuoi siti, valutare l’esposizione, esaminare log e controlli difensivi disponibili e pianificare la patch o l’aggiornamento supportato necessario. Se l’ambiente richiede osservazione continuativa, possiamo concordare ambito del monitoraggio, responsabilità degli avvisi e procedura di escalation in base ai rischi individuati.
Il nostro servizio di sicurezza applicativa supporta valutazione e indagine, mentre il servizio di sicurezza dei server copre l’ambito dell’hosting e della configurazione. Possiamo collaborare con il tuo fornitore di hosting per verificare le correzioni del fornitore, coordinare le modifiche e documentare le verifiche applicative successive all’aggiornamento.
Il risultato utile è un resoconto chiaro di ciò che è stato verificato, corretto, resta incerto e ha un responsabile per il seguito. Non promettiamo un attestato di sicurezza basato su una stringa di versione o una singola scansione. Ambito e disponibilità vengono concordati prima dell’inizio dei lavori.
Contattaci per una verifica dell’esposizione a PHP2Shell, monitoraggio della sicurezza o supporto alle patch . Indica la modalità di hosting, i domini interessati, le versioni PHP note e la persona autorizzata ad approvare le modifiche. Non inviare password o token di accesso nella richiesta iniziale.