PHP2Shell: patch uscita, cosa aggiornare subito

Aggiornato al 21 ottobre 2026, ore 18:10: la patch è uscita. PHP ha rilasciato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, che correggono le due vulnerabilità critiche ribattezzate PHP2Shell. Permettono a chiunque, senza login, di eseguire codice sul server. Se hai un sito WordPress, un ecommerce PrestaShop o WooCommerce, un'applicazione Laravel o un gestionale in PHP, devi aggiornare.

Il team di PHP è stato chiaro: aggiornare è l'unica soluzione completa. Le misure temporanee riducono il rischio ma non lo eliminano.

In questo articolo ti spiego cosa colpiscono le due falle, chi è esposto, come aggiornare su server, Docker e hosting condiviso e cosa fare se non puoi aggiornare subito. Con i comandi pronti da copiare.

Cos'è PHP2Shell, in parole semplici

PHP2Shell è il soprannome dato dai ricercatori a due vulnerabilità del core di PHP: CVE-2026-109618 e CVE-2026-109619. Il team di sicurezza di PHP le ha classificate come critiche, con un punteggio di 9.2 su 10 nella scala CVSS v4.0.

La differenza rispetto alle solite falle è dove si trovano. Non sono in un plugin, in un tema o in un framework: sono nell'interprete PHP, cioè nel programma che esegue tutto il resto.

Per questo il problema è così ampio: tocca ogni applicazione costruita sopra PHP, anche se il suo codice è perfettamente aggiornato.

Cosa vuol dire "esecuzione di codice da remoto"

Una vulnerabilità RCE (Remote Code Execution) permette a un attaccante di far girare istruzioni a sua scelta sul server, senza averne l'accesso. Con i permessi del processo PHP può, per esempio:

• leggere i file di configurazione, come wp-config.php, .env di Laravel o parameters.php di PrestaShop, con dentro le password del database;
• scaricare il database con clienti, ordini e dati personali;
• caricare una web shell, cioè un file PHP nascosto che gli lascia una porta aperta anche dopo l'aggiornamento;
• usare il server per altri attacchi, spam o mining di criptovalute.

Il soprannome PHP2Shell va letto così: si manda una richiesta al sito e si ottiene una shell, cioè il controllo del server.

Cosa colpiscono le due falle di PHP2Shell

Entrambe riguardano il modo in cui PHP prepara e ripulisce i dati di ogni richiesta web. Ecco cosa fanno, senza entrare nei dettagli utili solo a chi vuole sfruttarle.

CVE-2026-109618: corruzione quando finisce la memoria

Quando una richiesta fa esaurire la memoria a disposizione di PHP, l'interprete si ferma di colpo. Può succedere mentre i dati interni della richiesta sono preparati solo a metà.

Nella fase di pulizia, PHP tratta quei dati incompleti come se fossero validi. Un attaccante che sa provocare questa situazione può arrivare a eseguire codice. Codice GitHub dell'avviso: GHSA-w8hw-w9fx-j79w.

CVE-2026-109619: stato della richiesta precedente che resta in memoria

Un processo PHP-FPM o Apache serve tante richieste, una dopo l'altra. In certi casi, alcune informazioni di una richiesta sopravvivono anche dopo che la memoria che le conteneva è stata liberata.

La richiesta successiva, gestita dallo stesso processo, può usarle prima che vengano azzerate. È un errore di tipo "use after free", tra i più sfruttati in assoluto. Codice GitHub dell'avviso: GHSA-6wmf-4rv5-p3rp.

Chi è esposto a PHP2Shell

Secondo l'avviso ufficiale, è esposta qualsiasi installazione di PHP che risponde a richieste web:

• PHP-FPM (la configurazione più comune con Nginx e nei container Docker);
• Apache con mod_php;
• php-cgi;
• FrankenPHP;
• LiteSpeed (molto diffuso sugli hosting condivisi).

