Vulnerabilità PHP: la patch PHP2Shell e come controllare la versione di PHP (WordPress)

PHP2Shell è il nome di due vulnerabilità di PHP (CVE-2026-109618 · CVE-2026-109619) le cui patch sono state pubblicate il 21 ottobre 2026. Sono falle di esecuzione di codice da remoto che permettono di eseguire codice sul server anche con una richiesta senza login, quindi la prima cosa da fare è controllare quale versione di PHP usa il tuo sito e aggiornarla a una versione con la patch. Su un server Nginx + Apache con WordPress 7.1.3 ho controllato la versione di PHP in Salute del sito, ho aggiornato solo i pacchetti php alla versione con la patch e poi ho ricontrollato.

1️⃣ La vulnerabilità PHP PHP2Shell: come funzionano le falle e chi è colpito

Le falle si trovano nel motore di PHP, che legge la richiesta prima che venga eseguito il codice di WordPress: restano quindi anche se tieni aggiornati plugin e temi, finché non aggiorni PHP. Secondo l'avviso di CERT-EU entrambe hanno un punteggio CVSS di 9,2; i dettagli tecnici sono pubblici e se ne discute, e ha già cominciato a circolare un primo codice proof of concept.

CVE-2026-109618 è una falla per cui, quando una richiesta supera il limite di memoria (memory_limit) e viene interrotta, il processo di pulizia tratta come validi dati della richiesta inizializzati solo a metà. CVE-2026-109619 è una falla per cui lo stato della memoria liberata dopo un errore fatale resta e viene riutilizzato prima dell'inizializzazione dalla richiesta successiva gestita dallo stesso worker.

L'annuncio di php.net indica che è colpita ogni installazione di PHP che gestisce richieste web e considera Apache mod_php la configurazione più pericolosa. Su mod_php, infatti, è stato dimostrato che una sola richiesta senza login fa partire l'attacco prima che venga eseguito il codice dell'applicazione.

Le versioni corrette sono 8.2.35, 8.3.36, 8.4.27 e 8.5.12, e tutte le versioni precedenti dei rami da 8.2 a 8.5 sono colpite. PHP 8.1 e precedenti sono rami che il progetto PHP non supporta più, quindi non esiste una versione ufficiale con la patch: sono coperti dalle correzioni riportate da distribuzioni e provider di hosting (backport).

Quando CISA ha pubblicato l'avviso il 21 ottobre non era ancora stato confermato alcuno sfruttamento reale, ma CISA ha ritenuto pericoloso lasciare i sistemi senza patch e ha raccomandato di applicarla subito, a partire dai sistemi esposti a internet. Lo stesso giorno, nel suo avviso, CERT-EU ha concluso che, con il codice proof of concept in circolazione, è diventato più probabile che gli attaccanti stiano già sfruttando le falle.

2️⃣ Controllare la versione di PHP: Salute del sito › Informazioni › Server

Anche conoscendo le falle, non puoi decidere cosa fare finché non sai con quale versione di PHP gira il tuo sito. Nella bacheca di amministrazione apri [Strumenti › Salute del sito] ed espandi la sezione [Server] della scheda [Informazioni]: la riga [Versione di PHP] mostra la versione di PHP che gestisce davvero le richieste del tuo sito.

La riga [PHP SAPI], subito sotto [Versione di PHP], indica come viene eseguito PHP; fpm-fcgi corrisponde a una configurazione PHP-FPM. Poiché il difetto è nel motore di PHP che legge le richieste, anche questa configurazione è colpita, e l'annuncio di php.net ha indicato Apache mod_php come la configurazione più pericolosa. Qui guardi solo le due righe [Versione di PHP] e [PHP SAPI] della sezione [Server].

L'attacco inizia con una richiesta senza login. Nella fase in cui PHP legge la richiesta appositamente costruita prima del codice di WordPress, la richiesta fa scattare una delle due falle e porta all'esecuzione di codice sul server. Le versioni corrette bloccano questo flusso, quindi il compito è portare il PHP del sito almeno a una versione corretta.

[php -v] nel terminale mostra solo la versione del PHP predefinito della riga di comando. Nelle configurazioni con più versioni di PHP sullo stesso server, come EA-PHP di cPanel o alt-php di CloudLinux, può essere diversa da quella usata dal tuo sito. Per questo il riferimento è il valore [Versione di PHP] in Salute del sito.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

Su un server in cui non riesci ad accedere alla bacheca, trovi la versione usata dal sito tramite i processi PHP-FPM in esecuzione per gestire le richieste web. Nei pacchetti Debian e Ubuntu il percorso del file di configurazione letto dal processo master di FPM contiene il numero di versione; qui sotto c'è il risultato verificato su un server di test Debian 12 di un hosting gestito.

