PHP2Shell: di cosa si tratta e come proteggere il proprio sito PHP

Dati verificati il 26 ottobre 2026 rispetto alle note di rilascio PHP e ai report di ricercatori e fornitori di sicurezza. Questo articolo sarà aggiornato al prossimo rilascio PHP.

Se il suo sito utilizza PHP, aggiorni PHP oggi stesso. Questa è la sintesi di questo articolo.

Il 21 ottobre 2026 il progetto PHP ha pubblicato le correzioni per due vulnerabilità critiche in PHP, note come PHP2Shell. Consentono a un attaccante di prendere il controllo di un server web da remoto, senza autenticazione. Gli attacchi erano già in corso prima della correzione.

Secondo W3Techs, PHP è utilizzato dal 69,2% dei siti web con linguaggio server-side noto. Tra questi: WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel e la maggior parte dei siti PHP personalizzati. Non è un problema limitato: riguarda una parte rilevante del web.

Per i proprietari di siti web: PHP2Shell in termini semplici

Non è tecnico? Questa sezione è per Lei. PHP è il software sul server web che fa funzionare il sito, come il motore di un’auto. Se il sito è realizzato con WordPress, WooCommerce, Magento, Drupal, Joomla o Laravel, utilizza PHP.

PHP2Shell è una coppia di vulnerabilità in quel motore. Un utente esterno può inviare al sito una richiesta apposita e prendere il controllo del server. Non serve una password né un account. Il problema non riguarda il tema o i plugin, quindi aggiornarli non risolve. Solo un aggiornamento di PHP lo fa.

Una volta entrato, l’attaccante può leggere password e chiavi presenti sul server, accedere ai dati dei clienti, modificare il sito o installare una backdoor per tornare in seguito. Gli attacchi sono iniziati prima ancora che fosse disponibile una correzione, quindi non conviene rimandare.

Cosa fare oggi:

1. Chieda al suo sviluppatore o al fornitore di hosting una sola cosa: "PHP è aggiornato a una versione che risolve PHP2Shell ed è stato riavviato dopo l’aggiornamento?" Richieda una risposta scritta, sì o no.
2. Se la risposta è no o "non so", chieda di risolvere oggi stesso. Se il sito usa una versione PHP vecchia (8.1 o precedente), non esiste una correzione pronta: serve subito un piano di aggiornamento.
3. Se è già risolto, chieda di controllare il server per eventuali segni di attacco dal 17 ottobre e di cambiare password e chiavi memorizzate.
4. Se nessuno gestisce il server o non riceve risposta, si rivolga subito a un esperto. Ogni giorno in cui il sito resta non aggiornato aumenta il rischio di essere individuato.

Se il negozio utilizza Shopify o una piattaforma simile, non deve intervenire: la gestione dei server è a carico della piattaforma.

La sintesi

• Aggiorni PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o versioni successive), poi riavvii PHP-FPM, Apache o qualsiasi worker PHP a lungo termine. Aggiornare WordPress, Magento o i plugin non aggiorna PHP.
• Se usa PHP 8.1 o precedenti, non esiste un aggiornamento ufficiale già pronto. Si sposti su una versione supportata, oppure utilizzi un pacchetto hosting o Linux che abbia integrato entrambe le correzioni.
• Non può aggiornare oggi? Attivi le regole PHP2Shell del firewall web e le impostazioni PHP indicate al punto 4. Riducono il rischio, ma non garantiscono la sicurezza.
• Dopo l'aggiornamento, consideri i segreti memorizzati sul server come potenzialmente compromessi e verifichi eventuali segni di attacco dal 17 ottobre 2026 in poi.

Che cos'è PHP2Shell?

PHP2Shell è il nome dato dai ricercatori a due vulnerabilità nel motore PHP e allo script di exploit che le combina. I bug non sono nel tema, nei plugin o nel codice personalizzato, ma in PHP stesso, il software che esegue il sito sul server.

Ecco perché il problema è così grave. I ricercatori di Wiz affermano che anche una semplice applicazione "Hello World" su una versione PHP vulnerabile può essere a rischio. Per i server Apache con mod_php, PHP stesso segnala un exploit dimostrato che funziona "prima dell'esecuzione di qualsiasi codice applicativo". Il sito può essere vulnerabile anche se il codice personalizzato è privo di errori.

In termini semplici: quando una richiesta fa esaurire la memoria a PHP (o si verifica un altro errore fatale nel momento sbagliato), PHP interrompe la richiesta rapidamente e in alcuni casi non ripulisce correttamente. Dati parziali o che avrebbero dovuto essere eliminati restano in memoria e PHP li considera validi, talvolta anche durante la gestione della richiesta successiva sullo stesso worker. Un attaccante può provocare intenzionalmente questa situazione con richieste di upload appositamente costruite, anche su pagine che non utilizzano upload, e trasformarla nell'esecuzione di comandi propri.

