PHP2Shell: come proteggere il tuo server

Vuoi aggiornare il tuo server Linux? Allora clicca sull’articolo del blog qui sotto:

PHP2Shell: is jullie website al gepatcht?

PHP2Shell: update nu naar de gepatchte PHP-versie

“Se i tuoi siti web o le tue applicazioni utilizzano PHP, aggiornali oggi stesso. Mercoledì 21 ottobre 2026 alle ore 16:00 italiane (14:00 UTC), il team di PHP rilascerà un aggiornamento di emergenza per due vulnerabilità critiche note come PHP2Shell. I dettagli erano già di dominio pubblico prima che la patch fosse pronta, quindi gli aggressori sono in vantaggio.

In questo articolo scoprirai cos’è PHP2Shell, come schermare temporaneamente il tuo server in attesa della patch, come aggiornare in sicurezza in seguito e come controllare se qualcuno è già riuscito a entrare.

Questo articolo è aggiornato a mercoledì mattina 21 ottobre. Non appena PHP pubblicherà l’elenco ufficiale delle versioni interessate e patchate, lo aggiorneremo.

Cos’è PHP2Shell?

PHP2Shell è il soprannome di due vulnerabilità del core di PHP: CVE-2026-109618 e CVE-2026-109619. Il team di PHP ha assegnato a entrambe un punteggio di 9,2 su 10 (CVSS v4.0). Secondo il CERT-EU e altri enti, un aggressore può eseguire il proprio codice sul tuo server senza necessità di login (remote code execution).

Il nome deriva da un tool di exploit apparso in uno screenshot trapelato. Nel pomeriggio di martedì 20 ottobre sono apparsi online i primi dettagli, molto prima dell’annuncio ufficiale previsto. La società di sicurezza Sansec prevede attacchi di massa entro quindici minuti dal rilascio della patch, poiché gli aggressori potranno vedere esattamente cosa è stato riparato.

Dov’è la falla?

PHP non ha ancora confermato la causa tecnica. Ricercatori indipendenti indicano il modo in cui PHP gestisce le richieste multipart: il formato con cui un browser invia moduli contenenti file. Secondo loro, si tratta di un errore di memoria (use-after-free) nella funzione session upload progress, che tiene traccia dell’avanzamento di un caricamento. Questa funzione è attiva per impostazione predefinita.

La cosa più importante da ricordare: la falla è in PHP stesso, non in WordPress, Laravel o in un plugin. PHP elabora la richiesta prima ancora che la tua applicazione esegua una singola riga di codice. Un sito senza modulo di caricamento non è quindi automaticamente sicuro, e l’aggiornamento di WordPress non risolve il problema.

Sei vulnerabile?

Presumi di sì se utilizzi PHP. L’elenco ufficiale delle versioni interessate seguirà solo con il rilascio, ma i segnali sono chiari:

Versione PHP	Stato	Cosa fare
8.2, 8.3, 8.4, 8.5	Supportata, riceverà una patch	Misure temporanee oggi, aggiornare dopo le 16:00
8.1 e precedenti	End-of-life, probabilmente NON riceverà una patch	Mantenere le misure temporanee e aggiornare il prima possibile
Sconosciuta	Inventariare	Prima scopri quale versione di PHP serve realmente il tuo sito (passaggio 1)

watchTowr e CERT-EU ritengono possibile che siano colpite le versioni a partire da PHP 5. Se utilizzi ancora Ubuntu 20.04 con PHP dal PPA di Ondřej Surý, probabilmente non riceverai un pacchetto aggiornato: quel PPA fornisce aggiornamenti solo per Ubuntu 22.04 e 24.04.

Passaggio 1: mappa tutte le tue istanze PHP

Puoi patchare solo ciò che conosci. Fai un elenco di ogni server e ogni sito che utilizza PHP, inclusi ambienti di staging, vecchi siti di campagne, strumenti di gestione come phpMyAdmin e container. Nota per ogni host quali versioni di PHP sono presenti, da dove proviene PHP (pacchetti di distribuzione, PPA, immagine Docker, pannello di hosting) e se l’host è raggiungibile da Internet.

Su un server Debian o Ubuntu, puoi ottenere molto con:

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

# Welke PHP-processen draaien er?
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'

