La correzione di PHP2Shell è disponibile, ma per la maggior parte dei siti che ne hanno bisogno non c’è alcun pulsante da premere. Le falle si trovano in PHP, il motore che fa funzionare ogni pagina di WordPress, Joomla e Drupal, a un livello sottostante al CMS, ai suoi plugin e alla schermata di accesso. Aggiornare WordPress non serve a correggerle. L’interprete aggiornato deve arrivare da chi gestisce il server: la società di hosting, il pacchetto della distribuzione Linux o l’immagine del container. Fino ad allora, il sito resta esposto, qualunque cosa faccia il suo proprietario.

È questo l’aspetto della vicenda che i titoli con «aggiorna subito» trascurano. Il team di PHP ha fatto il suo lavoro. Portare il risultato su un determinato server dipende da una catena di distribuzione che procede alla velocità del suo anello più lento, e il primo giorno ha mostrato quanto siano distanti tra loro questi passaggi. Chi non sa da dove provenga la propria versione di PHP non può capire quanto il proprio sito sia ancora esposto.

Perché un aggiornamento di WordPress non risolve il problema

Poiché i bug si trovano nell’interprete, l’avviso di sicurezza di PHP riguarda tutte le installazioni che gestiscono richieste web: da PHP-FPM e mod_php di Apache a php-cgi, FrankenPHP e LiteSpeed. The Hacker News osserva che si può attaccare perfino una semplice pagina «Hello World» eseguita su una versione vulnerabile. Il caso peggiore riguarda mod_php: una sola richiesta inviata da una persona senza account può innescare l’attacco prima ancora che venga eseguito il codice dell’applicazione, perciò né i plugin di sicurezza né la schermata di accesso possono rilevarlo.

Wordfence, azienda che si occupa di sicurezza per WordPress, ha spiegato ai proprietari dei siti, come riportato da The Verge, che la correzione non può arrivare tramite gli aggiornamenti automatici e che devono scoprire chi è responsabile della loro versione di PHP. Laravel Forge ha comunicato lo stesso ai propri clienti a proposito dei suoi server: gli aggiornamenti di sicurezza automatici non correggono PHP e gli aggiornamenti non presidiati di Ubuntu scaricano soltanto i pacchetti dal repository ufficiale di Ubuntu, non dai repository di terze parti da cui Forge installa PHP.

Le diverse fonti dei pacchetti non si sono aggiornate tutte insieme. Il giorno del rilascio, il servizio di gestione dei siti mySites.guru ha riferito che EasyApache 4 di cPanel aveva reso disponibili build corrette nel giro di pochi minuti dalla pubblicazione degli avvisi, mentre la PPA di Ondřej Surý, la fonte dei pacchetti Ubuntu su cui si basa Laravel Forge, e il repository di Remi non ne avevano ancora. InMotion Hosting ha dichiarato che i suoi server condivisi e quelli dedicati a WordPress erano in attesa delle build di CloudLinux. Tra i siti attivi monitorati da mySites.guru, alle 13:52 UTC solo lo 0,08% risultava usare una versione di PHP corretta.

Il numero di versione può trarre in inganno

Verificare la versione è meno semplice che limitarsi a leggerne il numero. Ubuntu, Debian e Red Hat applicano le correzioni di sicurezza a versioni precedenti senza modificare la versione originale del software: un server Ubuntu 24.04 corretto continua quindi a indicare il pacchetto 8.3.6. The Hacker News, citando Debian, consiglia di cercare il CVE nel changelog del pacchetto anziché fidarsi del numero di versione. mySites.guru segnala un’altra insidia: il binario PHP che risponde al comando php -v nella riga di comando spesso non è quello che serve le pagine, quindi bisogna controllare la versione segnalata dal sito stesso.

La correzione deve poi essere caricata. L’avviso di PHP e Forge sottolineano entrambi che occorre riavviare Apache, PHP-FPM e tutti i processi di lunga durata. I processi in background, come quelli che gestiscono le code, continuano a usare il vecchio interprete finché non vengono riavviati, anche se i file corretti sono già presenti sul disco.