Non serve nessun login: basta una richiesta al sito. Il rischio più alto è su Apache con mod_php, dove è stato dimostrato un attacco che parte prima ancora che venga eseguito il codice dell'applicazione. Quindi nessun plugin di sicurezza di WordPress può fermarlo.

PHP usato solo da riga di comando, senza servire pagine web, non è indicato tra le configurazioni a rischio. Ma quasi tutti i siti rientrano in uno dei casi sopra.

Versioni corrette: a quale PHP aggiornare

Attenzione a PHP 8.2: finisce il supporto il 31 dicembre 2026. Se aggiorni adesso, valuta già il passaggio a 8.3 o 8.4.

PHP 8.1, 8.0 e 7.4: cosa fare

Questi rami non ricevono più versioni ufficiali. Il team di sicurezza ha però pubblicato delle correzioni minime per PHP 7.4, 8.0 e 8.1 nel repository GitHub di PHP, per chi compila da sorgente.

Alcune distribuzioni Linux e fornitori con supporto esteso stanno integrando queste correzioni nei loro pacchetti. Se il tuo server o il tuo hosting usa una di queste versioni, chiedi al fornitore se ha già applicato la patch.

Resta il fatto che sono versioni fuori supporto: la prossima falla potrebbe non avere nessuna correzione. È il momento di migrare.

Non è un caso raro. La società Mallory ha contato su Shodan circa 884.000 server esposti su internet che dichiarano PHP 8.1 o precedente. Nelle mie attività di manutenzione di siti web per PMI della Campania vedo spesso hosting condivisi fermi a PHP 7.4 da anni.

Come aggiornare PHP: cosa fare adesso

Prima di tutto fai un backup completo di file e database. Poi aggiorna partendo dai servizi pubblici più delicati: ecommerce, gestionali online, API.

1. Controlla la versione di PHP che usi

• Server Linux con SSH: php -v. La versione usata dal sito può essere diversa da quella della riga di comando. Per i pacchetti su Debian o Ubuntu: dpkg -l | grep -E "php[0-9.]+-(fpm|cli|common)"
• Container Docker (Coolify, Dokploy, Portainer): docker ps --format "{{.Names}} {{.Image}}" per l'elenco, poi docker exec NOME_CONTAINER php -v.
• WordPress: Strumenti → Salute del sito → Informazioni → Server.
• PrestaShop: Parametri avanzati → Informazioni.
• Laravel: php artisan about, sezione Environment.

2. Su Debian e Ubuntu

Le distribuzioni Linux hanno ricevuto la patch in anticipo, quindi i pacchetti aggiornati dovrebbero già essere disponibili. Aggiorna e riavvia PHP-FPM:

sudo apt update && sudo apt install --only-upgrade "php8.4-*" && sudo systemctl restart php8.4-fpm

Sostituisci 8.4 con il tuo ramo.

Le distribuzioni spesso applicano la correzione senza cambiare il numero di versione (backport). Quindi non fidarti solo di php -v: controlla l'avviso di sicurezza della tua distribuzione.

Se usi il repository Remi (rpms.remirepo.net, diffuso su CentOS, AlmaLinux e Rocky): oggi non avrà aggiornamenti. PHP consiglia di passare ai pacchetti della distribuzione o di compilare da sorgente.

3. Con Docker e Coolify

Qui c'è un punto da sapere. Nel momento in cui scrivo, le immagini ufficiali php su Docker Hub non sono ancora aggiornate: ci sono le versioni candidate 8.5.12RC1 e 8.4.27RC1, mentre per 8.3 e 8.2 le versioni corrette non sono ancora uscite.

Finché non escono, applica le mitigazioni della sezione successiva. Appena le immagini sono disponibili:

• se usi un tag di ramo come php:8.4-fpm, ricostruisci scaricando l'immagine nuova: docker build --pull --no-cache -t nome-app .
• se hai fissato la versione esatta, come php:8.4.26-fpm, cambiala a mano in php:8.4.27-fpm, altrimenti ricostruisci la stessa versione vulnerabile.

