Due vulnerabilità critiche di PHP, identificate come CVE-2026-109618 e CVE-2026-109619 e indicate con il nome PHP2Shell, stanno generando milioni di tentativi di sfruttamento. Le falle possono consentire a un attaccante non autenticato di eseguire codice sul server attraverso richieste HTTP appositamente costruite.
Il progetto PHP ha pubblicato aggiornamenti di sicurezza per le versioni supportate 8.2, 8.3, 8.4 e 8.5. L'avviso è insolitamente netto: non esistono mitigazioni complete e l'aggiornamento è l'unica scelta sicura. Chi gestisce un sito deve quindi controllare la versione realmente eseguita dal server, non quella indicata soltanto nel pannello di controllo.
Cloudflare spiega che il problema interessa potenzialmente server che eseguono PHP 5.4 o successivo quando un'applicazione elabora traffico HTTP costruito in modo malevolo. Gli effetti possibili comprendono esecuzione di codice, esposizione di dati e interruzione del servizio. La configurazione concreta determina comunque se un sistema è raggiungibile e sfruttabile.
Le regole di un web application firewall possono bloccare molti tentativi e ridurre il rischio durante la distribuzione delle patch. Non sono però un sostituto definitivo dell'aggiornamento: un aggressore può cambiare il formato delle richieste, usare percorsi non protetti o sfruttare servizi che non passano attraverso il filtro.
Reuters ha registrato interventi d'emergenza e disservizi in organizzazioni pubbliche e private dall'Asia all'Europa. Il numero elevato di scansioni non dimostra che ogni tentativo sia riuscito, ma segnala che gli aggressori stanno automatizzando la ricerca di server vulnerabili appena i dettagli tecnici sono diventati pubblici.
Per le piccole imprese italiane il primo passo è chiedere al fornitore hosting la versione PHP attiva e la data di applicazione della patch. Bisogna poi controllare log web, processi insoliti, nuovi account amministrativi, file modificati e traffico in uscita. Aggiornare senza cercare eventuali compromissioni pregresse può lasciare una backdoor già installata.
Prima dell'intervento è prudente creare un backup verificato e testare applicazioni e plugin in un ambiente separato, soprattutto su sistemi legacy. Ma il test non deve trasformarsi in un rinvio indefinito: le versioni PHP fuori supporto vanno migrate perché non ricevono la correzione ufficiale e restano esposte.
Un inventario accurato è essenziale perché PHP può essere presente anche dove non compare nel nome del servizio: portali interni, pannelli di amministrazione, vecchie API e applicazioni ospitate da fornitori esterni. Occorre includere ambienti di test e macchine dimenticate, spesso meno sorvegliati della produzione ma collegati alla stessa rete. La priorità cresce se il servizio è esposto direttamente a Internet.
La priorità è alta per e-commerce, portali pubblici, sistemi di prenotazione e siti che trattano dati personali. Dopo la patch conviene ruotare credenziali e chiavi se emergono indizi di intrusione, documentare l'incidente e valutare gli obblighi di notifica. Per gli utenti finali non c'è un aggiornamento del browser da fare: la responsabilità principale è di chi gestisce il server.