PHP2Shell: aggiorna ora alla versione PHP con patch

La patch per PHP2Shell è uscita. Da mercoledì 21 ottobre 2026, ore 16:00 italiane, sono disponibili PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Queste versioni risolvono due falle critiche che permettono a un malintenzionato di eseguire codice sul tuo server senza login. Il team di PHP è chiaro: solo l’aggiornamento ti rende sicuro, e devi farlo ora.

PHP2Shell: is jullie website al gepatcht?

I dettagli erano già trapelati il giorno prima e la società di sicurezza Sansec prevedeva attacchi di massa entro quindici minuti dal rilascio. Ogni ora in cui un server rimane senza patch conta.

In questo articolo leggerai cosa è vulnerabile esattamente, a quale versione devi passare, come aggiornare in sicurezza, cosa fare se non riesci ad aggiornare oggi e come controllare se qualcuno è già entrato.

Aggiornato il 21 ottobre 2026 dopo il rilascio ufficiale di PHP.

Cos’è PHP2Shell?

PHP2Shell è il soprannome di due vulnerabilità di PHP stesso, entrambe con un punteggio di 9,2 su 10 (CVSS v4.0). Il nome deriva da uno strumento di exploit apparso in uno screenshot trapelato. PHP ha ora confermato cosa sta succedendo:

CVE	Cosa va storto
CVE-2026-109618 — RCE tramite carenza di memoria	Se PHP esaurisce la memoria mentre sta costruendo una richiesta, questa può essere interrotta a metà. Durante la pulizia, PHP tratta poi quei dati riempiti a metà come validi.
CVE-2026-109619 — RCE tramite stato residuo	I dati interni di una richiesta persistono dopo che la memoria è già stata rilasciata. Una richiesta successiva nello stesso worker può utilizzare quei dati prima che vengano resettati correttamente.

Chi è a rischio?

Secondo PHP: qualsiasi installazione PHP che gestisce richieste web. Questo vale per PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è maggiore con mod_php: lì è stato dimostrato che una singola richiesta senza login avvia l’attacco prima ancora che venga eseguita una sola riga di codice dell’applicazione.

La falla è quindi in PHP, non in WordPress, Laravel, WooCommerce o in un plugin. Aggiornare il tuo CMS non risolve il problema, e un sito senza modulo di upload è altrettanto vulnerabile.

A quale versione devi passare?

La tua versione PHP	Aggiorna a	Nota
8.5	8.5.12	Rilascio ufficiale da php.net
8.4	8.4.27	Rilascio ufficiale da php.net
8.3	8.3.36	Rilascio ufficiale da php.net
8.2	8.2.35	Rilascio ufficiale; la versione 8.2 sarà end-of-life il 31 dicembre 2026, pianifica ora il tuo upgrade
8.1, 8.0, 7.4 e precedenti	Aggiornare alla 8.2 o superiore	Nessun rilascio da php.net. Alcune distribuzioni e fornitori LTS forniscono un backport; PHP ha anche pubblicato patch sorgente minime per 7.4, 8.0 e 8.1 per chi compila autonomamente

Se utilizzi i pacchetti di una distribuzione Linux, non devi guardare questo numero di versione. Le distribuzioni hanno ricevuto le correzioni in anticipo e spesso le applicano alla propria versione (backport). Come verificarlo, lo leggi qui sotto.

Fai attenzione se ottieni PHP dal repository Remi gestito da volontari (rpms.remirepo.net): oggi non riceverà aggiornamenti. PHP consiglia di passare ai pacchetti della distribuzione o di compilare autonomamente.

Passaggio 1: identifica cosa devi patchare

Aggiorna prima i tuoi server raggiungibili da internet, a partire dai server mod_php. Prima di iniziare, salva una copia dei log del tuo web server e di PHP a partire dal 20 ottobre: ti serviranno nel passaggio 3, e un deploy o la rotazione dei log potrebbero cancellarli.