ps -eo user,args | grep '[p]hp-fpm'

root     php-fpm: master process (/etc/php/8.2/fpm/php-fpm.conf)
abcdefg+ php-fpm: pool abcdefghij-82
klmnopq+ php-fpm: pool klmnopqrst-82

L'8.2 nel percorso di configurazione è la versione di PHP usata dal sito su questo server, e questo hosting aggiunge il numero di versione anche alla fine del nome del pool (-82). Il file avviato dal servizio FPM attivo si vede anche nella riga [Main PID] di [systemctl status], e compare anche senza l'account root.

systemctl status php8.2-fpm --no-pager | head -6

● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-10-22 07:14:57 UTC; 7h ago
       Docs: man:php-fpm8.2(8)
    Process: <PID> ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: <PID> (php-fpm8.2)

Nei pacchetti predefiniti delle distribuzioni della famiglia RHEL come AlmaLinux il percorso di configurazione del master è /etc/php-fpm.conf, quindi il numero di versione non compare; in questo caso verifica la versione del pacchetto FPM con [rpm -qf /usr/sbin/php-fpm].

3️⃣ Sotto PHP 8.2: chiedi al tuo hosting se è stato applicato un backport e, se manca, richiedilo

Se la [Versione di PHP] in Salute del sito è inferiore a 8.2 (7.x, 8.0 o 8.1), non esiste una versione ufficiale con la patch di php.net. Secondo la tabella delle versioni supportate di php.net (verificata il 22 ottobre 2026) sono supportati solo i quattro rami 8.2, 8.3, 8.4 e 8.5, e per le versioni ufficiali 8.1 e precedenti non escono patch di sicurezza.

Il supporto di sicurezza del ramo 8.2 termina il 31 dicembre 2026, quindi se aggiorni ora scegli la 8.3 o successiva.

Al loro posto, distribuzioni e provider di hosting a volte pubblicano pacchetti che mantengono il numero di versione e incorporano solo la correzione (backport). I pacchetti 7.4.33, 8.0.30 e 8.1.34 di un server di test di un hosting gestito ne sono un esempio. Nel loro changelog c'era la riga [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619].

Anche con lo stesso numero di versione, per sapere se la correzione è inclusa cerca il numero CVE nel changelog del pacchetto; se compare una riga, il pacchetto contiene la correzione. Su Debian e Ubuntu la ricerca si fa come qui sotto, e il numero di versione nel percorso va adeguato a quello usato dal tuo sito.

zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618

   + (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via

Sui sistemi RPM la ricerca si fa con il comando qui sotto.

rpm -q --changelog php-common | grep 109618

Quindi, se sei sotto la 8.2, chiedi prima al tuo provider di hosting se è stato applicato il backport e, se non lo è o non si riesce a confermarlo, chiedi di passare a una versione supportata. Dopo l'aggiornamento ricontrolla il valore [Versione di PHP] in Salute del sito.

CISA ha raccomandato alle organizzazioni che usano 8.1 o precedenti e non possono aggiornare subito di tenere offline i sistemi basati su PHP fino alla patch o all'upgrade.

Se gestisci il server da solo e usi 8.1 o precedenti, puoi installare i pacchetti con backport della tua distribuzione o applicare le patch sorgente per 7.4, 8.0 e 8.1 pubblicate dal team di sicurezza di PHP. Restano comunque rami non supportati, quindi la vera soluzione è passare a una versione supportata.

4️⃣ PHP 8.2 o successivo: aggiorna alla versione con la patch e ricontrolla

Se sei su 8.2 o successivo ma sotto la versione con la patch, aggiorna PHP stesso. Negli hosting gestiti e condivisi è il provider ad applicare la patch a tutto il server: verifica dai suoi avvisi o con l'assistenza se è stata applicata e quale build è in uso, poi guarda se la [Versione di PHP] in Salute del sito è cambiata. Cloudways ha comunicato in un avviso sulla pagina di stato che il 21 ottobre alle 22:19 UTC stava applicando la patch a PHP 5.6, 7.4 e da 8.0 a 8.4, e il 22 ottobre alle 10:11 UTC ha annunciato che l'applicazione era terminata.

Su un server che gestisci tu, aggiorna con i pacchetti del repository della tua distribuzione o di un fornitore LTS, come indica l'annuncio di php.net. Prima dell'aggiornamento controlla in anteprima l'elenco dei pacchetti che cambieranno, verifica che vengano aggiornati solo quelli che iniziano con php e che non se ne aggiungano altri, e non mescolarlo con altri aggiornamenti del sistema operativo.

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (righe dei pacchetti di estensione come php-gd · php-intl omesse)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (righe dei pacchetti di estensione omesse)

Complete!

In questo test sono stati aggiornati alla versione con la patch solo i pacchetti che iniziano con php, e php-fpm si è riavviato da solo al termine dell'installazione dei pacchetti. La versione corretta entra in funzione solo quando i worker di php-fpm si riavviano, quindi negli ambienti senza riavvio automatico esegui tu [systemctl restart php-fpm].

Dopo l'aggiornamento controlla che [php -v] e la riga [Versione di PHP] della scheda [Informazioni] di Salute del sito mostrino entrambe la versione con la patch o successiva, e verifica anche lo stato del servizio php-fpm e la risposta del sito. Se è cambiato solo il valore della riga di comando e [Versione di PHP] è rimasta uguale, riavvia php-fpm e ricontrolla.

Anche dopo l'aggiornamento espandi la sezione [Server] nella scheda [Informazioni] della stessa schermata [Strumenti › Salute del sito] e guarda la riga [Versione di PHP]. Se il valore è passato alla versione che hai installato, anche i worker di php-fpm girano con la nuova versione.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

200

Per i pacchetti il cui numero di versione sale, la patch si verifica dal nuovo numero di versione; per i pacchetti con backport che mantengono il numero, dal numero CVE nel changelog. Questo server era del primo tipo: in [rpm -q --changelog php-common] non c'era alcuna riga con il numero CVE, e ho verificato con il nuovo numero di versione nella prima riga del changelog.

5️⃣ Se non puoi aggiornare subito: le misure temporanee indicate da php.net

Per i server che non si possono aggiornare subito, php.net indica le impostazioni qui sotto come misure temporanee, precisando però che riducono solo alcuni percorsi di attacco e non rendono sicura l'installazione. Avverte anche di non impostare il limite di memoria con RLIMIT_AS o RLIMIT_DATA al loro posto, perché questo può provocare proprio gli errori di allocazione vulnerabili.

php_admin_value è un'impostazione lato server che l'applicazione non può ripristinare, quindi chi usa un hosting condiviso spesso non può modificarla da solo e, anche in quel caso, deve rivolgersi al provider di hosting. php.net consiglia inoltre di fissare limiti, anche a livello di server web o proxy, alla dimensione del corpo della richiesta, al numero di campi di input, al numero di parti multipart, al numero di header e alla profondità di annidamento.

L'impostazione session.upload_progress.enabled della tabella è stata raccomandata ancora una volta nell'avviso di php.net del 23 ottobre. Per bloccare anche un percorso improbabile di esecuzione di codice da remoto (CVE-2026-115560), php.net ha consigliato di lasciare questo valore a 0 fino alla prossima versione regolare di correzione dei bug. L'impostazione compariva già come mitigazione nell'avviso GHSA-6wmf-4rv5-p3rp del 21 ottobre, quindi se l'hai applicata allora puoi lasciarla così.

Questo percorso si crea solo quando un'applicazione che nella configurazione imposta session.serialize_handler su php_binary o php_serialize lo cambia in php con ini_set() prima di session_start(), e anche la funzione di avanzamento del caricamento della sessione è attiva. Considerando solo il percorso di CVE-2026-115560, php.net ha precisato che le applicazioni che non cambiano il metodo di serializzazione durante l'esecuzione possono continuare a usare questa funzione attiva.

🔢 FAQ & contenuti consigliati

🔗 Contenuti consigliati

Sicurezza Sicurezza WP: sicurezza di wp-admin Impostazioni che proteggono la bacheca di amministrazione cambiando l'URL di accesso, limitando i tentativi di login e bloccando XML-RPC. Leggi l'articolo →

Sicurezza Vulnerabilità di wp-config.php Come evitare che il file wp-config.php resti esposto e rafforzare le impostazioni di sicurezza. Sicurezza XML-RPC di WordPress Come riconoscere gli attacchi a xmlrpc.php nei log e tre modi per disattivarlo. Server Avviso php-fpm max_children Un test sul campo che trova la causa dell'avviso nei log prima di aumentare i worker.

ℹ️ Informativa sull'affiliazione
I contenuti di questo sito includono link di affiliazione. Se un visitatore acquista un prodotto o un servizio tramite uno di questi link, il sito riceve una commissione dal venditore. In questo processo l'importo pagato dall'acquirente ^{(durante le promozioni l'importo scende↓)} non aumenta. Prezzi, sconti e disponibilità indicati si riferiscono al momento della stesura e possono differire da quelli reali: prima di acquistare verifica sempre presso il venditore. I prodotti vengono scelti e valutati secondo criteri propri, e le commissioni non influiscono sull'ordine di presentazione né sul contenuto delle valutazioni.