Su Coolify, dopo aver aggiornato il Dockerfile, fai un nuovo deploy forzando la ricostruzione senza cache. Poi verifica con docker exec NOME_CONTAINER php -v.

4. Su hosting condiviso

Sugli hosting condivisi la correzione la applica il provider, e di solito non devi fare nulla dal pannello. Nei prossimi giorni controlla che la versione minore sia cambiata (per esempio da 8.3.35 a 8.3.36). Se non cambia, apri un ticket citando l'avviso di sicurezza di PHP del 21 ottobre.

Aggiornare PHP su WordPress con Aruba, Register o Netsons

Molti cercano come aggiornare PHP sul proprio hosting. Su Aruba, Register, Netsons e quasi tutti gli hosting condivisi funziona così: dal pannello puoi scegliere il ramo di PHP (per esempio passare da 7.4 a 8.3), ma la patch di sicurezza dentro il ramo la installa il provider.

Quindi per PHP2Shell la cosa giusta da fare dipende dalla versione che hai:

• Sei su 8.2, 8.3, 8.4 o 8.5: non cambiare nulla dal pannello. Controlla da Strumenti → Salute del sito che la versione salga a quella corretta e, se tarda, scrivi all'assistenza.
• Sei su 8.1 o precedenti: usa il selettore della versione PHP del pannello (di solito si chiama "Versione PHP", "Selettore PHP" o "MultiPHP") per passare almeno a 8.3. Prima fai un backup e una prova.

Cosa controllare dopo il cambio di versione su WordPress

• Errore 500 o pagina bianca: quasi sempre un plugin o un tema vecchio non compatibile. Torna alla versione precedente dal pannello, poi aggiorna o sostituisci il plugin.
• Log degli errori: attiva WP_DEBUG_LOG in wp-config.php e guarda wp-content/debug.log per capire quale plugin dà problemi.
• Cache: svuota la cache del plugin e quella dell'hosting, altrimenti potresti vedere ancora le pagine vecchie.
• Funzioni chiave: prova carrello, checkout, moduli di contatto e login. Sono le parti che si rompono più spesso.

Se il sito è troppo vecchio per reggere PHP 8, è il momento di valutare un restyling del sito web invece di rimandare.

Se non puoi aggiornare subito: le mitigazioni ufficiali

Queste misure riducono il rischio su alcuni percorsi d'attacco, ma non rendono il server sicuro. Servono solo per coprire le ore fino all'aggiornamento, per esempio nei container in attesa della nuova immagine.

Contro CVE-2026-109618 (memoria)

• Imposta memory_limit=-1 in un punto che l'applicazione non può sovrascrivere, per esempio con php_admin_value nel pool FPM o nella configurazione di Apache. Controlla che nessun pool, cartella o applicazione rimetta un limite.
• Abbassa post_max_size: 8M se il sito non riceve upload, 32M se servono, con upload_max_filesize più basso.
• Metti limiti nel web server o nel proxy: dimensione della richiesta, numero di campi, parti multipart, header.
• Siccome PHP non ha più un limite di memoria, imposta un limite di memoria al container (in Coolify, nelle risorse del servizio). Non usare RLIMIT_AS o RLIMIT_DATA: possono provocare proprio l'errore che apre la falla.

Contro CVE-2026-109619 (stato residuo)

• Imposta session.upload_progress.enabled=0 in php.ini, nel pool FPM o nella configurazione del server, non con ini_set() o .user.ini. Poi riavvia tutti i processi PHP.
• Solo su PHP 8.5: imposta anche fatal_error_backtraces=0 e riavvia.
• Correggi gli errori fatali e i timeout che un visitatore può provocare. Nasconderli con display_errors o con @ non serve.

Le mitigazioni in una riga per Docker

Per un'immagine PHP ufficiale puoi aggiungere al Dockerfile questa riga, poi fare il deploy:

RUN printf "memory_limit=-1\npost_max_size=8M\nupload_max_filesize=6M\nsession.upload_progress.enabled=0\n" > /usr/local/etc/php/conf.d/zz-php2shell.ini