# Luistert PHP ergens rechtstreeks op een poort?
sudo ss -tlnp

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

Passaggio 2: misure temporanee fino alla patch

L’unica vera soluzione è aggiornare PHP. Un core developer di PHP lo ha detto letteralmente: il patching è l’unica mitigazione. Le due misure seguenti non sono ufficiali di PHP, ma riducono notevolmente il rischio per le ore che precedono l’aggiornamento. Falle entrambe.

A. Disattiva session upload progress

Nel php.ini del tuo web server (non solo quello della CLI):

session.upload_progress.enabled = Off

Se usi PHP-FPM, imposta l’opzione in modo fisso in ogni pool, così che un .user.ini in una cartella web non possa riattivarla silenziosamente. Su Debian/Ubuntu i pool si trovano in /etc/php/<versie>/fpm/pool.d/:

php_admin_flag[session.upload_progress.enabled] = off

Riavvia poi PHP-FPM per ogni versione, ad esempio sudo systemctl restart php8.3-fpm. L’unico effetto che noterai: le barre di avanzamento che si appoggiano a questa funzione PHP non funzioneranno più.

Hosting condiviso? Inserisci la riga sopra in un file .user.ini accanto al tuo index.php (con PHP-FPM; possono volerci fino a 5 minuti prima che sia attivo). Se PHP gira come modulo Apache, usa in .htaccess: php_flag session.upload_progress.enabled off. Se ricevi un errore 500, rimuovi la riga e chiedi aiuto al tuo hoster.

B. Blocca le richieste multipart sul web server

Questa è la misura temporanea più efficace: rifiuta ogni richiesta con “multipart” nell’header Content-Type, prima che raggiunga PHP. Farlo per tutti i metodi HTTP (PHP 8.4 può gestire multipart anche con PUT e PATCH) e in ogni server block o virtual host che punta a PHP, incluso il default/catch-all. Gli aggressori inviano richieste anche direttamente al tuo indirizzo IP.

Nginx — nel contesto http, ad esempio in /etc/nginx/conf.d/block-multipart.conf:

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

E in cima a ogni server block che punta a PHP:

if ($block_multipart) {
    return 403;
}

Controlla con sudo nginx -t e ricarica nginx.

Apache 2.4 — nel virtual host o in cima a .htaccess (sopra le regole di WordPress):

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

Usa assolutamente req('Content-Type') e non %{CONTENT_TYPE}: quest’ultimo controlla la risposta invece della richiesta, rendendo il blocco inefficace.

LiteSpeed — in cima a .htaccess, fuori dal blocco WordPress, e poi riavvia LiteSpeed:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F]

Cloudflare (integrazione, non sostituzione) — una Custom Rule con azione Block e l’espressione:

any(lower(http.request.headers["content-type"][*])[*] contains "multipart")

Cloudflare protegge solo il traffico che passa attraverso Cloudflare. Imposta quindi il blocco anche sul server stesso, o consenti alle porte 80 e 443 solo il traffico proveniente dai range IP di Cloudflare.

Test — da un’altra macchina, sia tramite il tuo dominio che direttamente all’IP del tuo server:

curl -sS -o /dev/null -w '%{http_code}\n' -F test=1 https://jouwdomein.nl/
curl -sS -o /dev/null -w '%{http_code}\n' -X PUT -F test=1 https://jouwdomein.nl/index.php
curl -sS -o /dev/null -w '%{http_code}\n' -F test=1 --resolve jouwdomein.nl:443:<server-ip> https://jouwdomein.nl/

Dovresti vedere un 403 ovunque. Attenzione: anche un plugin di sicurezza di WordPress può dare un 403, ma questo avviene solo dopo che PHP ha già elaborato la richiesta. Verifica quindi che la pagina 403 provenga dal tuo web server.

Effetti collaterali: finché il blocco è attivo, i caricamenti di file non funzioneranno. Pensa alla libreria multimediale di WordPress, ai moduli con allegati, ai caricamenti Livewire e Filament. Anche Contact Form 7 invia i moduli normali come multipart, quindi testa i tuoi moduli più importanti. Le pagine normali, il login e le API JSON continueranno a funzionare normalmente.

C. Riduci la superficie di attacco