RCE significa remote code execution: un soggetto esterno può eseguire codice sul suo server. OOM significa out of memory. PHP valuta entrambe le vulnerabilità 9,2 su 10 (critico) secondo la scala CVSS 4.0. Il National Vulnerability Database USA utilizza la scala CVSS 3.1 e assegna punteggi di 9,8 (critico) e 8,1 (alto), quindi può trovare anche questi valori. Il nome PHP2Shell descrive il risultato: da un normale sito PHP a una "shell", con pieno accesso ai comandi del server.

Cosa può fare concretamente un attaccante?

• Eseguire comandi sul suo web server senza username o password.
• Leggere segreti dalla memoria del server. Wiz elenca "password, token di autenticazione, chiavi API e certificati". Non è nemmeno necessario che l'attaccante esegua codice sul server, quindi è un attacco silenzioso e difficile da rilevare.
• Utilizzare questi segreti per accedere al suo database, ai dati dei clienti e agli account dei fornitori di pagamento.
• Installare una backdoor nascosta (una "web shell") per tornare in seguito, oppure modificare e deturpare il sito.

Come si è verificato PHP2Shell

Le vulnerabilità sono state segnalate ad agosto, mantenute riservate mentre PHP preparava la correzione, poi la pubblicazione è stata anticipata dopo la fuga dei numeri CVE.

Secondo la PHP Foundation, i due numeri CVE sono trapelati il 20 ottobre senza dettagli tecnici, anche se un video pubblicato per errore da una società di ricerca ha rivelato alcune informazioni limitate. La Foundation aggiunge che un core developer di PHP aveva già notato i primi segnali del problema di out-of-memory durante un audit nel 2024, ma non era stato risolto all'epoca.

Perché questa volta si è proceduto così rapidamente

L'AI ha svolto gran parte dell'analisi. Wiz dichiara di aver utilizzato modelli AI (il proprio Wiz Atlas, Gemini 4 Argon di Google e GPT-5.6 Sol di OpenAI) e che "un singolo ricercatore ha completato in una settimana ciò che prima richiedeva mesi a un team di livello mondiale". Il team Codex Security di OpenAI e Calif sono citati insieme a Wiz sul sito PHP2Shell.

Anche gli attaccanti dispongono degli stessi strumenti. Il team di threat intelligence di Amazon avverte che l'AI rende più economico trasformare una patch in un exploit funzionante, quindi "più attori possono agire in poche ore o addirittura minuti". Il consiglio per bug critici su sistemi esposti a Internet: "misurare i tempi di patch e mitigazione in ore."

Chi è interessato da PHP2Shell?

Le versioni ufficiali di PHP coperte sono dalla 8.2 alla 8.5; la 7.4, la 8.0 e la 8.1 hanno ricevuto solo patch al codice sorgente. I ricercatori indicano che le versioni vulnerabili risalgono fino a PHP 5.4 e che quasi tutte le versioni di PHP sono state colpite da almeno uno dei due bug. Se il suo sito, store o applicazione web utilizza PHP e non ha aggiornato PHP dopo il 21 ottobre 2026, deve considerarsi coinvolto.

L'elenco di ProjectDiscovery cita circa 20 categorie di software PHP a lunga esecuzione da verificare. Qualsiasi software che utilizza PHP è potenzialmente coinvolto, tra cui:

• Siti WordPress e WooCommerce, Magento / Adobe Commerce, Laravel, Drupal e Joomla
• Moodle, Nextcloud e MediaWiki
• Strumenti di amministrazione come phpMyAdmin, Roundcube webmail e WHMCS
• Pannelli di hosting come cPanel e Plesk
• Apparati di rete con PHP integrato, dai firewall (pfSense, OPNsense) ai centralini telefonici (FreePBX) e strumenti di monitoraggio (Zabbix, Nagios XI). I vendor stanno pubblicando i propri bollettini; quello di HPE per ClearPass Policy Manager è un esempio.

L'impatto è molto ampio. Secondo i dati pubblicati il giorno della correzione, VulnCheck ha rilevato PHP su 2.608.039 host esposti su internet negli ultimi 30 giorni, valutando il 99,998% di essi come vulnerabili o probabilmente vulnerabili. Oltre 1,1 milioni, circa il 42%, utilizzano versioni PHP fuori supporto senza patch ufficiali, e circa il 27% usa PHP 7.3 o precedenti. Molti host non espongono la versione PHP, quindi parte del conteggio è una stima di VulnCheck.

