PHP2Shell: quando il problema non è il tuo sito, ma il motore che lo fa girare

Due settimane fa ho scritto che è meglio un sito rotto che un sito vulnerabile. Parlavo di plugin, di aggiornamenti saltati, di siti lasciati da soli. Ieri è successa una cosa che sposta il discorso un piano più in basso: la falla non era in un plugin, era in PHP, il motore su cui girano WordPress, WooCommerce, Laravel, Magento e una buona parte del web.

Se hai un sito, questo articolo è per te. Soprattutto se non sai su che versione di PHP gira.

Il 21 ottobre il team di sicurezza di PHP ha pubblicato in emergenza le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono due difetti nel modo in cui PHP gestisce la memoria quando una richiesta si interrompe male. Tradotto: una richiesta costruita apposta può far eseguire al server codice scelto dall’attaccante.

Tre dettagli rendono questa vicenda diversa dal solito:

• non serve essere autenticati: basta che il sito sia raggiungibile da internet;
• sono coinvolte tutte le versioni di PHP dalla 5.4 in poi, cioè gli ultimi quattordici anni (analisi di Sansec);
• i dettagli sono trapelati prima del previsto: la pubblicazione era fissata per il 22 ottobre ed è stata anticipata di un giorno (The PHP Foundation), e Cloudflare ha segnalato i primi tentativi di attacco già alle 9:43 ora italiana del 21, prima delle correzioni (14:00 UTC, le 16:00 in Italia).

“There are no complete mitigations, updating is the only safe choice.”

“Non esistono soluzioni complete alternative: aggiornare è l’unica scelta sicura.”

— PHP development team, annuncio ufficiale del 21 ottobre 2026

Non è un allarme da forum. Lo stesso giorno hanno pubblicato avvisi l’Agenzia per la Cybersicurezza Nazionale, la statunitense CISA, l’NCSC britannico, Google Cloud e tutti i principali fornitori di hosting.

Nell’articolo precedente ho spiegato che il 91% delle vulnerabilità WordPress riguarda i plugin (Patchstack). Questa volta no. Puoi avere WordPress aggiornato all’ultima versione, tutti i plugin a posto, il tema nuovo di zecca: se il server gira su un PHP non corretto, sei esposto.

E qui arriva la domanda scomoda: chi aggiorna PHP sul tuo sito? Dipende da dove si trova.

I siti dei nostri clienti stanno su Kinsta, quindi l’ho seguita da vicino. Ecco la cronologia, presa dalla pagina di stato ufficiale e dalle risposte del supporto nella community di Kinsta:

• prima ancora delle patch, Kinsta ha attivato regole firewall dedicate su Cloudflare e una modifica di configurazione su tutta l’infrastruttura per bloccare i tentativi di attacco;
• in serata, dalle 21 circa ora italiana, le versioni 8.5 e 8.3 corrette erano validate e in distribuzione;
• durante la notte sono arrivate via via anche 8.0, 7.4 e 8.1 e, all’1:25 del 22 ottobre, 8.4 e 8.2: in distribuzione su tutte le versioni, comprese 8.1, 8.0 e 7.4, che PHP non supporta più ma per cui Kinsta garantisce un supporto esteso. Le protezioni Cloudflare restano attive su tutti i siti, indipendentemente dallo stato della patch.

La frase che conta l’ha scritta il loro supporto ai clienti: “Since PHP is managed at the platform level on Kinsta, there’s nothing you need to do on your end”. PHP è gestito dalla piattaforma: il cliente non deve fare niente.

Questo è il vero vantaggio di una piattaforma gestita, che si comporta come un servizio SaaS: l’emergenza la gestisce qualcuno che ha un team di sicurezza, lo fa su migliaia di siti contemporaneamente e lo fa di notte. Chi ha un server suo, invece, ieri sera doveva accorgersene, scaricare l’aggiornamento, installarlo e riavviare tutto.