Metti offline i siti di staging e le applicazioni PHP che non ti servono oggi fino a quando non saranno patchati.
Limita gli strumenti di gestione come phpMyAdmin al tuo indirizzo IP (allow + deny all; in nginx).
Assicurati che il tuo server non sia raggiungibile bypassando il tuo CDN o WAF.

Cosa NON aiuta

Tutto ciò che viene eseguito solo dopo che PHP ha letto la richiesta arriva troppo tardi. Non fare affidamento su:

Aggiornare WordPress o i plugin. La falla è in PHP, non nel tuo CMS.
Plugin di sicurezza come Wordfence. Anche il firewall di Wordfence (tramite auto_prepend_file) entra in funzione solo quando PHP ha già elaborato la richiesta multipart.
file_uploads = Off. PHP legge comunque la richiesta multipart; salta solo i file.
disable_functions. Bloccare funzioni come system() non influisce sull’errore di elaborazione.
Un post_max_size ridotto. Non è noto alcun limite sicuro.
Solo un WAF o un CDN. Aiutano solo se il tuo server non è raggiungibile direttamente tramite il suo indirizzo IP.
Modalità manutenzione di Laravel o un messaggio 419. Questi arrivano solo dopo che PHP ha già elaborato la richiesta.

Passaggio 3: aggiorna non appena la patch è disponibile

Dalle 16:00 tieni d’occhio php.net, la mailing list php.announce e gli advisory della tua distribuzione. PHP potrebbe rilasciare la patch anche prima se vengono rilevati attacchi attivi. Aggiorna prima i server esposti su Internet, poi il resto.

Prima di iniziare, salva una copia dei log del web server e di PHP a partire dal 20 ottobre. Ti serviranno nel passaggio 4, e un deploy o la rotazione dei log potrebbero cancellarli.

Debian e Ubuntu

sudo apt update

# Staat er een pakket op 'hold'? Dan doet de update stilletjes niets.
apt-mark showhold

# Welke versie staat er en welke is beschikbaar?
apt-cache policy php8.3-fpm

sudo apt upgrade

Aggiorna ogni versione di PHP installata, non solo quella indicata dal comando php. Distribuzioni come Debian e Ubuntu spesso applicano correzioni di sicurezza alla versione esistente (backport). Il numero di versione potrebbe quindi sembrare vecchio anche se la correzione è presente. Controllalo nel changelog:

zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | head -20

Se sei molto indietro con gli aggiornamenti, tieni presente che scaricherai anche altre modifiche. Dopo l’aggiornamento, naviga un po’ nel tuo sito.

Riavviare, e stavolta proprio tutto

Riavvia PHP-FPM per ogni versione, o Apache se PHP gira come modulo.
Riavvia i processi PHP a lunga esecuzione: queue worker, Laravel Horizon, scheduler, Reverb, Octane. Altrimenti continueranno a usare il vecchio PHP.
Cerca i processi che girano ancora sul vecchio binario PHP sostituito:

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

Docker, hosting e pannelli

Docker: un host aggiornato non ripara il PHP nei tuoi container. Scarica l’immagine di base patchata, ricompila e fai il deploy. Controlla con docker run --rm jouw-image php -v.
FrankenPHP: PHP è nel binario stesso, quindi serve una nuova build di FrankenPHP.
Hosting condiviso o gestito, cPanel, Plesk, DirectAdmin: chiedi al tuo hoster di confermare quale build patchata di PHP serve il tuo dominio. Passare a un’altra versione di PHP nel pannello non garantisce che quella build sia patchata.
PHP 8.1 o precedente: mantieni le misure temporanee o tieni il sito offline finché non avrai effettuato l’upgrade.

Passaggio 4: controlla se qualcuno è già entrato

La patch chiude la porta, ma non dice nulla su chi l’abbia già varcata. Controlla a ritroso fino a martedì 20 ottobre intorno alle 17:00 ora italiana, poco prima dei primi messaggi pubblici sulla falla.

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.

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

Dopo la patch: rimuovere le misure temporanee

La versione patchata di PHP gira dimostrabilmente sul tuo sito? Allora rimuovi il blocco multipart dal tuo web server e da Cloudflare. Testa poi un caricamento di file e i moduli che temporaneamente non funzionavano. Session upload progress può restare 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à implementato 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 supporto oggi stesso.

Aggiornamenti, Linux, Sicurezza