Chi non è interessato

• Piattaforme completamente gestite come Shopify, dove la gestione dei server è a carico della piattaforma. Eventuali blog WordPress o strumenti PHP utilizzati a parte richiedono comunque una verifica.
• Siti che non utilizzano PHP sul server: Node.js, Next.js, Python o semplici HTML statici.
• Server già aggiornati alle versioni corrette indicate sotto e riavviati successivamente. (Si consiglia di monitorare anche il terzo bug descritto più avanti.)

Versioni PHP corrette

Se utilizza PHP 8.2, il supporto di sicurezza termina il 31 dicembre 2026; conviene pianificare ora la migrazione a 8.4 o 8.5, evitando una doppia attività di patching. Analizziamo la questione più ampia in PHP è ancora la scelta giusta per l’e-commerce?

Gli attaccanti stanno già sfruttando PHP2Shell?

Sì. I tentativi di attacco sono iniziati prima della pubblicazione della correzione.

• Quattro giorni in anticipo: I honeypot MadPot di Amazon (server esca progettati per attirare attaccanti) hanno registrato un tentativo di sfruttamento PHP2Shell datato 17 ottobre 2026, quattro giorni prima della divulgazione pubblica.
• Prima dell'orario di rilascio: Amazon segnala exploit proof-of-concept a partire dalle 02:00 UTC del 21 ottobre, dodici ore prima della pubblicazione delle versioni corrette, e altri nelle ore successive. Ora riporta "tentativi di sfruttamento diffusi in ambiente reale".
• Scansioni automatiche: VulnCheck ha rilevato scanner che utilizzano l'user-agent php2shell-scan/109618 e un tentativo da un indirizzo IP cinese di installare una web shell tramite un file di sessione. Il tentativo non è andato a buon fine.
• Exploit falsi: sono in circolazione repository proof-of-concept falsi su GitHub. Non esegua mai codice exploit scaricato su un server di produzione.

Alcune organizzazioni hanno preferito disconnettersi piuttosto che attendere. Secondo le notizie raccolte sulla pagina Wikipedia di PHP2Shell, molte organizzazioni europee hanno messo offline i siti su indicazione di CERT-EU e NCSC UK, mentre la NSA statunitense ha consigliato di disattivare i siti non aggiornabili immediatamente. La Finlandia ha sospeso i servizi web pubblici e Internet Archive si è fermato temporaneamente.

Un terzo bug, a rischio minore (23 ottobre)

Due giorni dopo la correzione principale, PHP ha pubblicato un avviso informativo su una vulnerabilità correlata, CVE-2026-115560, nella stessa funzione di session upload progress. Secondo Cloudflare, interessa anche le versioni già corrette, inclusa la 8.5.12. PHP la definisce un "vettore RCE improbabile" che richiede una configurazione di sessione non standard. In attesa del prossimo rilascio PHP, si consiglia di impostare session.upload_progress.enabled=0.

Come proteggere un sito PHP: cinque passaggi

Aggiornare PHP è l'unica soluzione completa. L'avviso di sicurezza PHP è chiaro: «Non esistono mitigazioni complete, l'aggiornamento è l'unica scelta sicura». Segua questi passaggi nell'ordine indicato.

Passo 1: Individuare ogni punto in cui PHP è in esecuzione

Elencare tutti i server, siti e strumenti in uso che utilizzano PHP. Non dimenticare:

• Copie di staging e test del sito
• Vecchi siti di campagne o landing page realizzati da agenzie
• Strumenti di amministrazione come phpMyAdmin o webmail
• Container Docker basati su una vecchia immagine php:
• Pannelli di hosting e appliance di rete

I siti dimenticati sono facili da trascurare e raramente aggiornati. Verificare anche che la porta 9000 di PHP-FPM non sia accessibile da internet: ProjectDiscovery segnala che le immagini Docker ufficiali di php-fpm ascoltano su tutte le interfacce di rete. Se ha ereditato un codice o un server di cui nessuno ha piena conoscenza, il nostro framework di due diligence per PHP legacy è un buon punto di partenza.

Passo 2: Verificare la versione di PHP

• Hosting condiviso o cPanel: controllare nel pannello di hosting sotto "Select PHP Version" o "MultiPHP Manager".
• Server proprio (VPS): eseguire php -v e php-fpm -v sul server. Su alcuni sistemi il comando FPM include la versione, ad esempio php-fpm8.3 -v.
• WordPress: andare su Strumenti → Salute del sito → Info → Server.

Confrontare con la tabella delle versioni corrette sopra. Se l’hosting o la distribuzione Linux applica patch retroattive, verificare il changelog del pacchetto per entrambi i numeri CVE invece che il solo numero di versione.

