# PHP2Shell: due vulnerabilità critiche in PHP, aggiorna subito > PHP2Shell: due vulnerabilità critiche in PHP (CVE-2026-109618, CVE-2026-109619, CVSS 9.2) che permettono RCE non autenticata. Corrette in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35: chi è esposto, come aggiornare e cosa fare se non puoi. - Autore / Author: Diego Betto (https://diegobetto.com/about/) - Pubblicato / Published: 2026-10-21 - Aggiornato / Updated: 2026-11-03 - URL: https://diegobetto.com/php2shell-vulnerabilita-critiche-php/ - Tag: php, security, wordpress Il il team di sicurezza di PHP ha annunciato una **release di sicurezza straordinaria** per correggere due vulnerabilità critiche, entrambe con punteggio **CVSS v4.0 9.2**. Nella community il problema è già stato battezzato **PHP2Shell**, perché il rischio concreto è quello di passare da una richiesta HTTP a una shell sul server: **esecuzione di codice da remoto senza autenticazione**. > **La patch è uscita: aggiorna adesso** > > Il , con qualche minuto di anticipo sulle 14:00 UTC previste, PHP ha rilasciato le versioni **8.5.12, 8.4.27, 8.3.36 e 8.2.35**, che correggono entrambe le vulnerabilità. Secondo il team PHP **non esistono mitigazioni complete**: aggiornare è l'unica scelta sicura. > > _Ultimo aggiornamento: — exploit funzionante con bypass di ASLR (VulnCheck) e dati sull'esposizione in rete._ > **Aggiornamento 3 novembre: ASLR aggirato, 2,6 milioni di host esposti** > > VulnCheck ha realizzato un exploit funzionante per CVE-2026-109618 che **aggira ASLR** su x86-64 con impostazioni da produzione (`display_errors=off`) e lo ha esteso alla maggior parte delle release non corrette di 8.2, 8.3, 8.4 e 8.5, comprese le **installazioni WordPress Docker predefinite**. La sua scansione conta **2.608.039 host PHP esposti su internet**, praticamente tutti vulnerabili o probabilmente vulnerabili. Dettagli in [exploit funzionanti ed esposizione](#exploit-funzionanti-ed-esposizione). > **Aggiornamento 23 ottobre: presunto bypass su 8.5.12** > > Girano segnalazioni di una RCE sulla versione corretta PHP 8.5.12. PHP ha confermato un problema residuo (**CVE-2026-115560**) che riguarda solo una configurazione particolare delle sessioni e consiglia di mantenere **`session.upload_progress.enabled=0`** **anche dopo l'aggiornamento**, fino al prossimo bugfix release. Aggiornare resta obbligatorio. Dettagli in [il presunto bypass su 8.5.12](#il-presunto-bypass-su-8512). ## In sintesi | | | | --- | --- | | **Nome** | PHP2Shell (nome non ufficiale) | | **CVE** | CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) | | **Gravità** | CVSS v4.0 9.2 per entrambe | | **Impatto** | Esecuzione di codice da remoto (RCE) non autenticata | | **Chi è a rischio** | Ogni installazione PHP che serve richieste web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed | | **Versioni corrette** | **8.5.12**, **8.4.27**, **8.3.36**, **8.2.35** | | **Versioni non supportate** | Nessuna release ufficiale; backport dei sorgenti per 7.4, 8.0 e 8.1 | | **Sfruttamento** | Primi tentativi segnalati da Cloudflare e VulnCheck (incluso un tentativo di caricare una webshell), exploit funzionante con bypass di ASLR non pubblico, nessuna compromissione confermata, non nel catalogo CISA KEV | | **Esposizione** | 2.608.039 host PHP su internet, il 99,998% vulnerabile o probabilmente vulnerabile (VulnCheck) | | **Problema residuo** | CVE-2026-115560: caso limitato legato al serializer di sessione, correzione nel prossimo bugfix release; nel frattempo `session.upload_progress.enabled=0` | ## Quali sono le due vulnerabilità Il [bollettino ufficiale](https://www.php.net/archive/2026.php#2026-10-21-5) descrive due falle nel modo in cui PHP gestisce lo stato interno delle richieste: - **CVE-2026-109618 — RCE tramite corruzione in caso di OOM**: la gestione dell'esaurimento di memoria può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte. La pulizia di fine richiesta può poi trattare quei dati non validi come validi. - **CVE-2026-109619 — RCE tramite stato globale "stantio"**: uno stato interno legato alla richiesta può sopravvivere dopo che la memoria che lo conteneva è stata liberata. Una richiesta successiva gestita dallo **stesso worker** può usare quello stato prima che la normale inizializzazione lo azzeri. Il team PHP considera il rischio **più alto per mod_php**, con un exploit dimostrato in cui una richiesta non autenticata innesca l'attacco **prima che venga eseguita qualsiasi riga dell'applicazione**. Tradotto: non importa quanto sia scritta bene la tua applicazione, il problema è nell'interprete. I dettagli tecnici completi sono negli advisory GitHub [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) e [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp). ## Exploit funzionanti ed esposizione All'inizio le falle sembravano sfruttabili in pratica solo su sistemi senza **ASLR** (la randomizzazione della memoria che nasconde dove si trovano codice e dati). Non è più così. [VulnCheck](https://www.vulncheck.com/blog/php2shell-vulnerabilities) ha costruito un exploit per CVE-2026-109618 che lavora in due fasi: prima **estrae indirizzi di memoria** dal processo vulnerabile, neutralizzando ASLR, poi li usa per ottenere l'**esecuzione di codice da remoto**. Il primo bersaglio è stato PHP 8.4.26 su x86-64 con impostazioni tipiche di produzione, compreso `display_errors=off`: nascondere gli errori non impedisce la fuga di informazioni. Al , secondo VulnCheck, l'exploit supporta (sempre con mod_php e impostazioni predefinite): | Ramo | Release vulnerabili supportate | Architetture | | --- | --- | --- | | 8.2 | 8.2.28 – 8.2.34 | x86-64 | | 8.3 | 8.3.22 – 8.3.35 | x86-64 | | 8.4 | 8.4.10 – 8.4.26 | x86-64, ARM64 | | 8.5 | 8.5.10 – 8.5.11 | x86-64, ARM64 | Funziona anche contro **WordPress nelle installazioni Docker predefinite** con quelle versioni. Lo strumento completo è disponibile solo per i clienti del servizio Initial Access Intelligence di VulnCheck (dal ), non pubblicamente. Tra le **centinaia di repository "PoC"** su GitHub, secondo VulnCheck solo pochissimi sono exploit reali; almeno un PoC pubblico aggira ASLR, ma solo su PHP 8.4.26 x86-64 con la configurazione di heap predefinita. Non è teoria: già il gli honeypot di VulnCheck hanno registrato scansioni e tentativi di sfruttamento, tra cui un tentativo di caricare una **webshell tramite `PHP_SESSION_UPLOAD_PROGRESS`**. Aspettati tentativi di massa, che il payload funzioni o meno. ### Quanti server sono esposti La scansione di VulnCheck dà l'idea della scala (copre solo gli host rilevabili, quindi è un minimo, non il totale): - **2.608.039** host esposti su internet usano PHP, circa l'1,86% dei ~140 milioni di IP che rispondono sul web; - **2.607.985 (99,998%)** sono vulnerabili o probabilmente vulnerabili: 1.474.985 dichiarano una versione precedente alla release corretta del proprio ramo e 1.133.000 nascondono la versione e sono considerati probabilmente vulnerabili; - **oltre 1,1 milioni (circa il 42%)** usano rami non più supportati e senza correzione ufficiale: oltre 700.000 sono su PHP da 3.x a 7.3 e circa 400.000 su 7.4, 8.0 e 8.1, per cui esistono solo backport dei sorgenti; - per applicazione: WordPress 469.699 host, Laravel 124.866, Joomla 26.591, Drupal 24.116. > **Nascondere la versione non protegge** > > Oltre un milione di host è stato contato come "probabilmente vulnerabile" proprio perché non espone la versione di PHP. Disattivare `expose_php` riduce il rumore, ma un attaccante non ha bisogno di conoscere la versione per provarci: invia semplicemente il payload. ## Il presunto bypass su 8.5.12 Dal diversi post su X sostengono di aver ottenuto una RCE su PHP 8.5.12, cioè proprio la versione che doveva chiudere PHP2Shell, e GitHub si è riempito di repository con presunti "PoC". La qualità delle prove è molto variabile: si va da analisi tecniche a un video di 34 secondi senza alcuna spiegazione. Il il team PHP ha pubblicato un [bollettino informativo](https://www.php.net/archive/2026.php#2026-10-23-1) che conferma **un problema residuo**, tracciato come **CVE-2026-115560**, ma lo circoscrive a una combinazione poco comune. Devono essere vere tutte queste condizioni: - la configurazione imposta `session.serialize_handler` a `php_binary` o `php_serialize`; - l'applicazione **lo cambia in `php` a runtime** con `ini_set()` prima di chiamare `session_start()`; - `session.upload_progress` è ancora attivo. Le segnalazioni del bypass parlano inoltre della necessità di un "gadget" adatto (per esempio un distruttore) nel codice dell'applicazione. PHP considera lo scenario improbabile, quindi lo correggerà nel **prossimo bugfix release regolare**, non con un'altra release d'emergenza, e pubblicherà allora il bollettino completo. Cosa fare: - **Non rimandare l'aggiornamento**: 8.5.12, 8.4.27, 8.3.36 e 8.2.35 chiudono comunque le due vulnerabilità critiche, sfruttabili senza condizioni particolari. - Imposta **`session.upload_progress.enabled=0`** in `php.ini` o nel pool FPM e riavvia i worker, **anche sulle versioni aggiornate**, fino alla prossima release. Se l'hai già fatto il 21 ottobre, lascialo così. - Verifica se il tuo codice o i plugin cambiano il serializer a runtime: ```bash grep -rn "serialize_handler" /var/www /etc/php 2>/dev/null ``` > **Non eseguire PoC trovati su GitHub** > > In episodi come questo compaiono regolarmente finti "exploit" che in realtà contengono malware per chi li esegue. Se vuoi verificare la tua esposizione, usa un ambiente di test e codice che hai letto riga per riga, mai la produzione. ## Chi è esposto In pratica: chiunque esponga su internet un'applicazione PHP. Quindi non solo applicazioni custom, ma anche tutti i CMS ed e-commerce più diffusi: - **WordPress**, **Joomla**, **Drupal** - **PrestaShop**, **Magento**, WooCommerce - framework come **Laravel** e **Symfony** - pannelli e tool di amministrazione scritti in PHP (phpMyAdmin, Roundcube, ecc.) > **Aggiornare il CMS non aggiorna PHP** > > È l'equivoco più comune: aggiornare WordPress, i plugin o il tema **non cambia la versione di PHP** del server. Sono due livelli separati. Qui la vulnerabilità è nell'interprete PHP, quindi serve aggiornare PHP (o farlo fare al tuo hosting). ## Come aggiornare ### 1. Fai l'inventario delle versioni PHP Spesso su un server convivono più versioni (CLI, FPM, pool diversi per siti diversi, container). Verificale tutte: ```bash # versione CLI php -v # tutte le versioni installate (Debian/Ubuntu) ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null # servizi FPM attivi systemctl list-units --type=service | grep -i php # versione usata dai container Docker in esecuzione docker ps --format '{{.Names}}' | xargs -I{} sh -c 'echo -n "{}: "; docker exec {} php -r "echo PHP_VERSION, PHP_EOL;" 2>/dev/null || echo "-"' ``` Per un sito WordPress, la versione effettiva usata dal web server si trova anche in **Strumenti → Salute del sito → Info → Server**. ### 2. Installa la versione corretta L'obiettivo è **8.5.12, 8.4.27, 8.3.36 o 8.2.35**, a seconda del ramo che usi. Le distribuzioni Linux e i vendor LTS hanno ricevuto le patch in anticipo, quindi i pacchetti stanno già arrivando. - **Hosting condiviso o gestito**: la patch la applica il provider. Chiedi quando sarà attiva la build corretta e verifica che la versione PHP selezionata nel pannello (cPanel, Plesk, ecc.) sia tra quelle supportate. - **Debian/Ubuntu con il repository di Ondřej Surý** (`packages.sury.org` / `ppa:ondrej/php`): i pacchetti corretti sono già disponibili. ```bash sudo apt update sudo apt install --only-upgrade 'php*' ``` - **Pacchetti della distribuzione** (Debian, Ubuntu, RHEL ufficiali, ecc.): fanno **backport** delle patch sulla versione che già usi, quindi un pacchetto corretto può mantenere un numero di versione "vecchio". Non basarti solo su `php -v`: cerca la CVE nel changelog del pacchetto o confronta la versione esatta con il bollettino della tua distribuzione. ```bash # Debian/Ubuntu: cerca le CVE nel changelog del pacchetto apt changelog php8.3-common 2>/dev/null | grep -E 'CVE-2026-10961[89]' ``` - **Repository di Remi** (`rpms.remirepo.net`): secondo il bollettino PHP **oggi non avrà aggiornamenti**. Il team PHP consiglia di passare ai pacchetti della distribuzione o di compilare dai sorgenti per poter patchare subito. - **Container**: ricostruisci le immagini dai nuovi tag ufficiali `php:*` (es. `php:8.3.36-fpm`). Scaricare la nuova immagine non basta: i container in esecuzione vanno ricreati. - **Windows**: i binari sono nella [pagina download di php.net](https://www.php.net/downloads.php?os=windows). ### 3. Riavvia e verifica Installare il pacchetto **non sostituisce i processi già in esecuzione**. Entrambe le falle vivono nei worker a lunga durata, quindi riavvia ogni pool PHP-FPM e Apache se usi mod_php: ```bash # adatta alle versioni che usi davvero sudo systemctl restart php8.3-fpm php8.4-fpm sudo systemctl restart apache2 # se usi mod_php ``` Poi verifica la versione **vista dal web server**, non quella della CLI: una pagina `phpinfo()` temporanea (da cancellare subito dopo), Salute del sito in WordPress, oppure l'header `X-Powered-By` se è attivo. Dopo l'aggiornamento **controlla i log** per individuare attività sospette avvenute prima della patch: crash e segfault dei worker PHP, richieste anomale, file nuovi nelle directory web. ### 4. Versioni non supportate (8.1, 8.0, 7.x, 5.x) Il progetto PHP non rilascia più aggiornamenti per la 8.1 e precedenti. Vista la gravità, però, il team di sicurezza ha pubblicato dei **backport minimi dei sorgenti** per [7.4](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619), [8.0](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) e [8.1](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619), per chi compila da sorgente o non ha un vendor LTS. Anche alcune distribuzioni e vendor con supporto esteso forniscono patch in backport. Per tutto ciò che è più vecchio della 7.4 non c'è nulla: migra, oppure isola l'applicazione. E in ogni caso, usa questa occasione come spinta per passare a una versione supportata (la 8.2 è in sola manutenzione di sicurezza fino a fine 2026, quindi punta a 8.4 o 8.5). ## Se non puoi aggiornare subito Il bollettino PHP è chiaro: **solo l'aggiornamento è una soluzione completa**. Le misure seguenti riducono l'esposizione a specifici percorsi di attacco ma **non rendono sicura un'installazione**. ### Contro CVE-2026-109618 (corruzione in caso di OOM) - Imposta **`memory_limit=-1`**, possibilmente in modo che le applicazioni non possano sovrascriverlo (`php_admin_value` nel pool FPM o nella configurazione di Apache), e verifica che nessun pool, directory o impostazione applicativa rimetta un limite finito. Così si elimina il fallimento controllabile del limite di memoria, ma un errore di allocazione sottostante può comunque raggiungere il percorso vulnerabile. - Imposta un **`post_max_size`** basso: `8M` per applicazioni senza upload, `32M` se gli upload servono, con `upload_max_filesize` inferiore a `post_max_size`. - Imponi limiti a livello di **web server o proxy** su dimensione della richiesta decodificata, numero di campi, parti multipart, header e profondità di annidamento, anche per le richieste senza un `Content-Length` utilizzabile. - Usa un **limite di memoria a livello di container o cgroup** come confine di disponibilità, idealmente con una policy che termini solo il worker coinvolto. **Non usare** al suo posto `RLIMIT_AS` o `RLIMIT_DATA`: possono provocare proprio l'errore di allocazione vulnerabile. Con `memory_limit=-1` una singola richiesta può consumare tutta la RAM: è proprio per questo che il limite cgroup fa parte del pacchetto. ### Contro CVE-2026-109619 (stato globale stantio) - Imposta **`session.upload_progress.enabled=0`** e **riavvia tutti i worker**. Va impostato in `php.ini`, nel pool FPM o nella configurazione del server che si applica prima del parsing della richiesta: **non affidarti** a `ini_set()` né a `.user.ini`. Blocca i percorsi confermati tramite sessione, non le altre varianti. - Su **PHP 8.5** imposta anche **`fatal_error_backtraces=0`** e riavvia i worker: blocca solo il percorso confermato tramite backtrace degli errori fatali. - Rimuovi le impostazioni non valide o deprecate applicate per singola richiesta che generano diagnostica prima dell'inizializzazione. Nascondere la diagnostica con `error_reporting`, `display_errors` o `@` **non serve**. - Correggi errori fatali e timeout di esecuzione che un attaccante può provocare, compresi i fallimenti in callback, nell'elaborazione di upload o import e nella fase di pulizia. > **session.upload_progress non è una correzione** > > Prima della release, `session.upload_progress.enabled=0` girava sui social come "il" fix. Il bollettino PHP conferma che aiuta, ma **solo contro alcuni percorsi di CVE-2026-109619**, e non fa nulla contro CVE-2026-109618. Utile come tampone, non come protezione. Dal PHP consiglia di mantenerlo **anche sulle versioni aggiornate**, a causa di CVE-2026-115560. ### Rete e danni potenziali - Per le applicazioni che non possono essere aggiornate tempestivamente, CERT-EU suggerisce di valutare **l'isolamento dalla rete pubblica**. In alternativa, mettile dietro VPN, allowlist di IP o autenticazione a monte, verificando che l'origine non sia raggiungibile direttamente aggirando questi controlli. - Cloudflare ha pubblicato [regole WAF d'emergenza](https://developers.cloudflare.com/changelog/post/2026-10-21-emergency-waf-release-cfmr/) per i percorsi di attacco noti, anche sul piano gratuito. Il suo CTO le definisce "a STOPGAP only": vedono solo il traffico che passa da Cloudflare e possono non intercettare nuove varianti. - **Riduci quello che otterrebbe un attaccante** se il server venisse compromesso: meno dati sul server, meno privilegi per l'utente PHP, niente credenziali o ruoli cloud in giro, e log inviati in un posto sicuro. ## Cronologia - **** — Il team PHP annuncia la release di sicurezza per due vulnerabilità con CVSS 9.2. - **–** — CERT-EU pubblica il bollettino 2026-018 con gli identificativi CVE-2026-109618 e CVE-2026-109619. - **** — GMO Flatt Security precisa che `session.upload_progress.enabled=0` non è una correzione completa. - **** — Cloudflare segnala i primi tentativi di sfruttamento e rilascia regole WAF d'emergenza. - **, poco prima delle 16:00 ora italiana** — PHP rilascia 8.5.12, 8.4.27, 8.3.36 e 8.2.35 insieme al bollettino di sicurezza e ai backport per 7.4, 8.0 e 8.1. - **** — Post su X e PoC su GitHub sostengono un bypass con RCE su PHP 8.5.12. - **** — VulnCheck rende disponibile ai clienti del servizio Initial Access Intelligence un exploit per CVE-2026-109618 che aggira ASLR. - **** — PHP pubblica un bollettino informativo su CVE-2026-115560 e consiglia `session.upload_progress.enabled=0` fino al prossimo bugfix release. - **** — VulnCheck estende l'exploit a 8.2, 8.3, 8.4 e 8.5 (x86-64, e ARM64 per 8.4/8.5) e alle installazioni WordPress Docker predefinite, e pubblica i dati sull'esposizione: 2,6 milioni di host PHP su internet. ## Fonti - [VulnCheck — PHP2Shell Vulnerabilities: CVE-2026-109618 and CVE-2026-109619](https://www.vulncheck.com/blog/php2shell-vulnerabilities) - [Red Hot Cyber — Milioni di server PHP nel mirino: scoperto come aggirare le difese](https://www.redhotcyber.com/post/milioni-di-server-php-nel-mirino-scoperto-come-aggirare-le-difese-e-lanciare-attacchi/) - [PHP.net — Informational advisory: Session upload progress](https://www.php.net/archive/2026.php#2026-10-23-1) - [PHP.net — Security advisory: Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5) - [GitHub — GHSA-w8hw-w9fx-j79w (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) - [GitHub — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) - [PHP.net — PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [PHP.net — Upcoming Critical PHP Security Release](https://www.php.net/archive/2026.php#2026-10-20-1) - [CERT-EU — Security Advisory 2026-018: Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018) - [The Hacker News — PHP2Shell: what actually protects you](https://thehackernews.com/2026/10/php2shell-what-actually-protects-you.html) - [Cloudflare — Emergency WAF release](https://developers.cloudflare.com/changelog/post/2026-10-21-emergency-waf-release-cfmr/) - [Serverplan — PHP2Shell: due vulnerabilità critiche in PHP](https://www.serverplan.com/blog/php2shell-due-vulnerabilita-critiche-in-php-necessario-aggiornare-i-siti-web/) - [PHP.net — Supported Versions](https://www.php.net/supported-versions.php) Per WordPress, poi, aggiornare PHP non chiude la partita: una falla distinta nella libreria Brotli, soprannominata HTTP2Shell, è stata sfruttata in laboratorio contro WordPress con PHP 8.3.36, cioè già aggiornato. Ne parlo in [HTTP2Shell: la vulnerabilità di Brotli che colpisce anche WordPress](https://diegobetto.com/http2shell-vulnerabilita-brotli-wordpress/). Se gestisci siti WordPress, approfitta di questo momento per ripassare anche la mia [checklist di sicurezza WordPress](https://diegobetto.com/wordpress-security-checklist/): aggiornare PHP chiude questa falla, ma non le altre. E se devi testare la compatibilità con una versione più recente di PHP prima di migrare la produzione, [WPDockerize](https://diegobetto.com/wpdockerize-wordpress-on-docker/) ti permette di creare un ambiente locale in pochi minuti.