Due vulnerabilità critiche in PHP: cosa fare, e cosa abbiamo fatto noi

Cosa è successo

Il 20 ottobre 2026 la notizia di due vulnerabilità critiche in PHP è circolata in rete prima del previsto, e il team di PHP ha preannunciato un rilascio di sicurezza straordinario (Huntress). Il 21 ottobre, nel pomeriggio ora italiana, sono uscite le versioni corrette; in serata i ricercatori hanno pubblicato i dettagli tecnici.

Le due falle si chiamano CVE-2026-109618 e CVE-2026-109619, e qualcuno le ha ribattezzate PHP2Shell. Entrambe hanno un punteggio CVSS v4 di 9,2 su 10 e permettono, nelle condizioni giuste, di eseguire codice sul server senza autenticazione (Rapid7). Anche il CERT-EU, il centro per la sicurezza informatica delle istituzioni europee, ha pubblicato un avviso (CERT-EU).

Perché riguarda quasi tutti

PHP è il linguaggio con cui funzionano WordPress, WooCommerce e una gran parte dei gestionali web. Non si vede, perché lavora sul server, ma è lì: un sito curato e aggiornato nei plugin resta esposto se la versione di PHP del server è vulnerabile.

Secondo il team di PHP sono a rischio tutte le installazioni che servono pagine web, con qualsiasi configurazione: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed (Huntress). Le due falle sfruttano la gestione della memoria esaurita e uno stato lasciato in memoria tra una richiesta e l'altra; oltre all'esecuzione di codice, i ricercatori hanno dimostrato la lettura della memoria del processo, dove possono trovarsi password, token e chiavi di accesso (Qualys).

Qualys riporta tentativi di attacco già osservati in rete, segnalati da Cloudflare, Amazon e da alcuni hosting (Qualys). Rapid7 raccomanda di aggiornare in emergenza, fuori dai normali cicli di manutenzione.

Le versioni da installare

Le versioni corrette sono queste (Rapid7):

Attenzione ai pacchetti delle distribuzioni Linux: spesso portano la correzione mantenendo il vecchio numero di versione, quindi conta l'avviso del fornitore, non il numero che si legge sul server. È considerata risolutiva solo una versione che contiene entrambe le correzioni.

Se il server non si può aggiornare subito

Capita più spesso di quanto si pensi: sistemi operativi fuori supporto, versioni di PHP vecchie richieste da un gestionale, server che nessuno vuole toccare. In questi casi esistono misure temporanee che riducono l'esposizione, ma non sostituiscono l'aggiornamento (Rapid7, Huntress):

• disattivare session.upload_progress nella configurazione del server (php.ini o pool FPM), non dall'applicazione, e riavviare i processi PHP;
• su PHP 8.5, disattivare fatal_error_backtraces allo stesso livello;
• limitare la dimensione delle richieste in ingresso, per esempio con post_max_size e con regole sul web server o sul firewall applicativo;
• mettere il server dietro un firewall applicativo o una VPN, o toglierlo da Internet se non serve che sia pubblico;
• controllare se i processi PHP avviano shell o programmi di download, e conservare i log per le verifiche a ritroso.

Nascondere gli errori con display_errors o error_reporting non protegge: il problema si verifica comunque.

Come ci siamo mossi noi

Gestiamo siti, e-commerce e gestionali in PHP per clienti in sanità, editoria, turismo e servizi. Il giorno della correzione abbiamo seguito questo ordine:

1. 01

   Inventario prima della patch

   La mattina del 21 ottobre, prima del rilascio, abbiamo verificato le versioni di PHP in uso su ogni server, per sapere già dove intervenire quando la correzione sarebbe uscita.

2. 02

   Log al sicuro

   Abbiamo messo da parte i log dei giorni precedenti, così da poter cercare tentativi di attacco a ritroso una volta pubblicati i dettagli tecnici.

3. 03

   Un avviso chiaro a ogni cliente

   Tra le 9.48 e le 10.47 abbiamo scritto a nove clienti, ognuno con l'elenco dei propri sistemi coinvolti: cosa succede, cosa facciamo noi, cosa devono fare loro. Quasi sempre niente.

4. 04

   Aggiornamento dove possibile

   Sui server con un sistema operativo supportato, aggiornamento di PHP appena disponibile il pacchetto corretto, partendo da quelli con dati personali e sanitari, poi la verifica che pagine, moduli e pagamenti funzionino come prima.

5. 05

   Mitigazioni dove l'aggiornamento non basta

   Sui server con sistemi operativi datati abbiamo applicato le mitigazioni indicate dal CERT-EU, messo le applicazioni dietro Cloudflare, chiuso all'esterno database e servizi interni, spento vecchi siti di prova ancora raggiungibili e attivato gli aggiornamenti automatici di sicurezza.

Su uno degli ambienti più esposti la verifica non ha trovato tracce di intrusione né modifiche sospette. Le mitigazioni hanno però un costo visibile: con il limite sulle richieste, per esempio, non si possono più caricare file oltre i 30 MB. Per quei server la soluzione definitiva è il passaggio a macchine nuove con un sistema operativo supportato, che stiamo pianificando con i clienti.

Cosa insegna un giorno come questo

• Sapere cosa si ha. Senza un inventario aggiornato di server e versioni, il primo giorno si passa a cercare invece che a correggere.
• Avvisare per primi. Un cliente che legge la notizia altrove e non ha sentito il suo fornitore si preoccupa il doppio.
• Dare priorità ai dati. Un modulo dove le persone scrivono dati personali o sanitari va messo in sicurezza prima di una pagina vetrina.
• Aggiornato non vuol dire funzionante. Ogni aggiornamento va seguito da una verifica, e ogni restrizione nuova va comunicata.
• Un server vecchio è un debito. Le mitigazioni comprano tempo; prima o poi la migrazione va fatta, ed è meglio farla con calma che il giorno della prossima vulnerabilità.

Domande frequenti

Fonti

1. Rapid7, CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP
2. Qualys, PHP2Shell: PHP Patches Two Critical RCE Vulnerabilities
3. Huntress, php2shell: Leaked Critical PHP Vulnerabilities
4. CERT-EU, Security Advisory 2026-018