Ieri mattina un cliente ti ha scritto: «Ho letto di un problema grave su PHP, siamo a posto?». La risposta istintiva è «i plugin li aggiorniamo ogni settimana». Su questa vulnerabilità PHP è la risposta sbagliata: le falle stanno sotto WordPress, e il tuo contratto di manutenzione probabilmente non arriva fin lì.
Cosa ha annunciato il progetto PHP il 21 ottobre?
Il 21 ottobre il progetto PHP ha pubblicato sul sito ufficiale un avviso di sicurezza: le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 correggono due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che possono permettere di eseguire codice sul server senza autenticazione. L'invito è ad aggiornare subito.
Sono a rischio, scrive il progetto, tutte le installazioni PHP che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto è su mod_php, dove un exploit dimostrato parte prima che giri una sola riga dell'applicazione.
Le distribuzioni Linux e i fornitori LTS hanno ricevuto le correzioni in anticipo. PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto: per 7.4, 8.0 e 8.1 ci sono solo backport minimi per chi compila dai sorgenti. Le mitigazioni elencate per chi non può aggiornare subito, avverte l'avviso, riducono l'esposizione ma non rendono l'installazione sicura.
Cloudflare aggiunge due cose: le falle erano trapelate prima della data ufficiale e ha visto traffico di attacco verso i propri clienti; dal 21 ottobre alle 3:02 UTC le regole del suo firewall applicativo proteggono di default tutti i piani con WAF, gratuito compreso. E scrive in chiaro che aggiornare il codice del sito o i plugin non risolve.
Perché aggiornare WordPress non basta?
Perché il CMS è un'applicazione che gira sopra PHP. Questa volta il problema è il motore, non la carrozzeria. Puoi avere WordPress all'ultima versione e zero plugin vecchi, e il server resta esposto finché qualcuno non aggiorna PHP.
E qui arriva la domanda scomoda per chi vende manutenzione: chi ha in mano PHP, sito per sito? Di solito la risposta è un miscuglio.
- Hosting condiviso: PHP lo aggiorna il provider. Tu puoi solo scegliere la versione dal pannello, quando il pannello te lo lascia fare.
- VPS o server gestito da te o da un tuo fornitore: l'aggiornamento è vostro, e nessuno lo farà al posto vostro.
- Siti con PHP 8.1 o più vecchio: qui la conversazione con il cliente non è più «aggiorniamo» ma «migriamo», con i test che una migrazione comporta.
Il secondo punto è il numero di versione. Leggere 8.3.30 nel pannello non dice se il sito è esposto: l'avviso stesso rimanda ai pacchetti delle distribuzioni e ai fornitori LTS, alcuni dei quali applicano le correzioni come backport. Il numero che vedi può non coincidere con quelli dell'avviso, in un senso o nell'altro. Serve la conferma di chi gestisce il server.
Terzo punto, il più delicato: il cliente pensa che la sicurezza del sito sia tua, perché paghi tu l'hosting o perché lo hai consigliato tu. Se il contratto non dice dove finisce la tua manutenzione, lo scoprirete insieme il giorno in cui qualcosa va storto. È lo stesso discorso che avevo fatto sul contratto di manutenzione WordPress, un piano più sotto.
Cosa fare questa settimana sui siti dei clienti?
- Fai l'elenco dei siti PHP che segui, con tre colonne: dove sono ospitati, chi aggiorna PHP, che versione dichiarano. È un'ora di lavoro e ti serve comunque.
- Chiedi a ogni hosting una conferma scritta che le correzioni per CVE-2026-109618 e CVE-2026-109619 sono applicate, con la data. Una mail con la risposta vale più di un numero letto nel pannello.
- Sui server gestiti da te o da un tuo fornitore, aggiorna a una versione corretta o al pacchetto della distribuzione che la include. Sui siti fermi a PHP 8.1 o prima, porta al cliente oggi stesso la proposta di migrazione.
- Se un sito passa da Cloudflare, controlla che il traffico passi davvero dal proxy e non solo dal DNS. È una protezione in più mentre aspetti la conferma dell'hosting, non un posto dove fermarsi.
Cosa non fare con la vulnerabilità PHP2Shell?
- Non spegnere i siti con un errore qualunque. Secondo Reuters, ripresa da Search Engine Roundtable, in Europa diversi siti pubblici sono stati messi offline per precauzione. Se lo fai su un sito di un cliente, John Mueller di Google consiglia un HTTP 503, anche impostato fuori da PHP con DNS o CDN, invece di lasciare timeout, 404 o 500.
- Non rispondere al cliente «abbiamo aggiornato tutto» se hai aggiornato WordPress. È vero per quello che controlli tu, e falso per la parte che conta questa settimana.
Non è un'emergenza da gestire con il panico, ma con un elenco e qualche mail. Quello che resta dopo, scritto nel contratto, vale più della patch.
Fonti: Security advisory - Critical remote code execution vulnerabilities, update now — php.net, 21 ottobre 2026 · Cloudflare deploys protections against php2shell vulnerability — Cloudflare, 21 ottobre 2026 · Post di John Mueller su Bluesky, 21 ottobre 2026 · Google On Taking Sites Down When Fixing The Emergency PHP Exploit — Search Engine Roundtable, 21 ottobre 2026
Articolo scritto con un assistente AI a partire da fonti primarie, pubblicato in automatico e riletto da Stefano Scaffidi Domianello dopo la pubblicazione. Segnalazioni: stefano@scafnet.it