Sappi cosa devi patchare

Non dimenticare gli ambienti di staging, i vecchi siti di campagne, gli strumenti di gestione come phpMyAdmin e i container. Su un server Debian o Ubuntu:

# Welke PHP-versies zijn geïnstalleerd?
ls /etc/php

# Welke PHP-processen draaien er (FPM, Apache mod_php, LiteSpeed)?
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp'

# Welke sites geven verzoeken door aan PHP?
sudo nginx -T | grep -E 'server_name|fastcgi_pass'

php -v sulla riga di comando non dice nulla sulla versione che serve il tuo sito web: i pool FPM e Apache possono caricare un PHP diverso. Non mettere mai online una pagina phpinfo() pubblica per controllare.

Passaggio 2: come aggiornare PHP su Linux

Il modo in cui aggiorni PHP dipende da dove proviene il tuo PHP. Controllalo prima, perché è da lì che arriverà la tua correzione:

Fonte	Riconoscibile da	Da dove arriva la correzione
Pacchetti Debian o Ubuntu	`apt-cache policy` mostra `deb.debian.org`, `security.debian.org` o `security.ubuntu.com`	Repository di sicurezza della tua distribuzione (backport)
PPA / repo di Ondřej Surý	`apt-cache policy` mostra `ppa.launchpadcontent.net/ondrej` o `packages.sury.org`	Nuova versione upstream nel PPA
RHEL, AlmaLinux, Rocky	`dnf info php-fpm` mostra `appstream`	Red Hat / Alma / Rocky (backport)
Repository Remi	Nomi dei pacchetti come `php83-php-fpm` o repo `remi-*`	Nessun aggiornamento oggi
Alpine	Nomi dei pacchetti come `php83-fpm`	Repository Alpine
Pannello di controllo (cPanel, DirectAdmin, Plesk)	PHP sotto `/opt/cpanel/`, `/usr/local/php*` o `/opt/plesk/php/`	Meccanismo di aggiornamento del pannello

Prima di iniziare, crea uno snapshot o un backup del server. Un aggiornamento di sicurezza di solito non crea problemi, ma se sei molto indietro potresti importare anche altre modifiche.

Debian e Ubuntu

# 1. Pakketlijsten verversen
sudo apt update

# 2. Staat er een PHP-pakket op 'hold'? Dan wordt het stilletjes overgeslagen.
apt-mark showhold
# eventueel: sudo apt-mark unhold php8.3-fpm

# 3. Welke versie staat er en welke is beschikbaar? (doe dit per PHP-versie)
apt-cache policy php8.3-fpm

# 4. Alleen PHP bijwerken
sudo apt install --only-upgrade 'php8.3*'

# of gewoon alles bijwerken
sudo apt upgrade

Ripeti i passaggi 3 e 4 per ogni versione in /etc/php, non solo per la versione a cui punta il comando php.

Usi i pacchetti della distribuzione? In tal caso, il numero di versione upstream spesso non cambia: Debian e Ubuntu applicano la correzione alla propria versione. Il numero del pacchetto e il changelog ti dicono se la correzione è presente:

dpkg -l | grep php8.3-fpm
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | grep -m3 -E 'CVE-2026-10961[89]'

Se non trovi riscontri, la correzione non è ancora arrivata. Controlla l’avviso di sicurezza della tua distribuzione (Debian, Ubuntu) e mantieni le misure di emergenza finché il pacchetto non è disponibile.

Usi il PPA di Ondřej Surý? Allora apt-cache policy deve mostrare la nuova versione upstream dopo l’aggiornamento, ad esempio 8.3.36. Il PPA compila solo per le versioni Ubuntu supportate (22.04 e 24.04). Se utilizzi ancora Ubuntu 20.04 o versioni precedenti, non arriverà più nulla per questa via: pianifica una migrazione a un nuovo server.

RHEL, AlmaLinux e Rocky Linux

