Il 21 ottobre 2026 il progetto PHP ha corretto due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che permettono di eseguire codice su un server senza alcuna autenticazione. Chi ha un sito, un e-shop o un gestionale in PHP deve aggiornare subito alle versioni 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
Cosa è successo
Le due falle riguardano il modo in cui PHP gestisce la memoria mentre risponde a una richiesta web. Nel caso peggiore basta una richiesta preparata ad arte, inviata da chiunque su internet, per prendere il controllo del server con i permessi del sito. Entrambe hanno un punteggio di gravità di 9,2 su 10.
L'avviso ufficiale di PHP non lascia margini: non esistono soluzioni alternative complete, l'unica scelta sicura è aggiornare. La configurazione più esposta è quella con Apache e il modulo PHP integrato, dove i ricercatori hanno dimostrato l'attacco prima ancora che il codice del sito entri in gioco. Anche le installazioni con PHP-FPM, molto diffuse sui server moderni, rientrano tra quelle vulnerabili.
Lo stesso giorno l'agenzia americana per la cybersicurezza CISA ha chiesto di aggiornare immediatamente, partendo dai sistemi esposti su internet. Al momento della pubblicazione non aveva osservato attacchi, ma i fornitori di hosting stanno già scrivendo ai clienti di muoversi in fretta: dopo una falla di questo livello, il tempo tra l'annuncio e i primi tentativi di sfruttarla si misura in giorni.
Chi deve preoccuparsi e cosa fare
Chiunque abbia un sito WordPress, un negozio online, un gestionale o anche solo un modulo di contatto che gira su PHP. Su un hosting condiviso l'aggiornamento spetta di solito al fornitore; su un server proprio spetta a chi lo amministra. Nelle PMI, spesso, nessuno sa con certezza chi sia.
- Fai l'inventario: elenca dove gira PHP in azienda — sito, e-shop, area clienti, server noleggiati, strumenti interni.
- Controlla la versione: deve essere almeno 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure l'aggiornamento di sicurezza pubblicato dal tuo sistema operativo.
- Non dare per scontati gli aggiornamenti automatici: su Ubuntu e Debian di solito arrivano da soli, ma va verificato; alcuni pannelli di gestione dei server vanno aggiornati a mano.
- Versioni vecchie: PHP 8.1 e precedenti non ricevono più correzioni. Vanno sostituite, non rattoppate. Anche PHP 8.2 esce dal supporto il 31 dicembre 2026.
Il PHP che non sai di avere: dove entra l'AI
Molti titolari oggi creano siti, moduli e piccoli strumenti chiedendo aiuto a un assistente AI. Alla richiesta «fammi un modulo di contatto per il sito» la risposta è spesso un file PHP pronto da caricare. Funziona al primo colpo, e proprio per questo nessuno si chiede cosa sia appena finito online.
L'assistente non avvisa che da quel momento c'è un software in più da tenere aggiornato, non controlla quale versione di PHP gira sul server e non tornerà a dirti che il 21 ottobre è uscita una correzione urgente. A volte suggerisce persino di noleggiare un piccolo server e fornisce i comandi per installare tutto: un'ora dopo il sito è online, ma nessuno è stato incaricato di mantenerlo.
Non è un difetto dell'AI: fa esattamente quello che le si chiede. Il problema è che chi ha poca esperienza non sa quali domande fare. È lo stesso tema di cui abbiamo scritto parlando del rischio di improvvisare con le automazioni: costruire qualcosa che funziona è diventato facile, tenerlo sicuro nel tempo no.
Perché serve chi guarda anche la sicurezza
Usare l'AI senza esperienza non è sbagliato, è incompleto. Mancano l'inventario di cosa gira dove, gli aggiornamenti pianificati e qualcuno che legge gli avvisi di sicurezza il giorno in cui escono. È la parte meno visibile di un progetto digitale, ed è quella che evita i danni.
In Dedalix la sicurezza fa parte del progetto fin dall'inizio: sappiamo quali strumenti girano su ogni server che gestiamo, installiamo solo ciò che serve e seguiamo gli avvisi dei fornitori. Quando è arrivata la notizia di queste due falle, verificare i nostri ambienti ha richiesto minuti, non giorni. Con la formula continuativa di manutenzione lo stesso lavoro lo facciamo per i nostri clienti.
Fonti
- PHP.net — avviso di sicurezza del 21 ottobre 2026
- PHP su GitHub — CVE-2026-109618
- PHP su GitHub — CVE-2026-109619
- CISA — Critical Vulnerabilities in PHP Require Immediate Patching
Domande frequenti
Cos'è PHP2Shell e quale versione di PHP è sicura?
PHP2Shell è il soprannome delle due vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619, corrette il 21 ottobre 2026: permettono di eseguire codice sul server da remoto, senza password. Sono sicure PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 o successive: chi usa PHP 8.4, per esempio, deve aggiornare PHP almeno alla 8.4.27.
Come faccio a sapere se il mio sito usa PHP?
Se il sito è fatto con WordPress, Joomla, Drupal, PrestaShop o WooCommerce, usa PHP. Lo usa anche un modulo di contatto caricato a mano come file .php. Nel dubbio, chiedi al fornitore di hosting quale versione di PHP è attiva sul tuo spazio: è una domanda da due minuti.
Il mio sito è su un hosting condiviso: devo aggiornare PHP io?
Di solito il fornitore di hosting aggiorna PHP per tutti i clienti, ma conviene verificarlo nel pannello di controllo: alcuni lasciano scegliere la versione e tengono attive anche quelle vecchie. Se il sito gira ancora su PHP 8.1 o precedente, va spostato su una versione supportata.
Per la sicurezza del sito WordPress basta aggiornare WordPress?
No. Le due falle sono in PHP, il linguaggio su cui WordPress gira, non nei plugin né nel tema. Aggiornare WordPress resta una buona abitudine, ma la correzione delle vulnerabilità PHP arriva solo aggiornando PHP sul server che ospita il sito.
Ho creato il sito con l'aiuto dell'AI: sono più a rischio?
Non per forza. Il rischio cresce quando nessuno sa cosa è stato messo online, su quale server o hosting e chi lo aggiorna. Un controllo di sicurezza fatto da chi conosce il mestiere chiarisce in poco tempo cosa gira, dove e chi ne è responsabile.