Passo 3: Aggiornare PHP e riavviarlo

Installare la versione corretta, poi riavviare Apache, PHP-FPM, LiteSpeed e ogni worker PHP attivo. Gli stessi ricercatori consigliano di "installare una versione corretta di PHP su ogni runtime e poi riavviare". Fino al riavvio, il vecchio PHP continua a gestire le richieste. Se usa Apache con mod_php, aggiornare prima questi server: PHP li considera a rischio maggiore.

Aggiornare WordPress, Magento o i plugin non aggiorna PHP. PHP è un software separato sul server. Per Docker, ricostruire l’immagine su una base php: aggiornata e ridistribuire.

Passo 4: Se oggi non può aggiornare

Questi passaggi riducono il rischio solo temporaneamente. L'avviso di sicurezza PHP precisa che tali misure «ridimensionano l'esposizione a specifici vettori di attacco ma non rendono sicura l'installazione». Alcune possono compromettere le funzionalità di upload: verifichi il sito dopo ogni modifica.

• Attivi le regole PHP2Shell del firewall web. Cloudflare ha applicato automaticamente le regole su tutti i piani con WAF, incluso quello Free. Fortinet indica la protezione FortiWeb e FortiGate nel proprio outbreak alert. Per il bug del 23 ottobre, la regola Cloudflare non copre i siti che hanno rinominato session.upload_progress.name.
• Disattivare upload progress: impostare session.upload_progress.enabled=0 in php.ini o nella configurazione del pool PHP-FPM, poi riavviare tutti i worker. L’impostazione tramite ini_set() o file .user.ini non è efficace in questo caso.
• Limitare la dimensione delle richieste: impostare post_max_size a 8M se il sito non prevede upload, o 32M se li prevede. Amazon suggerisce anche di bloccare gli upload multipart sui server che non si possono ancora aggiornare.
• Su PHP 8.5, imposti anche fatal_error_backtraces=0 e riavvii tutti i worker.
• Mettere offline il sito, o proteggerlo con login, se contiene dati sensibili. Diversi servizi pubblici hanno adottato questa soluzione.

Passo 5: Dopo l’aggiornamento, verificare se il sito è stato compromesso

Se il server era accessibile da internet prima dell’aggiornamento, considerare che i segreti in memoria potrebbero essere stati esposti. Analizzare i log almeno dal 17 ottobre 2026, la data del primo tentativo segnalato da Amazon.

• Cambiare le password del database, le API key, le chiavi dei gateway di pagamento, le password SMTP e le chiavi di firma delle sessioni (ad esempio i salt di WordPress o la chiave di cifratura di Magento, dove possibile in sicurezza).
• Cercare nuovi utenti admin sconosciuti, file PHP nuovi o modificati (soprattutto nelle cartelle di upload e session) e nuovi task pianificati (cron job).
• Controlli i log delle richieste per upload POST contenenti PHP_SESSION_UPLOAD_PROGRESS (Amazon) e per richieste multipart seguite da errori "Allowed memory size of … bytes exhausted", errori 500 ripetuti o crash dei worker PHP (Wiz).
• Verificare la presenza di cookie PHPSESSID insolitamente grandi o anomali nelle risposte (Wiz) e la stringa PWNED:: nelle risposte o nei file di sessione (VulnCheck).
• Cercare processi sconosciuti e connessioni in uscita inattese dal server.

Se trova qualcosa di anomalo, si rivolga a un esperto prima di intervenire, per non compromettere le prove.

In sintesi

PHP2Shell è uno dei problemi di sicurezza web più gravi degli ultimi anni. Coinvolge direttamente PHP, può essere sfruttato da internet senza autenticazione e gli attaccanti hanno iniziato a provarci prima che la correzione fosse disponibile.

La soluzione è semplice: aggiornare PHP, riavviarlo e controllare ogni server. Lo faccia subito, non la prossima settimana. Approfitti per dismettere tutto ciò che usa ancora PHP fuori supporto. Se un’applicazione legacy blocca l’aggiornamento, abbiamo descritto come migrare un monolite PHP legacy a Laravel senza freeze delle funzionalità.

Serve aiuto per correggere PHP2Shell?

Gestiamo ogni giorno siti WordPress e WooCommerce, Magento, Laravel e PHP personalizzati. Possiamo individuare tutti i siti e server PHP in suo possesso, aggiornare PHP in sicurezza e riavviarlo, configurare un firewall web, ruotare password e chiavi, verificare eventuali compromissioni e migrare i vecchi siti da PHP 7.x, 8.0 e 8.1 fuori supporto.

Ci contatti oppure scriva a info@stathmosgroup.com: inizieremo dal server più esposto.