# 1. Welke PHP-pakketten en welke bron?
dnf list installed 'php*'
dnf module list php        # welke PHP-stream staat aan (bijv. 8.2)?

# 2. Zijn er updates?
sudo dnf check-update 'php*'

# 3. Bijwerken
sudo dnf upgrade 'php*'

# 4. Zit de fix erin?
rpm -q --changelog php-fpm | grep -m3 -E 'CVE-2026-10961[89]'

Anche Red Hat, AlmaLinux e Rocky effettuano il backporting: il numero di versione rimane lo stesso, il numero del pacchetto (la release) aumenta. Il changelog fa fede. Se la correzione non è ancora presente, segui le notifiche di sicurezza della tua distribuzione e mantieni le misure di emergenza.

Usi il repository Remi? PHP avverte che rpms.remirepo.net non ha aggiornamenti oggi. Puoi quindi:

attuare le misure di emergenza e tenere d’occhio gli aggiornamenti Remi (sudo dnf check-update --enablerepo='remi*');
passare allo stream PHP della tua distribuzione (dnf module reset php e dnf module enable php:8.2), a condizione che la tua applicazione funzioni con quella versione;
oppure compilare PHP autonomamente (vedi sotto).

Alpine Linux

sudo apk update
sudo apk upgrade 'php83*'      # vervang 83 door jouw versie
php83 -v

Pannelli di controllo

Sui server con un pannello di controllo, PHP proviene dal pannello, non dalla tua distribuzione. Aggiornalo tramite il pannello:

cPanel/WHM (EasyApache): sudo dnf upgrade 'ea-php*' (sui sistemi più vecchi yum), o tramite WHM → EasyApache. Aggiorna ogni ea-phpXX installato.
DirectAdmin (CustomBuild): da build update e poi da build php.
Plesk: tramite Strumenti e impostazioni → Aggiornamenti aggiorna i componenti PHP.

Controlla poi per ogni dominio quale versione di PHP è attiva e se si tratta della build con patch. Chi si trova su hosting condiviso non può farlo da solo: chiedi conferma al tuo hoster.

Compilazione autonoma

Se non è disponibile un pacchetto, ad esempio con Remi o un’installazione personalizzata, puoi compilare PHP dai sorgenti. Fallo solo se sai come è stato compilato il tuo PHP attuale:

# Hoe is de huidige PHP gecompileerd?
php -i | grep 'Configure Command'

# Broncode van php.net halen (pas de versie aan)
wget https://www.php.net/distributions/php-8.3.36.tar.gz
tar xzf php-8.3.36.tar.gz && cd php-8.3.36

# Met dezelfde opties bouwen en installeren
./configure <opties van hierboven>
make -j"$(nproc)"
sudo make install

Controlla il download con le firme sulla pagina di download di php.net. Per PHP 7.4, 8.0 e 8.1 il team PHP ha pubblicato patch sorgente separate; sono linkate nell’ avviso di sicurezza.

Controlla quale PHP sta eseguendo davvero il tuo sito web

Dopo l’aggiornamento e il riavvio (vedi sotto), vuoi essere sicuro che il tuo sito giri sulla build con patch, non solo sulla riga di comando.

# Versie van de geïnstalleerde FPM-binary
php-fpm8.3 -v

# Is de service ná de update gestart? Kijk naar 'Active: … since'
systemctl status php8.3-fpm

Se vuoi vederlo dal web server stesso, metti temporaneamente un file con un nome casuale nella webroot, aprilo una volta nel browser e cancellalo subito dopo:

<?php echo PHP_VERSION, ' ', PHP_SAPI;

In una versione upstream vedrai qui 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Con i pacchetti della distribuzione con backport, potrebbe rimanere il vecchio numero di versione; in tal caso, il comando changelog sopra indicato è la tua prova.

Riavviare, e stavolta proprio tutto