Chi non riceverà una correzione ufficiale

Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 e risolvono CVE-2026-109618 e CVE-2026-109619, entrambe valutate 9,2 secondo CVSS v4.0. Per PHP 8.1 e le versioni precedenti, il progetto PHP non offre nulla, salvo correzioni minime riportate nel codice sorgente per le versioni 7.4, 8.0 e 8.1, destinate a chi compila PHP autonomamente. Alcuni fornitori colmano la lacuna: InMotion afferma che cPanel ha applicato le correzioni alle proprie versioni dalla 7.4 alla 8.1 e che CloudLinux sta correggendo tutte le versioni distribuite, mentre CentOS 7 non riceverà alcuna correzione.

Non si tratta di un gruppo ristretto di siti. Il giorno prima del rilascio, il 22,7% dei siti Joomla e WordPress attivi monitorati da mySites.guru usava PHP 8.1 o una versione precedente, mentre il 16,6% era ancora fermo a PHP 7 o a una versione ancora più vecchia. L’azienda attribuisce parte del problema a WordPress, che raccomanda PHP 8.3 ma indica ancora la 7.4, ormai fuori supporto da tempo, come versione compatibile. PHP 8.2 ha ricevuto questa correzione, ma il suo supporto di sicurezza terminerà il 31 dicembre 2026.

Cosa blocca l’impostazione temporanea

La soluzione temporanea circolata prima del rilascio, impostare session.upload_progress.enabled=0, esiste davvero, ma risolve solo una parte del problema. PHP afferma che blocca i percorsi attraverso le sessioni confermati per CVE-2026-109619, ma non le altre varianti, e che va impostata in php.ini o nella configurazione del server o del pool, prima di riavviare tutti i processi. In PHP 8.5, fatal_error_backtraces=0 chiude un altro percorso confermato. Nessuna delle due impostazioni interviene su CVE-2026-109618: per questa falla PHP suggerisce un memory_limit=-1 non sovrascrivibile, un valore basso per post_max_size e limiti alla dimensione delle richieste configurati sul server web o sul proxy. La stessa PHP precisa che non esistono misure di mitigazione complete. InMotion osserva che WordPress, Joomla, Drupal, Magento e PrestaShop non usano l’avanzamento dei caricamenti, quindi disattivarlo non provoca problemi a queste piattaforme.

Cloudflare ha attivato regole firewall per tutti i piani, una misura tampone, come l’ha definita il suo direttore tecnologico, Dane Knecht. Come fa notare mySites.guru, queste regole sono utili solo se il server che si trova dietro Cloudflare rifiuta il traffico che aggira il servizio e raggiunge direttamente il suo indirizzo IP.

Gli attacchi finora

watchTowr afferma che i suoi honeypot hanno registrato tentativi di sfruttamento di entrambe le falle il giorno del rilascio e che Cloudflare ha visto gli aggressori modificare i payload per eludere le sue regole. Nessuna fonte ha confermato la compromissione riuscita di un server specifico. Alcuni operatori non hanno voluto correre rischi: secondo The Hacker News, BambooHR ha messo offline il proprio servizio e alcuni servizi pubblici olandesi, tra cui DigiD, sono diventati irraggiungibili a titolo precauzionale. Il CERT dell’UE e il National Cyber Security Centre del Regno Unito hanno consigliato alle organizzazioni impossibilitate ad applicare la correzione di isolare le applicazioni esposte o di metterle offline.

Le falle sono state scoperte da Wiz Research, Calif e dal team Codex Security di OpenAI. Secondo la PHP Foundation, alcuni indizi relativi alla falla di memoria erano emersi in un audit del 2024, ma la correzione è rimasta bloccata per mesi, un ritardo che la fondazione ha definito «un fallimento strutturale». I ricercatori affermano che i modelli di IA hanno contribuito a trasformare bug vecchi di dieci anni in exploit funzionanti nel giro di circa una settimana.

Per distribuire questa correzione, PHP ha avuto bisogno di un audit, di mesi di stallo e di una fuga di notizie. Per un sito su hosting condiviso, l’ultimo passaggio è aprire un ticket all’assistenza.

Tag: Cloudflare, PHP, PHP2Shell, vulnerabilità, WordPress