Sicurezza informaticaServerWeb

PHP sotto attacco: CVE-2026-109618 e CVE-2026-109619 (php2shell), cosa fare subito per non farsi prendere il server

21 ottobre 2026

Oggi, mercoledì 21 ottobre 2026, alle 14:00 UTC (le 16:00 in Italia) il team di PHP rilascia una patch di sicurezza straordinaria per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619. Chi gestisce un sito o un'applicazione in PHP ha poche ore per prepararsi. E non è un modo di dire: chi si occupa di e-commerce si aspetta i primi attacchi di massa entro quindici minuti dalla pubblicazione delle correzioni.

La differenza rispetto alle solite falle dei plugin è che qui il problema non sta nel codice del sito, ma nell'interprete PHP stesso. WordPress aggiornato, plugin affidabili, codice scritto bene: se il PHP sotto è vulnerabile, tutto questo non basta.

Qui sotto trovate cosa sappiamo davvero (separato da quello che circola senza conferme), chi rischia e soprattutto cosa fare, prima e dopo le 16:00.

Cosa è confermato e cosa no

In una vicenda come questa la prima cosa da fare è distinguere i fatti dalle voci.

Confermato:

Il 20 ottobre il progetto PHP ha annunciato sul proprio sito una release di sicurezza per due vulnerabilità critiche, entrambe con punteggio CVSS v4.0 di 9,2, programmata per il 21 ottobre alle 14:00 UTC. L'annuncio invita tutti gli utenti a "prepararsi ora" e si riserva di anticipare il rilascio se i dettagli diventassero pubblici.
CERT-EU ha pubblicato l'avviso 2026-018: secondo il punteggio assegnato, le falle potrebbero consentire esecuzione di codice da remoto senza autenticazione. La raccomandazione è di prepararsi a patchare subito e, dove non è possibile, valutare di isolare dalla rete pubblica le applicazioni esposte finché la correzione non è installata.
La società di sicurezza watchTowr dichiara di aver riprodotto lo sfruttamento di CVE-2026-109618 e di non voler divulgare dettagli prima della patch.
Al momento non risultano attacchi reali basati su queste falle.

Non confermato:

Le versioni coinvolte. CERT-EU scrive che "potrebbero" essere tutte quelle da PHP 5 in poi; altre fonti parlano di PHP 5.4 e successive. Il progetto PHP non lo ha ancora detto.
La causa tecnica. Le ricostruzioni non ufficiali puntano alla gestione delle richieste multipart/form-data (quelle dei moduli e dell'upload di file) e in particolare al meccanismo di session upload progress, che PHP usa per tracciare l'avanzamento dei caricamenti ed è attivo di default.
Il nome php2shell non è ufficiale: è quello usato dai ricercatori e negli strumenti dimostrativi circolati online.

La notizia è uscita prima del previsto: l'embargo è saltato il 20 ottobre, con un post su Hacker News poi cancellato. Per questo il progetto PHP ha anticipato l'annuncio.

Perché è così grave

Su un normale server web la richiesta del browser arriva ad Apache o Nginx, che la passa all'interprete PHP (spesso tramite PHP-FPM). PHP legge i dati in arrivo, li prepara per l'applicazione, esegue il codice e restituisce la pagina.

Il principio su cui si regge tutto è semplice: ciò che arriva dall'esterno (un campo di un modulo, un cookie, un file caricato) deve restare dato, mai diventare istruzione. Una vulnerabilità di tipo RCE (Remote Code Execution) è proprio la rottura di questa separazione.

Se le ipotesi sono corrette, qui la rottura avviene mentre PHP sta ancora analizzando la richiesta, prima che il vostro codice venga eseguito. Questo spiega tre cose:

Non conta quale CMS usate. Le dimostrazioni circolate parlano di WordPress, Drupal e Magento; Sansec cita anche Shopware e WooCommerce. Il punto è che il problema sta sotto l'applicazione.
Non si sistema dal codice del sito. Come scrive Sansec, non lo potete correggere dentro la codebase del vostro negozio: va aggiornato PHP a livello di infrastruttura.
Basta una richiesta. Se lo sfruttamento non richiede autenticazione, qualsiasi server PHP raggiungibile da Internet è un bersaglio, e la scansione automatica di milioni di siti è questione di ore.

Cosa succede dopo? L'attaccante esegue codice con i permessi del processo PHP (per esempio l'utente www-data). Non è root, ma spesso basta: può leggere il file di configurazione con le credenziali del database, modificare pagine, caricare una web shell per tornare quando vuole, iniettare skimmer di carte di credito negli e-commerce, usare il server per attaccare altri sistemi della rete interna.

Chi è esposto

Se le indicazioni preliminari saranno confermate, praticamente chiunque usi PHP. Con una distinzione importante:

PHP 8.2, 8.3, 8.4 e 8.5 sono le versioni ancora supportate dal progetto e riceveranno la patch ufficiale.
PHP 8.1 e precedenti sono fuori supporto: non ci sarà una correzione ufficiale. Si dipende dal backport della propria distribuzione (Debian LTS, Red Hat, fornitori di supporto esteso) o dall'hosting. Altrimenti resta solo la migrazione.

E attenzione a dove PHP si nasconde: siti di staging, vecchi gestionali interni, pannelli di amministrazione, phpMyAdmin dimenticati, container con immagini mai ricostruite. Sono quelli che nessuno aggiorna e che un attaccante trova per primi.

Cosa fare adesso, prima della patch

1. Fate l'inventario (vero)

Non basta sapere che versione di WordPress avete: serve sapere che versione di PHP sta servendo davvero le pagine. Il php -v da terminale mostra la versione a riga di comando, che può essere diversa da quella di PHP-FPM o del modulo Apache.

