PHP2Shell: due vulnerabilità critiche in PHP, aggiorna subito

Il 20 ottobre 2026 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.

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, nessuna compromissione confermata, non nel catalogo CISA KEV

Quali sono le due vulnerabilità

Il bollettino ufficiale 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 e GHSA-6wmf-4rv5-p3rp.

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.)

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:

# 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.

  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.

  # 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.

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:

# 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, 8.0 e 8.1, 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.

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 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

• 20 ottobre 2026 — Il team PHP annuncia la release di sicurezza per due vulnerabilità con CVSS 9.2.
• 20–21 ottobre 2026 — CERT-EU pubblica il bollettino 2026-018 con gli identificativi CVE-2026-109618 e CVE-2026-109619.
• 21 ottobre 2026, 07:00 ora italiana — GMO Flatt Security precisa che session.upload_progress.enabled=0 non è una correzione completa.
• 21 ottobre 2026 — Cloudflare segnala i primi tentativi di sfruttamento e rilascia regole WAF d’emergenza.
• 21 ottobre 2026, 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.

Fonti

• PHP.net — Security advisory: Critical remote code execution vulnerabilities, update now
• GitHub — GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• PHP.net — PHP 8 ChangeLog
• PHP.net — Upcoming Critical PHP Security Release
• CERT-EU — Security Advisory 2026-018: Critical Vulnerabilities in PHP
• The Hacker News — PHP2Shell: what actually protects you
• Cloudflare — Emergency WAF release
• Serverplan — PHP2Shell: due vulnerabilità critiche in PHP
• PHP.net — Supported Versions

Se gestisci siti WordPress, approfitta di questo momento per ripassare anche la mia checklist di sicurezza WordPress: 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 ti permette di creare un ambiente locale in pochi minuti.