PHP2Shell: il bug che ha dato a tutto il web circa 24 ore

Oggi alle 14:00 UTC PHP ha pubblicato quattro release di emergenza. Se avete un sito web, è molto probabile che giri su PHP, ed è quasi certo che fino a questa settimana non aveste mai sentito parlare di PHP2Shell. Ecco perché vi riguarda, e perché stavolta il tempo a disposizione è così poco.

Cosa è successo in poche parole

Due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, permettono a chiunque sia in grado di inviare una richiesta web apparentemente normale a un server PHP di eseguire comandi su quel server. Senza login. Senza plugin particolari. Senza che il vostro codice abbia alcun difetto. Il problema è dentro PHP stesso, il motore sotto WordPress, Magento, Drupal, Laravel, Shopware, WooCommerce e buona parte delle applicazioni web su misura costruite negli ultimi quindici anni.

Entrambi i bug hanno un punteggio CVSS v4.0 di 9.2, cioè quasi il massimo per qualcosa raggiungibile da internet. Il codice vulnerabile risale a PHP 5.4, uscito nel 2012. Le configurazioni di default sono vulnerabili. Apache con mod_php e PHP-FPM sono entrambi esposti. Secondo W3Techs, PHP è dietro circa il 69% dei siti di cui si conosce il linguaggio lato server. Le prime scansioni stimano tra 1,3 e 1,9 milioni di host direttamente esposti.

Il meccanismo, semplificato: quando PHP incontra un errore fatale a metà richiesta (memoria esaurita, tempo di esecuzione superato, client che chiude la connessione) non ripulisce correttamente tutto quello che stava gestendo. Alcuni puntatori interni restano agganciati a memoria già liberata o mai inizializzata del tutto. Chi riesce a provocare quell'errore di proposito, e a decidere cosa finisce in quella memoria, ottiene l'esecuzione di codice. I ricercatori di Calif lo hanno già dimostrato su Magento 2.4.9 e su altre dieci applicazioni PHP.

La cronologia è, più o meno, questa:

• 1 agosto: Ryan Austin di Calif trova diverse vie per l'esecuzione remota di codice.
• 11 agosto: Calif segnala il primo bug al team di sicurezza di PHP e parte la divulgazione coordinata.
• 24 agosto: Wiz Research segnala le stesse vulnerabilità a PHP, in modo indipendente.
• 20 ottobre: i dettagli trapelano, due giorni prima della divulgazione prevista per il 22. Gli identificativi CVE girano su Hacker News e sui social. watchTowr riproduce uno dei bug in giornata. PHP annuncia una release di emergenza per il pomeriggio seguente. CERT-EU pubblica l'avviso 2026-018.
• 21 ottobre, 07:43 UTC: il CTO di Cloudflare segnala i primi attacchi, sette ore prima che esista la patch.
• 21 ottobre, 14:00 UTC: escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, insieme alle analisi tecniche di Calif, Wiz e OpenAI.

Rileggetela. Undici settimane di coordinamento silenzioso e attento tra ricercatori e team PHP, e poi tutto il piano è crollato in un giorno per una fuga di notizie. Gli attacchi sono stati osservati prima che la correzione esistesse. Sansec, che di mestiere monitora gli attacchi agli e-commerce, dice di aspettarsi uno sfruttamento di massa ora che patch e analisi sono pubbliche. Perché la patch stessa è una mappa: chiunque sappia leggere un diff vede esattamente dove colpire.

Ed è questa la novità. Dieci anni fa un bug trapelato così avrebbe lasciato a chi difende qualche giorno, a volte settimane, prima che gli exploit funzionanti circolassero davvero. Oggi la finestra tra "la correzione è pubblica" e "l'attacco è automatizzato" si misura in ore. E si sta restringendo. Gli strumenti per trasformare una patch in un exploit sono diventati economici, veloci e sempre più automatici. Anche lo sforzo per trovare bug di questo tipo è calato, ed è il motivo per cui due team distinti hanno trovato la stessa falla a tre settimane di distanza. Aspettatevi più casi così, non meno. I bug c'erano da sempre. Quello che è cambiato è la velocità con cui vengono scoperti, e la velocità con cui diventano armi una volta scoperti.