php -v                                   # versione CLI
ls /etc/php/                             # versioni installate (Debian/Ubuntu)
systemctl list-units 'php*-fpm*'         # quali FPM sono attivi

Per ogni sito, la verifica affidabile è dal web: una pagina temporanea con <?php phpinfo(); da cancellare subito dopo, oppure l'intestazione X-Powered-By se è attiva. Elencate tutto: produzione, staging, interni, container.

2. Applicate la mitigazione temporanea

La misura più citata (Sansec, GMO Flatt Security e altri) è disattivare il tracciamento dell'avanzamento degli upload. Gli upload continuano a funzionare; smettono solo le eventuali barre di avanzamento basate su questa funzione, che quasi nessuno usa.

In php.ini o in un file sotto conf.d:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Oppure nel pool di PHP-FPM (per esempio /etc/php/8.4/fpm/pool.d/www.conf):

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

Poi ricaricate (systemctl reload php8.4-fpm, oppure riavviate Apache se usate mod_php) e verificate dal web che il valore risulti Off: la riga di comando legge un altro file di configurazione.

Su hosting condiviso senza accesso a php.ini: con mod_php si usa .htaccess con php_flag session.upload_progress.enabled off; con CGI/FastCGI si usa un file .user.ini (che può impiegare fino a 5 minuti per essere letto).

Siate onesti con voi stessi su cosa vale questa misura: non è confermata ufficialmente. Secondo alcuni ricercatori blocca solo una delle due falle, mentre l'altra starebbe nel parser multipart. È una riduzione del rischio per qualche ora, non una soluzione.

3. Riducete l'esposizione

È il consiglio di CERT-EU, ed è quello che funziona davvero anche senza conoscere i dettagli della falla:

togliete da Internet ciò che non deve starci: staging, aree admin, phpMyAdmin, strumenti interni. Mettetele dietro VPN o limitatele per IP;
se un'applicazione non è indispensabile oggi pomeriggio, valutate di spegnerla fino all'aggiornamento;
se avete un WAF o un reverse proxy, preparate regole sulle richieste multipart/form-data verso endpoint che non ricevono upload. Con cautela: un blocco indiscriminato rompe moduli e funzioni legittime e non garantisce copertura completa.

4. Preparate l'aggiornamento

Sapete già da dove arriverà la nuova versione? Repository della distribuzione (il security team di Debian o Ubuntu potrebbe pubblicare qualche ora dopo il progetto PHP), repository di terze parti come quello di Ondřej Surý, pannello dell'hosting, immagini Docker ufficiali. Se il server lo gestisce un fornitore, chiamatelo stamattina e chiedete a che ora installerà la patch.

5. Fate un backup e guardate i log

Un backup recente di file e database vi serve in ogni caso. E tenete d'occhio da adesso gli accessi: richieste POST multipart anomale verso pagine che non ricevono upload, errori PHP insoliti, processi figli di PHP-FPM che lanciano shell.

Cosa fare dopo le 16:00

Aggiornate appena la versione corretta è disponibile per il vostro canale (distribuzione, repository, hosting, immagine Docker).
Riavviate PHP-FPM (o Apache con mod_php). I processi già in esecuzione continuano a usare il vecchio codice finché non vengono riavviati.
Ricostruite i container: aggiornare l'immagine base non serve se poi il container gira ancora con quella vecchia.
Verificate dal web che la versione servita sia quella corretta, sito per sito.
Controllate di non essere già stati colpiti, soprattutto se avete aggiornato tardi:

# file PHP creati o modificati negli ultimi 2 giorni dentro il sito
find /var/www -name '*.php' -mtime -2 -ls
# file PHP nelle cartelle di upload (non dovrebbero esserci)
find /var/www -path '*upload*' -name '*.php*' -ls
# cron aggiunti all'utente del web server
crontab -u www-data -l

Se trovate qualcosa di sospetto non limitatevi a cancellarlo: cambiate le password del database e le chiavi API presenti nei file di configurazione, perché vanno considerate lette.

Quando la mitigazione temporanea non serve più, decidete con calma se riattivare session.upload_progress. Probabilmente non vi serviva prima e non vi servirà dopo.

Se siete fermi a PHP 7 o 8.0/8.1

È il caso più scomodo, ed è più frequente di quanto si pensi: gestionali scritti dieci anni fa, plugin che "non funzionano" sulle versioni nuove, server che nessuno vuole toccare.

Le strade sono tre: un backport della distribuzione o di un fornitore di supporto esteso, se esiste; l'isolamento completo dell'applicazione (niente accesso da Internet, solo VPN); la migrazione a una versione supportata. Quello che non si può fare è lasciare il server esposto e sperare.

La lezione di php2shell

Questa vicenda ripete una cosa che chi fa sicurezza dice da anni: aggiornare l'applicazione non basta, se i componenti sotto restano vulnerabili. Interprete, server web, librerie, sistema operativo sono tutti parte della superficie d'attacco.

E ne aggiunge un'altra: quando tra la pubblicazione della patch e i primi attacchi passano quindici minuti, la sicurezza non può dipendere solo dalla velocità con cui si aggiorna. Le applicazioni che non devono essere pubbliche non devono essere raggiungibili da chiunque. È il principio su cui abbiamo costruito ZTAG: filtrare e autenticare il traffico prima che arrivi all'applicazione, così che una falla nell'interprete non sia raggiungibile dal primo scanner che passa.

Per oggi, però, la priorità è una sola: sapere dove gira PHP, mitigare adesso e aggiornare alle 16:00.

Articolo scritto la mattina del 21 ottobre 2026, prima del rilascio delle correzioni. Versioni coinvolte e dettagli tecnici saranno chiariti dalle note ufficiali del progetto PHP.