CVE-2026-109619 riguarda i dati che rimangono in un worker. Un aggiornamento senza riavvio non serve a nulla.

Riavvia PHP-FPM per ogni versione, ad esempio sudo systemctl restart php8.3-fpm, o Apache se PHP gira come modulo.
Riavvia i processi PHP a lunga esecuzione: queue worker, Laravel Horizon, scheduler, Reverb, Octane.
Cerca i processi che girano ancora sul vecchio binario PHP:

ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*deleted'

Docker, FrankenPHP e hosting

Docker: un host aggiornato non ripara il PHP nei tuoi container. Scarica l’immagine di base con patch, compila di nuovo ed esegui il deploy. Controlla con docker run --rm jouw-image php -v.
FrankenPHP: PHP è nel binario stesso, quindi hai bisogno di una nuova build di FrankenPHP.
Hosting condiviso o gestito, cPanel, Plesk, DirectAdmin: chiedi al tuo hoster di confermare che il tuo dominio giri su una build con patch. Passare a un’altra versione PHP nel pannello non garantisce nulla al riguardo.
PHP 8.1 o precedente: chiedi alla tua distribuzione o al fornitore LTS un backport, oppure aggiorna. Fino ad allora: applica le misure qui sotto, o metti il sito offline.

Non riesci ad aggiornare oggi?

PHP elenca una serie di misure che riducono le rotte di attacco note. Queste non rendono la tua installazione sicura; considerale come un ponte per ore, non per settimane. Impostale in php.ini, nel pool FPM (php_admin_value / php_admin_flag) o nella configurazione di Apache, non tramite ini_set() o un .user.ini, e poi riavvia tutti i worker.

Contro CVE-2026-109619 (stato residuo)

; in php.ini, of per FPM-pool:
; php_admin_flag[session.upload_progress.enabled] = off
session.upload_progress.enabled = 0

; alleen op PHP 8.5:
fatal_error_backtraces = 0

Inoltre, PHP consiglia:

Rimuovi le impostazioni PHP non valide o obsolete che generano un avviso per ogni richiesta. Nascondere gli avvisi con error_reporting, display_errors o @ non aiuta.
Risolvi gli errori fatali e i timeout che un aggressore può provocare, ad esempio nel codice di upload, importazione o pulizia.

Contro CVE-2026-109618 (carenza di memoria)

Imposta memory_limit = -1 tramite php_admin_value e controlla che nessun pool, cartella o applicazione imposti nuovamente un limite. Gestisci quindi l’utilizzo della memoria con un limite di container o cgroup che fermi solo il worker interessato. Per farlo, non usare RLIMIT_AS o RLIMIT_DATA: questi possono causare proprio l’errore vulnerabile.
Abbassa post_max_size: 8M se non hai bisogno di upload, 32M se ne hai bisogno. Mantieni upload_max_filesize al di sotto di tale valore.
Limita a livello di web server o proxy anche la dimensione delle richieste, il numero di campi, le parti multipart e gli header, anche per le richieste senza un Content-Length valido.

; per FPM-pool, bijvoorbeeld /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off

Livello extra: bloccare le richieste multipart

Questo non è un consiglio ufficiale di PHP, ma è una misura che molti amministratori hanno già attuato ieri. Chi non ha bisogno di upload può rifiutare le richieste multipart prima che raggiungano PHP. Fallo in ogni server block o virtual host che inoltra a PHP, compreso il catch-all.

Nginx (nel contesto http, più il if in cima a ogni server block):

map $http_content_type $block_multipart {
    default       0;
    "~*multipart" 1;
}

# in elke server block:
if ($block_multipart) { return 403; }

Apache 2.4 (virtual host o in cima a .htaccess):

<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Finché questa impostazione è attiva, gli upload di file, i moduli con allegati e alcuni plugin per moduli (come Contact Form 7) non funzioneranno.

Riduci la tua superficie di attacco