Non è un caso isolato. Cloudways, la piattaforma di hosting gestito di DigitalOcean che usiamo anche noi, ha seguito lo stesso schema. Ha aperto l’incidente sulla pagina di stato alle 9:16 UTC del 21 ottobre (le 11:16 in Italia), prima del rilascio delle correzioni: ha applicato le misure temporanee indicate da PHP e ha preparato una distribuzione graduale delle patch ufficiali su tutta la flotta, avvertendo che le misure provvisorie possono causare una breve interruzione del servizio. Per le versioni fuori supporto lavora con i suoi partner di supporto esteso. DigitalOcean, nel suo annuncio, aggiunge che ha attivato anche regole WAF mirate, che patcha le versioni da PHP 5.6 in su e che non costringe i clienti a migrare. Nella pagina di stato non sono indicate azioni a carico del cliente, che riceve gli aggiornamenti via email.

Il discorso cambia sui prodotti “fai da te”: sempre secondo DigitalOcean, un server virtuale (Droplet) con PHP installato a mano, le installazioni 1-Click già attive e le app con container personalizzati vanno aggiornati dal cliente. Stessa emergenza, responsabilità diversa: dipende da chi gestisce PHP.

Secondo le statistiche di WordPress.org, circa un sito WordPress su tre (35%) gira ancora su PHP 8.1 o precedenti, cioè su versioni senza più aggiornamenti ufficiali. Per queste versioni il progetto PHP non rilascia più aggiornamenti: ha pubblicato solo correzioni minime dei sorgenti per 7.4, 8.0 e 8.1, da integrare a cura dei fornitori. Sotto la 7.4, niente.

Restano solo misure di contenimento temporanee sulla configurazione del server, indicate dall’Agenzia per la Cybersicurezza Nazionale e da PHP: riducono il rischio, non lo eliminano.

Perché un sito resta su un PHP vecchio? Quasi sempre perché qualche plugin o il tema non funziona sulle versioni nuove. Il passaggio da PHP 7.4 a PHP 8 è stato il più traumatico degli ultimi anni: funzioni rimosse, errori che prima erano avvisi. Quindi il sito vecchio non si aggiorna con un clic: va migrato, cioè controllato, corretto e testato.

E aggiungo una cosa che vale anche per chi è su Kinsta: anche se il fornitore ha messo una toppa a PHP 7.4, quella versione resta fuori supporto. Ha retto questa volta. La prossima non è detto.

Qui voglio essere esplicito, perché è la domanda che mi state facendo da ieri.

Se hai un contratto di manutenzione con noi, paghiamo noi. Nel senso che è già compreso in quello che paghi ogni mese. Abbiamo cominciato ieri gli interventi sui siti in manutenzione: controlliamo la versione PHP, aggiorniamo dove serve, verifichiamo che tutto funzioni. Non devi chiamarci, non devi chiedere un preventivo, non devi metterti in coda. Sei in cima alla lista per contratto: è il nostro sistema di priorità.

Se non hai un contratto, paghi tu. Non per cattiveria: senza contratto non ci occupiamo regolarmente della manutenzione del tuo server, ma solo su una tua richiesta esplicita. E ogni intervento ha un costo che non tutti sono lieti di pagare; eppure è necessario, perché quando la manutenzione manca poi succedono i pasticci. Ogni intervento parte da zero: analisi, preventivo, intervento (come funziona l’assistenza senza contratto). E se lo vuoi subito, mentre stiamo lavorando sui clienti in manutenzione, è un intervento urgente con tariffa doppia (differenza tra urgenza ed emergenza).

Cinque cose, in ordine:

1. Scopri dove sta il tuo sito e chi gestisce il server. Se non lo sai, è già una risposta.
2. Chiedi a chi lo gestisce su che versione di PHP gira e se è stata aggiornata dopo il 21 ottobre. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35, o i pacchetti corretti del tuo fornitore. Se usi un repository gestito da volontari come Remi, PHP consiglia di passare ai pacchetti della distribuzione o di compilare dai sorgenti.
3. Se sei su PHP 8.1 o precedenti, metti in conto una migrazione, non un semplice aggiornamento.
4. Se non si può aggiornare subito, chi gestisce il server può applicare le misure temporanee indicate da PHP e dall’ACN, che riducono il rischio ma non rendono il server sicuro, oppure togliere il sito da internet finché non è sistemato. Meglio un sito spento che un sito bucato.
5. Dopo, controlla che nessuno sia entrato. Se dal sito sono usciti dati personali (contatti, ordini, account) è un data breach: hai 72 ore per notificarlo al Garante.

