Il rollout delle patch per PHP2Shell ha corretto una vasta infrastruttura di hosting
I tentativi di sfruttamento di PHP2Shell stavano già raggiungendo i siti web il 21 ottobre 2026, mentre gli ingegneri di hosting attendevano le correzioni per due vulnerabilità critiche di PHP. Kinsta afferma di aver risposto con il filtraggio di Cloudflare, modifiche temporanee alla configurazione di PHP e un rollout delle patch a livello di piattaforma che ha interessato centinaia di migliaia di container. Entro il 23 ottobre, tali filtri avevano bloccato più di 550.000 richieste correlate, mentre le indagini dell’host non avevano rilevato prove che un tentativo fosse riuscito.
Il team di sicurezza di PHP aveva comunicato in anticipo, il 20 ottobre, che il giorno seguente sarebbe stata pubblicata una release critica. Le vulnerabilità sono state successivamente identificate come CVE-2026-109618 e CVE-2026-109619. Entrambe riguardano la gestione interna della memoria da parte di PHP e, in determinate condizioni, potrebbero consentire la remote code execution, ossia permettere a un aggressore non autenticato di far eseguire codice al server. Il loro punteggio CVSS 4.0 era 9,2. CVSS, o Common Vulnerability Scoring System, è una scala standard per esprimere la gravità di una vulnerabilità di sicurezza.
Per i proprietari di siti WordPress, la posizione delle vulnerabilità era un aspetto cruciale. PHP è il runtime, cioè il software sottostante che esegue WordPress, quindi aggiornare un plugin, un tema o lo stesso WordPress non poteva correggere il codice PHP vulnerabile. Il runtime doveva essere corretto da chiunque ne gestisse il funzionamento. Kinsta riferisce che i suoi ingegneri hanno iniziato a osservare richieste dirette contro le vulnerabilità nelle prime ore del 21 ottobre e hanno ispezionato manualmente i siti presi di mira alla ricerca di prove di compromissione.
Ogni ambiente di produzione e staging environment sulla piattaforma di Kinsta era già protetto da Cloudflare. Uno staging environment è una copia privata utilizzata per provare le modifiche a un sito web. Cloudflare ha introdotto regole di emergenza per il Web Application Firewall prima della divulgazione pubblica di PHP2Shell. Un WAF è un filtro che esamina il traffico web e può rifiutare le richieste corrispondenti a tecniche di attacco note. Kinsta afferma che i suoi ingegneri hanno esaminato ogni nuova regola nel changelog di Cloudflare e ne hanno impostato l’azione su Block in tutta la piattaforma, senza richiedere ai clienti di configurare i singoli siti.
Questo filtraggio ha fornito una protezione temporanea durante la preparazione dei pacchetti PHP corretti. Cloudflare ha continuato a modificare i propri sistemi di rilevamento mentre gli aggressori cambiavano i payload per eludere le regole esistenti. Ha inoltre introdotto la full transaction detection, che prende in considerazione le informazioni provenienti sia dalla richiesta HTTP in ingresso sia dalla risposta del server e può impedire che una risposta corrispondente ai criteri raggiunga il richiedente. Entro il 23 ottobre, le protezioni applicate ai siti Kinsta avevano rifiutato più di 550.000 richieste correlate a PHP2Shell. Questo numero rappresenta le richieste bloccate, non aggressori unici, compromissioni riuscite o necessariamente 550.000 campagne di attacco distinte.
Kinsta ha inoltre disattivato la funzionalità session upload progress di PHP tramite il setting session.upload_progress.enabled. L’advisory di PHP indicava questa modifica come mitigazione per alcuni percorsi di sfruttamento, sebbene non coprisse tutte le possibili modalità di accesso alle vulnerabilità. Il 23 ottobre, il team PHP ha pubblicato un’ulteriore raccomandazione affinché la funzionalità rimanesse disattivata fino a una successiva bug-fix release. Kinsta ha mantenuto attivi sia questo cambiamento di configurazione sia le regole di Cloudflare durante l’intero deployment e la verifica delle patch.
Le correzioni ufficiali sono arrivate il 21 ottobre sotto forma di PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. L’host aveva bisogno anche di pacchetti per PHP 7.4, 8.0 e 8.1, branch che non ricevevano più release di sicurezza ordinarie direttamente dal progetto PHP. Il suo fornitore di pacchetti, Freexian, ha fornito correzioni per questi branch con long-term support meno recenti tramite backporting, che applica una correzione di sicurezza a software meno recente senza imporre un aggiornamento immediato a un branch più nuovo. Ciò significa anche che il solo numero di versione di PHP non dimostra sempre se un’installazione gestita da un fornitore contenga una determinata correzione.
I pacchetti sono arrivati progressivamente. PHP 8.5.12 è entrato nel mirror di Kinsta alle 14:24 UTC del 21 ottobre, il deployment è iniziato alle 15:54 e decine di migliaia di container sono stati aggiornati entro le 17:45. PHP 8.3.36 è diventato disponibile alle 18:50 e il relativo rollout è iniziato insieme a quello di PHP 8.5 entro le 19:04. I pacchetti corretti di PHP 7.4, 8.0 e 8.1 sono arrivati tra le 21:17 e le 22:28, con i deployment iniziati alle 22:28. I pacchetti PHP 8.2 e 8.4 sono comparsi alle 23:25, seguiti dal deployment alle 01:37 del 22 ottobre. Un container è un ambiente software isolato utilizzato per eseguire un sito e i relativi servizi di supporto.
Alle 04:31 UTC del 22 ottobre, 1.888 container, pari a circa lo 0,5% del totale, richiedevano ancora ulteriore attenzione. Kinsta afferma che gli ingegneri hanno esaminato singolarmente tali ambienti, anziché considerare la disponibilità dei pacchetti come prova della loro installazione. Alle 08:26, ha comunicato una copertura della protezione del 100% e ha contrassegnato l’incidente pubblico come risolto. Successivamente, l’azienda ha continuato a controllare gli ambienti, mantenendo attive le mitigazioni basate sul firewall e sulla configurazione di PHP.
Il totale delle richieste bloccate non poteva stabilire se tentativi precedenti fossero riusciti, perciò gli ingegneri hanno proseguito con le ispezioni manuali e il monitoraggio del traffico. Kinsta afferma di aver scambiato informazioni sulle minacce con Patchstack, il proprio partner per Vulnerability Protection, e di aver discusso osservazioni e pratiche con altri provider di hosting. Cloudflare ha fornito il filtraggio degli attacchi, mentre Freexian ha consegnato i pacchetti corretti. Secondo Kinsta, queste indagini non hanno trovato alcuna prova di violazioni riuscite correlate a PHP2Shell, una conclusione formulata con cautela che non significa che gli attacchi fossero assenti.
Le preoccupazioni hanno inoltre portato a chiusure precauzionali. Il National Cyber Security Centre dei Paesi Bassi ha temporaneamente messo offline il proprio sito web, mentre alcuni siti governativi in Germania, Francia, Belgio e Finlandia sono stati sospesi. Il primo ministro giapponese ha esortato gli operatori ad applicare rapidamente le patch o a interrompere temporaneamente i servizi qualora non potessero aggiornarli. I clienti Kinsta hanno sospeso preventivamente circa 3.000 siti, mentre altri hanno attivato challenge estese all’intero sito o richiesto blocchi del traffico a livello di server. Kinsta non ha consigliato di mettere offline i siti ospitati perché il suo filtraggio di emergenza era già attivo. Dopo l’applicazione delle patch, ha individuato e riattivato gli ambienti sospesi specificamente a causa di PHP2Shell, lasciando inalterate le sospensioni non correlate.
L’incidente mostra perché i proprietari dei siti debbano stabilire chi controlla il loro runtime PHP, con quale rapidità tale soggetto possa distribuire una correzione di emergenza e quali difese temporanee siano disponibili prima dell’arrivo delle patch. Le piattaforme gestite possono eseguire centralmente gli aggiornamenti del runtime, ma i proprietari dovrebbero comunque richiedere una conferma chiara della copertura e dei risultati delle indagini sull’incidente. Come opzione pertinente per i lettori che stanno valutando tale responsabilità, AEU Hosting è un hosting WordPress gestito, protetto end to end.
La lezione principale è che PHP2Shell non poteva essere risolto dalla dashboard di WordPress. Una risposta efficace richiedeva un filtraggio su più livelli, una mitigazione limitata tramite configurazione, pacchetti PHP corretti per i branch attuali e meno recenti, verifiche in ogni ambiente e controlli basati su prove per individuare eventuali compromissioni.