Metti offline i siti di staging e le applicazioni PHP di cui non hai bisogno immediato finché non sono patchati. CERT-EU consiglia di isolare, se necessario, le applicazioni vulnerabili esposte su internet.
Limita gli strumenti di gestione come phpMyAdmin al tuo indirizzo IP.
Assicurati che il tuo server non sia raggiungibile bypassando il tuo CDN o WAF.

Hosting condiviso? Lì di solito non puoi impostare queste opzioni in modo affidabile da solo. Chiedi al tuo hoster quando il tuo dominio girerà su un PHP con patch.

Cosa NON aiuta

Aggiornare WordPress, Laravel o i plugin. La falla è in PHP, non nella tua applicazione.
Plugin di sicurezza come Wordfence. Questi entrano in funzione solo dopo che PHP ha già elaborato la richiesta.
Impostazioni tramite ini_set() o un .user.ini FPM. Arrivano troppo tardi; PHP lo menziona esplicitamente.
Nascondere i messaggi di errore con error_reporting, display_errors o @.
RLIMIT_AS o RLIMIT_DATA come limite di memoria. Questi possono provocare proprio l’errore vulnerabile.
Solo un WAF o CDN. Questo aiuta solo se il tuo server non è raggiungibile direttamente tramite il suo indirizzo IP.
Aggiornare senza riavviare i worker. I processi in esecuzione utilizzano il vecchio PHP fino a un riavvio.

Passaggio 3: controlla se qualcuno è già entrato

Patchare chiude la porta, ma non dice nulla su chi l’abbia già attraversata. I dettagli sono trapelati martedì 20 ottobre intorno alle 17:20 ora italiana; controlla a ritroso dalle 17:00 di quel giorno fino al momento in cui hai applicato la patch.

Cerca nei log del web server e di PHP richieste multipart insolite e crash dei worker PHP-FPM.
Cerca file nuovi o modificati nelle webroot, cartelle di upload, plugin e mu-plugin: find /var/www -type f -newermt '2026-10-20 15:00 UTC' (aspettati del rumore da cache e log).
Controlla i file .user.ini e l’impostazione auto_prepend_file per eventuali modifiche.
Controlla cron, unità systemd e Supervisor per nuovi task, e cerca nuove chiavi SSH.
Fai attenzione ai processi PHP che avviano una shell, Python o curl/wget, e a connessioni in uscita inaspettate dall’utente PHP.
Controlla nelle tue applicazioni se sono stati aggiunti nuovi account amministratore.

Trovi qualcosa? Isola il server e conserva i log. Se le prove indicano un’intrusione, ricostruisci il server e cambia ogni segreto a cui l’utente PHP aveva accesso: file .env, password del database, chiavi API e app keys. Un controllo pulito non è una garanzia, ma è un buon segno.

Dopo l’aggiornamento: rimuovere le misure temporanee

Il PHP con patch gira dimostrabilmente su tutti i tuoi siti e tutti i worker sono stati riavviati? Allora annulla le misure di emergenza:

Riporta memory_limit a un valore normale. Senza limite, un singolo script fuori controllo può far bloccare l’intero server.
Ripristina post_max_size e upload_max_filesize se i tuoi siti hanno bisogno di upload più grandi.
Rimuovi l’eventuale blocco multipart sul tuo web server e nel tuo CDN, quindi testa un upload di file e i tuoi moduli più importanti.

session.upload_progress.enabled può rimanere disattivato, a meno che la tua applicazione non utilizzi quella funzione.

Hai bisogno di aiuto?

I clienti con gestione server non devono fare nulla: abbiamo già attuato le misure temporanee e applicheremo la patch non appena l’aggiornamento sarà disponibile.

Non hai un contratto di gestione o non sei sicuro che il tuo server sia ben protetto? Contatta Servermeister all’indirizzo [email protected] o al numero 020 895 0045. Ti daremo un’occhiata già oggi.