Oppure ci scrivi (info@f.technology, 0547.1877300), e ne parliamo. Ma ti dico già da ora cosa ti proporrò: un contratto, così la prossima volta non devi leggere questo articolo.

Succede. Un sito di otto anni, un tema abbandonato, plugin che nessuno aggiorna più: portarlo su PHP 8.4 può costare quasi come rifarlo.

In quel caso la domanda giusta non è “come lo aggiorno”, ma “mi serve ancora WordPress?”. Se il sito è una vetrina, chi siamo, servizi, contatti, la risposta spesso è no. Come ho spiegato nell’articolo precedente, noi lo rifacciamo come sito statico con Astro: pagine già pronte, senza database e senza PHP. Ieri, con PHP2Shell, un sito statico non aveva niente da aggiornare. Né ieri, né la prossima volta.

Costi annui indicativi: WordPress gestito tra 1.250 e 1.550 €, sito statico circa 100 € di hosting su Sevalla, la piattaforma di Kinsta per i siti statici. Si perde un po’ di autonomia nelle modifiche, si guadagna in sicurezza e tranquillità.

Un sito non è solo il sito: è il sito più il server, più PHP, più il database, più tutto quello che ci sta sotto. Puoi tenere pulito il giardino, ma se le fondamenta hanno una crepa, lo devi sapere e qualcuno la deve chiudere. Di notte, se serve.

Le strade sono tre:

• un hosting gestito con un’agenzia che ti segue: il server e PHP li aggiorna il fornitore, il sito e i plugin li segue l’agenzia. Paghi un canone, ma l’emergenza la gestiscono altri;
• un sito statico su hosting “serverless”: le pagine sono già pronte e le serve direttamente l’infrastruttura di un cloud provider (nel nostro caso Sevalla). Non c’è un server tuo da gestire, non c’è PHP, non c’è un database: quindi non ci sono aggiornamenti da fare, né costi di manutenzione extra. Ci pensa il provider, ed è il motivo per cui ieri un sito così non aveva niente da aggiornare;
• te ne occupi tu, con competenze e tempo.

Quella sbagliata è sempre la stessa: lasciarlo lì e sperare.

E il tuo sito, su che versione di PHP gira? Se non lo sai, scrivimelo nei commenti: te lo dico io.

Altri articoli su vulnerabilità e su Kinsta. Per sapere come lavoriamo sulla sicurezza WordPress: WordPress Security.

• PHP: security advisory del 21 ottobre, preavviso del 20 ottobre, versioni supportate, versioni fuori supporto
• The PHP Foundation: Today’s PHP Security Release
• ACN: PHP2Shell: sanate vulnerabilità critiche in PHP
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• NCSC UK: Critical security issue affecting PHP
• Google Cloud: Responding to core PHP vulnerabilities
• Kinsta: pagina di stato, PHP Security Vulnerability Update, thread nella community, supporto esteso per PHP 7.4 e 8.0
• Cloudways: pagina di stato, Critical PHP Remote Code Execution Vulnerabilities; DigitalOcean: Critical PHP RCE Vulnerabilities: Patch Now
• Sansec: PHP2Shell: Critical PHP RCE
• Palo Alto Unit 42: Threat Brief su CVE-2026-109618 e CVE-2026-109619
• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
• Help Net Security: PHP2Shell: Critical PHP vulnerabilities patched
• Garante Privacy: violazioni di dati personali (data breach)
• Patchstack: State of WordPress Security in 2026
• F.technology: Contratti di application maintenance, WordPress Security, Kinsta, Assistenza senza contratto, Urgenza ed emergenza, Triage e priorità
• francamente.tech: Meglio un sito rotto che un sito vulnerabile