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

Ambiente di test Famiglia RHELAlmaLinux 9.8PHP 8.3 · WordPress 7.1.3Verificato il 2026-10-22

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.

Indice

2 min di lettura

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.

Secondo l'annuncio di php.net è colpita ogni installazione di PHP che gestisce richieste web, e Apache mod_php è considerata 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.

Modalità di esecuzione di PHP	Impatto	Note
Apache mod_php	🔴 Colpito · il più pericoloso	Dimostrazione in cui una sola richiesta senza login ha fatto partire l'attacco prima dell'esecuzione del codice dell'applicazione
PHP-FPM	🔴 Colpito	—
php-cgi	🔴 Colpito	—
FrankenPHP	🔴 Colpito	—
LiteSpeed	🔴 Colpito	—

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.

Schermata Salute del sito, scheda Informazioni: menu a sinistra Strumenti › Salute del sito e righe Architettura del server, Server web, Versione di PHP e PHP SAPI della sezione Server — la versione di PHP è il riferimento per verificare la patch della vulnerabilità PHP PHP2Shell (WordPress 7.1.3)

La riga [PHP SAPI], subito sotto [Versione di PHP], indica come viene eseguito PHP; fpm-fcgi corrisponde a una configurazione PHP-FPM. Qui guardi solo le due righe [Versione di PHP] e [PHP SAPI] della sezione [Server].

🧩 Flusso dell'attacco PHP2Shell

Diagramma esplicativo

①Richiesta senza loginUna richiesta web che chiunque può inviare

②Richiesta appositamente costruitaPHP la legge prima del codice di WordPress

③Falle di PHPMemoria esaurita → dati costruiti a metà usati così come sonoCVE-2026-109618La richiesta successiva usa lo stato di una richiesta già terminataCVE-2026-109619

④Esecuzione di codice sul serverPresa di controllo del sito

✅ Le versioni corrette bloccano questo flusso8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

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)

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.

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. Su Debian e Ubuntu la ricerca è del tipo [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618]. Sui sistemi RPM la forma è [rpm -q --changelog php-common | grep 109618]; adegua il numero di versione nel nome del pacchetto a quello usato dal tuo sito.

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 (8.2 o successiva). 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. Secondo la sua pagina di stato, Cloudways ha iniziato ad applicare la patch a tutte le versioni di PHP che supporta (da 5.6 a 8.4) il 21 ottobre alle 22:19 UTC. Il 22 ottobre alle 10:11 UTC ha annunciato il completamento.

🪐RiferimentiPHP2Shell 2

📡[Urgente] Emergenza PHP, usato dal 70% dei siti web | La vulnerabilità e cosa fare subito (in coreano) 🌌Hosting gestito Cloudways

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.

Schermata Salute del sito, scheda Informazioni: dopo l'aggiornamento si ricontrolla che la riga Versione di PHP della sezione Server sia alla versione con la patch o successiva — menu a sinistra Strumenti › Salute del sito e righe Versione di PHP e PHP SAPI della sezione Server (WordPress 7.1.3)

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'

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.

Impostazioni	Valore	Dove	Cosa blocca
memory_limit	-1	php_admin_value nel pool FPM o nella configurazione di Apache (perché l'applicazione non possa ripristinarlo)	CVE-2026-109618 · percorso di errore del limite di memoria (non completo)
post_max_size	8M (32M se ti servono gli upload) · upload_max_filesize più piccolo di così	php.ini · configurazione del pool	CVE-2026-109618
session.upload_progress.enabled	0 + riavviare tutti i worker	php.ini · pool FPM · configurazione del server (non tramite ini_set() o .user.ini)	CVE-2026-109619 · solo il percorso di sessione confermato
fatal_error_backtraces	0 + riavviare tutti i worker (solo PHP 8.5)	Come sopra	CVE-2026-109619 · solo il percorso di backtrace confermato

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.

🔢 FAQ & contenuti consigliati

Gli aggiornamenti automatici di WordPress riguardano solo core, plugin, temi e traduzioni; PHP è un programma installato sul server, quindi lo aggiorna l'amministratore del server o il provider di hosting. Gli aggiornamenti automatici di core, plugin e temi si attivano nella schermata Aggiornamenti di WordPress e nelle schermate Plugin e Temi, rispettivamente, e in nessuna di queste schermate compare la versione di PHP.

Tutti i dettagli tecnici sono nei due avvisi di sicurezza di GitHub che l'annuncio di php.net collega accanto ai numeri CVE. CVE-2026-109618 corrisponde a GHSA-w8hw-w9fx-j79w e CVE-2026-109619 a GHSA-6wmf-4rv5-p3rp. Anche l'avviso di CERT-EU cita questi due avvisi come riferimenti, e in questo articolo non sono inclusi i dettagli per riprodurre l'attacco.

CISA consiglia di monitorare i processi worker di PHP che aprono shell o scaricano strumenti. Scrive anche che, finché non applichi la patch, un firewall per applicazioni web può offrire una certa protezione. Poiché PHP è spesso incluso come componente di altri software e passa inosservato, CISA ha raccomandato di partire da un elenco dei sistemi su cui gira PHP.

🔗 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 di wp-admin: ingressi al login di WordPress

Sicurezza Vulnerabilità di wp-config.php Come evitare che il file wp-config.php resti esposto e rafforzare le impostazioni di sicurezza.

Diagramma degli attacchi nel log di accesso di xmlrpc.php

Sicurezza XML-RPC di WordPress Come riconoscere gli attacchi a xmlrpc.php nei log e tre modi per disattivarlo.

Simulatore del percorso delle richieste di php-fpm max_children

Server Avviso php-fpm max_children Un test sul campo che trova la causa dell'avviso nei log prima di aumentare i worker.

🪐RiferimentiPHP2Shell 6

📡PHP: Security advisory — Critical remote code execution vulnerabilities, update now (2026-10-21) 📡CISA: Critical Vulnerabilities in PHP Require Immediate Patching (2026-10-21) 📡CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP 📡Avviso di sicurezza GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) 📡Avviso di sicurezza GitHub GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) 🛰️Sansec: PHP2Shell — PHP RCE (CVE-2026-109618, CVE-2026-109619)

ℹ️ 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.