Su PHP 8.5 aggiungi fatal_error_backtraces=0. E ricordati il limite di memoria del container.

Come capire se qualcuno ha già provato a sfruttare PHP2Shell

Ora che i dettagli sono pubblici, gli attacchi automatici possono partire in fretta. Nel 2024, con CVE-2024-4577, Akamai aveva registrato i primi tentativi entro 24 ore.

Il segnale più tipico di un attacco riuscito è un processo PHP che avvia programmi che non dovrebbe avviare. Un worker php-fpm o apache2 che lancia sh, bash, curl, wget, python o nc è quasi sempre un brutto segno.

Tre controlli rapidi sui server Linux:

• Processi figli di PHP: ps -eo pid,ppid,user,etime,cmd --forest | grep -A3 -E "php-fpm|php-cgi|apache2"
• File PHP modificati di recente: find /var/www -type f -name "*.php" -mtime -2. Un file con nome strano in uploads o tmp va guardato subito.
• Cron dell'utente web: sudo crontab -l -u www-data non dovrebbe contenere niente che non hai messo tu.

Per una sorveglianza continua esiste anche process-watcher di Florian Roth, gratuito, che registra ogni programma avviato da un processo PHP.

Se trovi qualcosa di sospetto: isola il server, salva i log prima di toccare altro e cerca web shell, file nuovi, cron e utenti nuovi. Aggiornare PHP non toglie una web shell già caricata. Ho descritto lo stesso approccio nella guida su come capire se un sito WordPress è già stato bucato.

Cronologia di PHP2Shell

• 20 ottobre, mattina: un post su Hacker News anticipa l'esistenza delle due falle, poi viene rimosso.
• 20 ottobre, poche ore dopo: i ricercatori di watchTowr confermano che sono reali e sotto embargo.
• 20 ottobre, 21:33: PHP pubblica il preavviso con il rilascio fissato al giorno dopo.
• 21 ottobre, 16:00: escono 8.5.12, 8.4.27, 8.3.36 e 8.2.35, con l'avviso di sicurezza completo.

Nel 2012 era successo qualcosa di simile con CVE-2012-1823: la prima patch d'emergenza si era rivelata aggirabile e ne era servita una seconda. Quindi aggiorna subito, ma tieni d'occhio php.net nei prossimi giorni.

Checklist rapida contro PHP2Shell

• Subito: backup, controllo delle versioni PHP, aggiornamento dei servizi pubblici a 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
• Sui container Docker: mitigazioni oggi, ricostruzione appena escono le immagini ufficiali.
• Sugli hosting condivisi: verifica che la versione minore salga, altrimenti ticket.
• Nelle 48 ore successive: controllo di processi PHP, file modificati e cron.
• Nei prossimi mesi: migrazione da 8.1 e precedenti, e piano per lasciare 8.2 prima di fine anno.

Conclusione

PHP2Shell è una delle falle più serie degli ultimi anni per chi lavora con PHP: sta nel core, non richiede login e colpisce le configurazioni più diffuse. La correzione c'è ed è semplice da applicare dove gestisci tu il server.

Il punto debole sono i siti che nessuno segue: hosting condivisi mai controllati, versioni vecchie, container con la versione fissata. Lì un aggiornamento di dieci minuti può evitare un sito compromesso.

Se non sai su che versione di PHP girano i tuoi siti, o hai un sito su una versione fuori supporto, posso fare io il controllo e l'aggiornamento. Scrivimi e ti dico in giornata cosa va fatto. Seguo anche ecommerce e gestionali su misura, oltre agli altri servizi di assistenza e sviluppo.

Leggi anche

• Click2Shell WordPress: il bug del link che installa un tema
• Vulnerabilità Elementor Pro: come capire se sei già bucato
• Manutenzione sito web: quanto costa e cosa comprende
• Plugin4Shell: la falla zero-click di Claude Code e Codex

Fonti: avviso di sicurezza e rilasci su php.net; ChangeLog di PHP 8; avvisi GitHub GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp; analisi di Huntress e The Hacker News.