Perché "basta aggiornare" è più difficile di quanto sembri

PHP supporta solo le versioni dalla 8.2 in su. Se il vostro sito gira su 8.1, 8.0, 7.x o (succede più spesso di quanto si ammetta) 5.x, per voi non esiste una correzione ufficiale. Alcune distribuzioni Linux e alcuni hosting riporteranno la patch sulle versioni vecchie, a volte senza nemmeno cambiare il numero di versione, quindi a occhio non si capisce. Gli stessi sviluppatori di PHP sono stati netti: i ritocchi alla configurazione non vi salvano, l'unica vera mitigazione è aggiornare.

E un avvertimento, perché oggi ci abbiamo perso un po' di tempo: GitHub si sta già riempiendo di repository che promettono exploit "dimostrativi" e script di fix in un clic. Quasi tutti non verificati. Alcuni chiedono i permessi di root. L'avviso di Tenable ricorda che il codice di exploit non verificato per bug di questo tipo a volte contiene malware. Non eseguite lo script di uno sconosciuto sul vostro server di produzione perché ve lo dice un README.

Due tipi di clienti, due martedì molto diversi

Qui viene la parte che racconta come si traduce tutto questo per chi lavora con noi.

Per i clienti che hanno un sito, un e-commerce, o una App sui nostri server gestiti, oggi è stata una giornata quasi noiosa. Lunedì sapevamo che sarebbe uscita una release. Avevamo già l'inventario delle versioni. Quando nel pomeriggio sono arrivati i pacchetti, abbiamo aggiornato, riavviato i worker PHP, controllato i siti e siamo andati avanti. Nessuno ci ha dovuto chiamare. Nessuno ha dovuto capire cos'è uno use-after-free, alcuni hann scoperto del problema solo quando abbiamo inviato la comunicazione di chiusura, dicendo che tutto era sistemato. È esattamente quello che dovrebbe significare "gestito", e giornate come questa sono il motivo per cui insistiamo tanto su questo punto.

Per i clienti il cui sito vive su un hosting di terze parti, il quadro è diverso. Possiamo costruire e mantenere la vostra applicazione, ma non controlliamo il runtime PHP sul server di qualcun altro. È quel fornitore che deve distribuire la patch, con i suoi tempi, su tutta la sua infrastruttura. Alcuni lo faranno stanotte. Altri la settimana prossima. Altri ancora girano su PHP 7.4 in un piano condiviso e vi diranno, con garbo, che l'aggiornamento è in programma. L'unico modo per saperlo è chiedere, oggi, con la domanda precisa: su quale versione di PHP gira il mio sito, e ha ricevuto la correzione per CVE-2026-109618 e CVE-2026-109619?

Il rischio vero non è tecnico. È che questa domanda non venga mai fatta. Se gestite un'azienda e leggete di PHP2Shell come dell'ennesimo titolo allarmante in una settimana piena di titoli allarmanti, niente nella vostra giornata vi obbliga ad agire. Il sito funziona. Lo shop incassa. L'attacco, quando arriva, non si annuncia. Sembrerà una pagina un po' lenta e un file nuovo in una cartella che non aprite mai. Quando qualcuno se ne accorge, la domanda non è più "siamo aggiornati" ma "cosa si sono portati via".

Quindi, tre cose, in ordine. Se siete su un server gestito con noi, avete finito: vi arriverà la solita conferma. Se siete ospitati altrove, mandate al vostro fornitore la domanda qui sopra adesso. E se non siete sicuri in quale dei due casi vi trovate, quell'incertezza è già il problema, ed è un problema che sconta il volere sempre un servizio a buon mercato, per non dire altro.

Il web non sta diventando più sicuro da solo. La distanza tra divulgazione e attacco si è ridotta a una giornata lavorativa, e la prossima volta sarà forse ancora più breve. L'unica risposta che regge è avere un il cui mestiere è guardare, e muoversi prima che voi sappiate che c'era qualcosa da fare.