Aggiungi come fonte preferita su Google
Il 21 ottobre 2026, gli hacker stavano già prendendo di mira i siti web con richieste pensate per sfruttare due vulnerabilità critiche di PHP note come PHP2Shell. Le patch di sicurezza ufficiali non erano ancora disponibili, ma i nostri team di ingegneri e della sicurezza stavano già lavorando per proteggere i siti web ospitati su Kinsta.
La risposta ha coinvolto diverse azioni coordinate. Il nostro team ha attivato regole di firewall Cloudflare di emergenza, modificato le configurazioni PHP e si è preparato a distribuire le patch su centinaia di migliaia di container non appena fossero state disponibili. Allo stesso tempo, il nostro team di supporto stava rispondendo a un’ondata di domande da parte dei clienti preoccupati per i propri siti web.
Entro il 23 ottobre, le nostre protezioni Cloudflare avevano bloccato più di 550.000 richieste mirate alle vulnerabilità. Avevamo anche distribuito gli aggiornamenti di sicurezza PHP necessari su tutta la nostra piattaforma di hosting e non abbiamo trovato alcuna traccia di violazioni riuscite.
Ecco come è andata, dai primi segnali di sfruttamento della vulnerabilità al rilascio delle patch e al lavoro che ne è seguito.
Prepararsi a PHP2Shell prima che le patch fossero disponibili
Il 20 ottobre, il team di sicurezza di PHP ha annunciato un imminente rilascio critico di sicurezza, previsto per il giorno successivo. L’annuncio metteva in guardia da due vulnerabilità con un punteggio di gravità CVSS 4.0 pari a 9,2 e incoraggiava gli utenti PHP a prepararsi ad aggiornare le proprie installazioni non appena le patch fossero state disponibili.
Le vulnerabilità, successivamente identificate come CVE-2026-109618 e CVE-2026-109619, riguardavano la gestione della memoria interna di PHP e, in determinate condizioni, avrebbero potuto consentire agli hacker di eseguire codice da remoto senza autenticazione.
L’annuncio era particolarmente importante per i siti WordPress perché è proprio PHP a gestire l’applicazione stessa. Aggiornare un plugin o un tema di WordPress non bastava a risolvere queste vulnerabilità. Era necessario applicare le correzioni di sicurezza al runtime PHP sottostante.
Per i provider di hosting come Kinsta, la sfida iniziale era proteggere i siti web prima che le patch ufficiali fossero disponibili. Il nostro team ha iniziato a prepararsi per il rilascio, ma i tentativi di sfruttamento erano già in corso.
Secondo Laszlo Farkas, direttore tecnico di Kinsta, il nostro team ha iniziato a rilevare richieste mirate alle vulnerabilità nelle prime ore del 21 ottobre. I tecnici hanno controllato manualmente i siti presi di mira e hanno continuato a monitorare l’attività alla ricerca di segni di una violazione riuscita.
A quel punto, avevamo già adottato misure per proteggere i siti web sulla nostra piattaforma.
Come abbiamo attivato le regole WAF di emergenza di Cloudflare
Ogni sito web ospitato su Kinsta è protetto da Cloudflare, compresi gli ambienti di staging e di produzione. Questo permette al nostro team di ingegneri di applicare protezioni firewall su tutta la piattaforma di hosting senza che i clienti debbano configurare regole per i singoli siti web.
Prima della divulgazione pubblica di PHP2Shell, Cloudflare ha introdotto regole di emergenza del Web Application Firewall (WAF) per rilevare i tentativi di sfruttamento. Il nostro team ha monitorato attentamente il changelog del WAF di Cloudflare man mano che le nuove regole diventavano disponibili, le ha esaminate e ha impostato l’azione su “Blocca” il prima possibile.
Dato che ogni sito Kinsta è già protetto da Cloudflare, abbiamo potuto applicare queste protezioni su tutta la nostra piattaforma di hosting, coprendo sia gli ambienti di produzione che quelli di staging senza che i clienti dovessero fare nulla.
Questa protezione a livello di piattaforma era fondamentale perché PHP2Shell non era una tipica vulnerabilità a livello di applicazione. Gli attacchi prendevano di mira il PHP stesso, quindi gli aggiornamenti di sicurezza di WordPress o le protezioni a livello di plugin non avrebbero risolto il problema di fondo.
Le regole WAF ci hanno permesso di bloccare i tentativi di sfruttamento noti mentre preparavamo le patch per PHP. Cloudflare ha continuato ad aggiornare le sue protezioni man mano che gli hacker cambiavano le loro tecniche. Il suo rapporto tecnico su PHP2Shell descrive come gli hacker abbiano modificato i propri payload per aggirare i sistemi di rilevamento esistenti.
Cloudflare ha inoltre introdotto il rilevamento completo delle transazioni, che analizza i segnali sia dalla richiesta HTTP che dalla risposta del server. Questo fornisce ulteriori informazioni per identificare le richieste sospette e può impedire che una risposta corrispondente raggiunga il richiedente.
I nostri ingegneri hanno potuto osservare come i modelli di attacco cambiassero man mano che venivano rese disponibili nuove regole.
Al 23 ottobre, le protezioni di Cloudflare a copertura dei siti Kinsta avevano bloccato più di 550.000 richieste mirate a PHP2Shell.
Questa cifra rappresenta le richieste bloccate associate alle vulnerabilità, non le intrusioni riuscite o gli autori degli attacchi. Riflette il traffico sospetto gestito dalle nostre protezioni firewall mentre il team lavorava all’implementazione delle correzioni PHP.
Aggiunta di protezioni temporanee alla configurazione PHP
Non ci siamo affidati solo a Cloudflare. In attesa dei pacchetti PHP aggiornati, il nostro team di ingegneri ha anche implementato modifiche alla configurazione di PHP in tutti i nostri ambienti di hosting per ridurre l’esposizione ai percorsi di exploit noti.
Una delle modifiche consisteva nel disattivare la funzione di avanzamento dell’upload di sessione di PHP utilizzando l’impostazione session.upload_progress.enabled.
L’avviso di sicurezza di PHP identifica questa impostazione come una misura di mitigazione per determinati percorsi di exploit. Disattivarla aiuta a bloccare gli attacchi che sfruttano la gestione dell’avanzamento dell’upload delle sessioni in PHP, anche se non risolve tutti i possibili modi in cui le vulnerabilità potrebbero essere sfruttate.
Le regole del firewall e le modifiche alla configurazione hanno fornito una protezione aggiuntiva mentre le patch non erano disponibili o erano ancora in fase di implementazione. Tuttavia, l’aggiornamento del runtime di PHP rimaneva necessario.
Il 23 ottobre, il team di PHP ha pubblicato un’ulteriore nota in cui raccomandava di mantenere disattivato lo stato di avanzamento dell’upload delle sessioni fino al rilascio di una versione successiva con correzioni dei bug. Questo ha rafforzato le precauzioni che il nostro team di ingegneri aveva già adottato.
Le nostre regole Cloudflare e le protezioni di configurazione locali sono rimaste attive per tutta la durata del rollout delle patch, indipendentemente dal fatto che un singolo ambiente avesse ricevuto o meno il pacchetto PHP aggiornato.
Distribuzione delle patch PHP su centinaia di migliaia di container
Quando il team di sviluppo PHP ha rilasciato gli aggiornamenti di sicurezza il 21 ottobre, la nostra sfida successiva è stata quella di distribuire quelle correzioni su tutta l’infrastruttura di hosting.
Le versioni ufficiali includevano PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Tuttavia, Kinsta supporta anche versioni precedenti di PHP, che richiedevano correzioni di sicurezza da parte di manutentori di terze parti.
Abbiamo collaborato con Freexian, il nostro fornitore di pacchetti PHP, per ottenere i pacchetti aggiornati per le versioni di PHP in esecuzione sulla nostra piattaforma, comprese le versioni più vecchie con supporto a lungo termine.
I pacchetti sono stati resi disponibili gradualmente, non tutti in una volta. Man mano che ogni build arrivava nel nostro mirror dei pacchetti, il nostro team la verificava e iniziava l’implementazione senza aspettare che tutti i branch di PHP fossero pronti.
Ecco come è proceduta l’implementazione:
| Data e ora (UTC) | Cosa è successo |
| 21 ottobre, ~14:00–17:45 | PHP ha rilasciato le patch di sicurezza. PHP 8.5.12 è diventato disponibile nel nostro mirror dei pacchetti alle 14:24 e la distribuzione è iniziata alle 15:54. Alle 17:45, erano già state aggiornate decine di migliaia di container. |
| 21 ottobre, dalle 18:50 alle 19:04 | PHP 8.3.36 è diventato disponibile e la distribuzione è iniziata insieme a PHP 8.5. |
| 21 ottobre, dalle 21:17 alle 22:28 | Sono stati resi disponibili i pacchetti aggiornati per PHP 7.4, 8.0 e 8.1, con ulteriori distribuzioni iniziate alle 22:28. |
| 21–22 ottobre, dalle 23:25 alle 01:37 | I pacchetti PHP 8.2 e 8.4 sono arrivati alle 23:25, con la distribuzione iniziata alle 01:37 del 22 ottobre. |
| 22 ottobre, ore 04:31 | Rimanevano da aggiornare solo 1.888 container, circa lo 0,5% del totale, che richiedevano un’attenzione particolare. |
| 22 ottobre, ore 08:26 | Abbiamo confermato una copertura di protezione del 100% e abbiamo contrassegnato l’incidente come risolto. |
La capacità di distribuire le modifiche su questa scala è stata una delle parti più importanti della risposta.
Farkas ha sottolineato la rapidità con cui il team è riuscito a distribuire le modifiche in tutta l’infrastruttura:
“Questa è la parte di cui vado più fiero. Una volta che una modifica è stata convalidata e sappiamo che non causerà problemi, possiamo distribuirla su tutta l’infrastruttura nel giro di un paio d’ore.”
Questa capacità ha permesso al nostro team di distribuire pacchetti PHP aggiornati su centinaia di migliaia di container nel giro di poche ore.
Inoltre, non abbiamo dovuto coordinare gli aggiornamenti PHP con i singoli clienti. Kinsta gestisce PHP a livello di piattaforma, quindi una volta che il team tecnico ha convalidato un pacchetto aggiornato, abbiamo potuto distribuirlo in tutti gli ambienti interessati senza chiedere ai proprietari dei siti di installare gli aggiornamenti da soli.
Perché le versioni precedenti di PHP necessitavano di correzioni aggiuntive
L’implementazione ha dovuto tenere conto anche della differenza tra i branch ufficialmente supportati da PHP e le versioni precedenti gestite da fornitori terzi.
Il progetto PHP ha rilasciato aggiornamenti di sicurezza per le versioni da PHP 8.2 a 8.5. Versioni come PHP 7.4, 8.0 e 8.1 non ricevevano più aggiornamenti di sicurezza regolari direttamente dal progetto PHP, anche se i fornitori di supporto a lungo termine potevano fornire correzioni backportate.
Il backporting permette ai manutentori di applicare correzioni di sicurezza a un branch software più vecchio senza che gli utenti debbano passare a una versione più recente di PHP.
Questo significava che potevamo distribuire aggiornamenti di sicurezza per quegli ambienti PHP più vecchi man mano che Freexian rilasciava pacchetti aggiornati.
Questo spiega anche perché il solo numero di versione di PHP non sempre ti dice se una particolare correzione di sicurezza è stata applicata. I pacchetti gestiti dai fornitori possono includere codice aggiornato senza mostrare lo stesso numero di versione della release ufficiale di PHP.
Durante tutta la fase di implementazione, abbiamo continuato a distribuire gli aggiornamenti mantenendo le protezioni aggiuntive del firewall e della configurazione.
Monitoraggio degli attacchi e ricerca di segni di compromissione
L’applicazione delle patch era solo una parte della risposta. Il nostro team doveva anche capire se i tentativi di sfruttamento osservati avessero avuto successo.
Quando abbiamo notato per la prima volta attività mirate ai siti web ospitati da Kinsta nelle prime ore del 21 ottobre, i nostri ingegneri hanno esaminato manualmente i siti coinvolti.
Hanno continuato a monitorare il traffico sospetto e a effettuare controlli a campione sugli ambienti di hosting per tutta la durata dell’incidente, alla ricerca di segni che indicassero che gli aggressori avessero sfruttato con successo le vulnerabilità.
Gli eventi di sicurezza di Cloudflare ci hanno aiutato a capire cosa fosse preso di mira e come cambiassero i modelli di attacco man mano che rilasciavamo nuove regole. Tuttavia, il solo conteggio delle richieste bloccate non bastava a dirci se qualche attacco avesse avuto successo.
Ecco perché i controlli manuali erano fondamentali. Il nostro team è rimasto inoltre in stretto contatto con Patchstack, il nostro partner per la protezione dalle vulnerabilità, condividendo informazioni sulle minacce e sui modelli di attacco osservati da entrambi i team. Abbiamo anche partecipato a discussioni con altri provider di hosting per scambiare informazioni e buone pratiche, mentre la più ampia comunità PHP reagiva all’accaduto.
Questi sforzi hanno integrato il nostro lavoro con Cloudflare e Freexian. Cloudflare ha fornito protezioni contro i tentativi di sfruttamento, Freexian ha fornito i pacchetti PHP aggiornati e il coordinamento con i partner di sicurezza ha aiutato i nostri ingegneri a capire come si stava evolvendo la minaccia.
Durante l’intero incidente, non abbiamo trovato prove di violazioni riuscite legate a PHP2Shell.
Questa conclusione si basa sul monitoraggio e sulle indagini condotte durante la risposta. Ciò non significa che non ci siano stati attacchi, come dimostrano i dati del firewall. Significa che i nostri controlli non hanno individuato segni di compromissione riuscita.
Risoluzione dell’incidente e verifiche successive
Il 22 ottobre alle 08:26 UTC, abbiamo contrassegnato l’incidente di sicurezza PHP come risolto sulla nostra pagina di stato pubblica.
A quel punto, avevamo distribuito gli aggiornamenti di sicurezza su tutta la piattaforma e tutti i siti erano protetti da una combinazione di patch e misure di mitigazione.
La risoluzione non ha implicato che smettessimo di controllare. Il nostro team ha continuato a verificare gli ambienti e a monitorare le protezioni anche dopo la chiusura ufficiale dell’incidente.
Questo è stato fondamentale durante un’implementazione che ha coinvolto più branch PHP e centinaia di migliaia di container. Alle 04:31 UTC, circa lo 0,5% dei container richiedeva ancora un’attenzione particolare. I nostri ingegneri hanno continuato a lavorare su quegli ambienti rimanenti e a verificare i risultati, invece di considerare la disponibilità di un pacchetto aggiornato come prova che ogni installazione fosse stata aggiornata.
Anche le regole di Cloudflare e le misure di protezione della configurazione PHP sono rimaste attive durante questo lavoro di verifica.
Per i clienti, gli aggiornamenti di sicurezza di PHP non hanno richiesto alcuna applicazione manuale di patch né il cambio di versione.
Risposta ai clienti che hanno adottato ulteriori precauzioni
La reazione a PHP2Shell è andata ben oltre i provider di hosting. Man mano che la notizia delle vulnerabilità si diffondeva, le agenzie governative e altre organizzazioni in tutto il mondo hanno iniziato a mettere temporaneamente offline i siti web mentre preparavano gli aggiornamenti di sicurezza.
Nei Paesi Bassi, il Centro Nazionale per la Sicurezza Informatica ha messo offline il proprio sito web per precauzione. Anche i siti web governativi in Germania, Francia, Belgio e Finlandia sono stati temporaneamente sospesi. In Giappone, la prima ministra Sanae Takaichi ha emesso un avviso urgente su X, esortando i gestori dei siti web ad applicare le patch il prima possibile o a sospendere temporaneamente i servizi se non fossero riusciti ad aggiornare immediatamente.
Noi di Kinsta abbiamo riscontrato preoccupazioni simili tra i nostri clienti. Il nostro team di supporto ha ricevuto un notevole aumento di domande su PHP2Shell e alcuni clienti hanno iniziato a prendere ulteriori precauzioni per proteggere i propri siti web.
Tra queste c’era l’uso della funzione di sospensione dell’ambiente di MyKinsta per mettere offline i siti, l’attivazione delle verifiche di autenticità a livello di sito tramite Protezione Bot, oppure la richiesta all’assistenza di bloccare il traffico in entrata a livello di server. Durante l’incidente, i clienti hanno sospeso in modo proattivo circa 3.000 siti.
Data la gravità delle vulnerabilità e le precauzioni adottate altrove, queste decisioni erano comprensibili. Tuttavia, il nostro team non ha raccomandato ai clienti di mettere offline i loro siti web ospitati su Kinsta. Avevamo già attivato le regole WAF di emergenza di Cloudflare su tutta la nostra piattaforma di hosting, quindi i siti rimasti online hanno continuato a ricevere quelle protezioni senza diventare inaccessibili ai visitatori.
Il nostro team di supporto ha iniziato a sconsigliare ai clienti le sospensioni non necessarie, mentre il team tecnico continuava a distribuire le patch PHP.
Una volta distribuiti gli aggiornamenti di sicurezza, abbiamo esaminato le azioni di sospensione intraprese durante l’incidente per identificare i siti web che i clienti avevano messo offline proprio a causa di PHP2Shell.
Il nostro team ha quindi riattivato quegli ambienti, lasciando invece inalterati i siti sospesi per motivi non correlati. Questo ha richiesto di distinguere le sospensioni precauzionali da altre sospensioni intenzionali, invece di limitarsi a ripristinare ogni ambiente che era stato messo offline.
Oltre a bloccare gli attacchi e distribuire le patch, i nostri team hanno dovuto anche aiutare i clienti a riprendersi dalle misure precauzionali che avevano adottato durante l’incidente.
Cosa ha significato questa risposta per i clienti di Kinsta
PHP2Shell ha richiesto un coordinamento tra i reparti di Ingegneria, Supporto e diversi partner esterni di sicurezza e infrastruttura. Ma la piattaforma ha gestito da sola l’applicazione delle patch.
I clienti non hanno dovuto tenere traccia della disponibilità di ogni versione di PHP, determinare quale pacchetto aggiornato servisse al loro sito web, né installare gli aggiornamenti da soli.
Farkas ha spiegato cosa ha significato in definitiva questa risposta per i clienti di Kinsta:
“Per me, il messaggio principale è che i clienti non hanno dovuto preoccuparsi di nulla: cosa aggiornare, quando o come. Erano semplicemente protetti sulla nostra piattaforma.”
La reazione dei clienti durante l’incidente ha anche dimostrato perché fosse importante comunicare queste misure di protezione. Alcuni clienti hanno messo offline i siti web anche se le regole WAF di emergenza erano già attive, e i nostri team hanno poi lavorato per ripristinare gli ambienti sospesi a causa delle vulnerabilità.
Nel frattempo, il nostro team ha distribuito gli aggiornamenti di sicurezza PHP su centinaia di migliaia di container senza che i clienti dovessero gestire le modifiche.
Per un resoconto degli aggiornamenti di sicurezza e della risoluzione dell’incidente, dai un’occhiata al nostro rapporto sull’incidente di sicurezza PHP.
Per capire cosa comportano queste vulnerabilità per il tuo sito web, leggi il nostro articolo correlato, PHP2Shell: Come Kinsta ha protetto i siti WordPress.
