Le patch d’emergenza di PHP espongono le fragili fondamenta del web

Cosa succede quando un linguaggio che alimenta silenziosamente gran parte del web ha bisogno di un aggiornamento di sicurezza d’emergenza, mentre gli attaccanti hanno già i dettagli dell’exploit? È questa la domanda scomoda dietro l’ultima crisi di PHP. Il pericolo non consiste soltanto nell’esistenza di due bug critici. Il problema è che le persone incaricate di risolverli potrebbero essere separate dai sistemi vulnerabili da livelli di hosting provider, pannelli di controllo, plugin, codice legacy e server dimenticati.

Il problema immediato è una coppia di vulnerabilità di esecuzione di codice da remoto senza autenticazione, CVE-2026-109618 e CVE-2026-109619, entrambe con un punteggio CVSS di 9,2. The Hacker News riporta che le falle sono state divulgate prima delle patch d’emergenza di PHP, con un aggiornamento di sicurezza previsto per il 21 ottobre 2026. Secondo quanto riferito, un proof of concept trapelato è stato associato al nome “PHP2Shell”.

La tempistica conta. Quando una vulnerabilità viene divulgata dopo la disponibilità di una patch, i responsabili della difesa devono affrontare una corsa che almeno possono comprendere. Quando una vulnerabilità viene esposta prima della correzione, ogni installazione non mantenuta diventa un punto interrogativo. E PHP non è un’applicazione desktop isolata in attesa che qualcuno faccia clic su “aggiorna”: è integrato in stack web gestiti da società di hosting, agenzie, piccole imprese oppure da nessuno che ricordi ancora le credenziali di accesso.

Il vero rischio è la distanza tra PHP e chi deve applicare la patch

L’importanza di PHP è esattamente ciò che rende difficile questo episodio. Si trova sotto i sistemi di gestione dei contenuti e i plugin, spesso invisibile al proprietario del sito. Un amministratore di WordPress può ragionare in termini di temi, estensioni e aggiornamenti nella dashboard, mentre l’interprete sottostante viene scelto tramite cPanel, un piano di hosting o un’immagine server.

Questa divisione delle responsabilità è efficiente quando tutto viene mantenuto correttamente. Diventa pericolosa quando la titolarità non è chiara. Il provider può controllare il runtime, il cliente può controllare WordPress e uno sviluppatore il codice personalizzato. Se un livello è fermo a una versione obsoleta, l’intero sito eredita il rischio.

Le prove disponibili indicano anche una trappola ben nota: si scambia “il sito funziona ancora” per “il sito è sicuro”. PHP 8.2 dovrebbe terminare il supporto ufficiale il 31 dicembre 2026, mentre PHP 8.3, 8.4 e 8.5 risultano tra i rami supportati a settembre 2026. Una recente analisi dello stato del supporto di PHP sottolinea un aspetto pratico: passare a un ramo più recente può creare problemi di compatibilità con temi e plugin.

Questo non è un argomento per rimandare gli interventi di sicurezza. È un argomento per considerare i test di compatibilità come normale manutenzione, non come una scusa per rimanere esposti a tempo indeterminato.

Una patch di WordPress non può riparare uno stack PHP non gestito

Il recente incidente di WordPress mostra perché gli aggiornamenti delle applicazioni siano necessari, ma non sufficienti. WordPress 7.1.2, rilasciato il 22 settembre 2026, ha corretto CVE-2026-87902, una vulnerabilità critica non autenticata di path traversal e inclusione di file locali che interessava le versioni dalla 4.7.0 alla 7.1.1. In specifiche condizioni legate al tema e al server, la vulnerabilità poteva portare all’esecuzione di codice da remoto.

Nel giro di poche ore dalla correzione sarebbero state osservate richieste dannose e TurboLab ha riportato che il traffico d’attacco si è moltiplicato nel corso del giorno successivo. La lezione non è che WordPress sia particolarmente negligente. È che una patch pubblica dell’applicazione mette immediatamente in evidenza la qualità dell’ambiente circostante: configurazione di PHP, file locali leggibili, permessi del server e anzianità dell’installazione.

PHP2Shell solleva la stessa questione un livello più in basso. Aggiornare WordPress non applicherà patch a PHP. Aggiornare PHP potrebbe rompere un plugin trascurato. Aggiornare il plugin potrebbe richiedere una versione più recente di WordPress. Questa è una catena di dipendenze e il web ha passato anni a fingere che fosse un insieme di caselle indipendenti da spuntare.

La nostra posizione è che l’hosting condiviso sia l’anello più debole, non perché sia intrinsecamente insicuro, ma perché può rendere ambigua la responsabilità. Spesso i clienti non possono vedere quale ramo di PHP sia in esecuzione, se un provider abbia applicato l’aggiornamento d’emergenza o se vecchie scelte di configurazione lascino esposto un sistema altrimenti aggiornato.

“Applicare subito le patch” è un consiglio corretto, ma incompleto

La risposta giusta alle vulnerabilità critiche di esecuzione di codice da remoto senza autenticazione resta semplice: individuare le installazioni di PHP interessate, applicare l’aggiornamento d’emergenza del fornitore non appena disponibile e verificare la versione effettivamente in esecuzione, senza fidarsi dell’etichetta del pannello di controllo. Rimandare perché un sito sembra stabile è una scelta sbagliata.

Ma l’applicazione della patch dovrebbe avviare un’indagine, non concluderla. Gli amministratori dovrebbero censire ogni dominio e server che utilizza PHP, distinguere le versioni a riga di comando dall’interprete che serve il sito e verificare che i provider di hosting siano intervenuti. Dovrebbero inoltre esaminare log e file se è possibile che lo sfruttamento sia iniziato prima della correzione. Una patch chiude la vulnerabilità; non rimuove una web shell, non ripristina i file modificati né permette di ruotare le credenziali sottratte da un server compromesso.

Per chi gestisce WordPress, i test di compatibilità di plugin e temi devono rientrare nello stesso processo. L’obiettivo non è passare alla cieca al ramo PHP più recente. È smettere di considerare un ramo non supportato come un modello operativo permanente e stabilire un percorso ripetibile verso una configurazione supportata e compatibile.

Il web ha bisogno di garanzie di manutenzione, non di altri allarmi d’emergenza

Ogni patch d’emergenza produce lo stesso rituale pubblico: un punteggio di gravità elevato, titoli allarmistici, aggiornamenti affrettati e avvertimenti sul fatto che gli attaccanti siano già interessati. È un rituale utile, ma nasconde anche il fallimento strutturale. Il web moderno dipende da software spesso installato una volta e poi abbandonato, mentre le sue dipendenze continuano a cambiare.

PHP non è in difficoltà perché è vecchio o ampiamente utilizzato. È esposto perché la sua ubiquità rende determinante il ritardo nell’applicazione delle patch, mentre il modello operativo che lo circonda continua a dare per scontato che qualcuno, da qualche parte, controlli ogni server. È un presupposto sempre più difficile da difendere.

Il verdetto pratico è netto: se il proprietario di un sito non sa dire quale versione di PHP serve il sito e chi è responsabile delle patch, quel sito non è gestito: è semplicemente ancora online. Applica gli aggiornamenti d’emergenza, verificane l’installazione, controlla che non ci siano compromissioni e pretendi dal provider un contratto di manutenzione chiaro. La patch è urgente. La governance che la circonda è il vero lavoro di sicurezza.