PHP2Shell (CVE-2026-109618 e CVE-2026-109619): la falla critica di PHP spiegata semplice

Il 21 ottobre 2026 gli sviluppatori di PHP hanno pubblicato in tutta fretta una correzione per due falle critiche, registrate come CVE-2026-109618 e CVE-2026-109619 e ribattezzate subito PHP2Shell. Il nome dice già quasi tutto: da PHP alla “shell”, cioè al comando diretto del server.

Se il tuo sito è fatto con WordPress, WooCommerce, Joomla, Prestashop o quasi qualunque altro CMS, gira su PHP. La notizia riguardava anche te. In questo articolo provo a spiegare come funzionavano le due falle senza dare per scontato che tu sappia cos’è un server. Se sei un mio cliente puoi leggerlo con calma: il lavoro è già fatto, e te lo racconto in fondo.

Un sito web è un’aula

Per capire dove stava il problema serve un’immagine di come nasce una pagina web. Immagina un’aula.

• Lo schedario è il database. Dentro ci sono i fogli con tutti i contenuti del sito: il testo degli articoli, i prezzi dei prodotti, i nomi delle pagine.
• Il quaderno delle istruzioni è WordPress, con il tema e i plugin. Dice quali fogli prendere e come impaginarli: il titolo in alto, il menu a sinistra, il prezzo in grassetto.
• L’insegnante è PHP. Legge il quaderno, va allo schedario, prende i fogli giusti e trascrive tutto.
• La lavagna è la pagina HTML, quello che alla fine il browser mostra a chi visita il sito.
• La classe sono i visitatori. Ognuno alza la mano e chiede una pagina.

Ogni volta che qualcuno apre una pagina, l’insegnante cancella la lavagna e la riscrive da capo seguendo il quaderno. Un sito con molte visite ha più insegnanti, che lavorano in parallelo. C’è un dettaglio che conterà molto più avanti: per non perdere tempo, ogni insegnante fa lezione a una classe dopo l’altra senza mai uscire dall’aula. Finisce con una richiesta, riordina la cattedra e passa alla successiva.

E la cache?

Riscrivere la lavagna a ogni domanda è fatica sprecata, se la domanda è sempre la stessa. La cache è una fotografia della lavagna: quando qualcuno chiede una pagina già scritta da poco, gli si mostra la foto e l’insegnante non viene nemmeno disturbato. Per questo un sito con la cache è più veloce e regge più visite. Ogni tanto la foto si butta e se ne scatta una nuova, così i contenuti restano aggiornati.

La fotografia, però, si usa solo per chi chiede di leggere una pagina. Chi consegna qualcosa (un modulo di contatto, un ordine, un file da caricare) va sempre dall’insegnante in persona. Teniamolo a mente.

Prima della lezione: i pacchi

Quando un visitatore invia un modulo o carica un file, il browser impacchetta tutto in un formato chiamato multipart/form-data. Pensalo come un pacco con tanti scomparti: in uno c’è il nome, in un altro il messaggio, in un altro ancora l’allegato.

Il punto chiave è questo: l’insegnante disfa il pacco prima di aprire il quaderno. Prima sistema sulla cattedra il contenuto di ogni scomparto, e solo dopo comincia a leggere le istruzioni di WordPress. Tutte e due le falle stanno in questa fase. Il sito non ha ancora fatto niente, nessun plugin di sicurezza si è ancora acceso, nessuno ha ancora chiesto una password.

CVE-2026-109618: la cattedra che si riempie

Ogni insegnante ha una cattedra di dimensioni fisse: è la memoria che PHP può usare per una singola richiesta (il memory_limit). Se gli si chiede troppo, si ferma e abbandona la lezione. È una protezione sensata, che c’è da sempre.

L’attaccante arriva con un pacco costruito apposta per riempire la cattedra: centinaia di scomparti vuoti, buste dentro buste dentro buste per decine di livelli. Gli attacchi registrati il 21 ottobre arrivavano fino a 37 MB di scomparti inutili. L’insegnante comincia a disfarlo e a compilare il registro di ciò che ha ricevuto. A un certo punto la cattedra è piena e l’insegnante viene interrotto a metà di una riga del registro.

Fin qui niente di grave, se non che la pulizia finale funzionava male. Quando l’insegnante riordina, prende per buone le righe scritte a metà: segue frecce che puntano a cassetti a caso, o a cassetti in cui l’attaccante ha messo con cura i suoi fogli. Con la giusta preparazione, uno di quei fogli contiene istruzioni che l’insegnante esegue come se venissero dal quaderno.

Gli sviluppatori di PHP lo descrivono così: la gestione della memoria esaurita può interrompere PHP mentre i dati della richiesta sono inizializzati solo in parte, e la pulizia successiva li tratta come validi. Il rischio era più alto nella configurazione più vecchia, mod_php, in cui il riordino parte sempre, anche se la lezione non è mai cominciata.

CVE-2026-109619: il post-it rimasto sulla cattedra

La seconda falla sfrutta il fatto che l’insegnante non esce mai dall’aula.

Durante una lezione l’insegnante attacca un post-it sulla cattedra: “gli appunti di questo studente sono nel cassetto 3”. Finita la lezione, il cassetto 3 viene svuotato e messo a disposizione di chiunque. Ma in certe situazioni il post-it resta attaccato. Arriva la classe successiva, e l’insegnante, prima di fare il solito riordino del mattino, legge il post-it e va dritto al cassetto 3, convinto che ci siano i suoi appunti. Se nel frattempo l’attaccante è riuscito a metterci dentro un foglio suo, l’insegnante lo esegue.

Nel linguaggio tecnico si chiama use-after-free: usare un pezzo di memoria dopo averlo liberato. Gli sviluppatori di PHP parlano di stato interno di una richiesta che sopravvive dopo che la sua memoria è stata liberata, e che una richiesta successiva gestita dallo stesso processo può usare prima che venga azzerato.

La strada più usata: il foglietto dell’avanzamento

Per arrivare a quel post-it gli attaccanti hanno usato una funzione poco conosciuta di PHP, attiva in modo predefinito da oltre dieci anni: l’avanzamento del caricamento (session.upload_progress). Serve a mostrare la barra “caricato il 40%” quando si spedisce un file grande.

Funziona così. Se nel pacco c’è uno scomparto con la scritta PHP_SESSION_UPLOAD_PROGRESS, l’insegnante, mentre lo disfa, tiene aggiornato un foglietto nel quaderno personale dello studente (la “sessione”): nome del file, quanto è arrivato, quanto manca. E lo fa prima di aprire il quaderno di WordPress, anche se il sito non ha mai chiesto di usare quel quaderno personale.

È qui che l’attaccante mette le mani: decide lui cosa c’è scritto su quel foglietto e in quale quaderno finisce, e con richieste minuscole, di poche centinaia di byte, porta l’insegnante nello stato in cui il post-it vecchio viene riletto. In una delle varianti viste negli attacchi l’etichetta del pacco era essa stessa un pezzo di codice, che finiva copiato parola per parola nel quaderno personale. Bastava poi un secondo difetto nel sito, uno che permettesse di dire all’insegnante “leggi ad alta voce quel quaderno”, e il codice veniva eseguito.

Perché era così grave

1. Riguardava praticamente tutti. Il codice difettoso risale a PHP 5.4, del 2012, ed era presente in tutte le versioni successive, con qualunque modo di far girare PHP: PHP-FPM, Apache con mod_php, CGI, LiteSpeed.
2. Non serviva un account. Bastava inviare un pacco a una pagina qualsiasi del sito, anche una che i moduli non li usa.
3. Il punteggio di gravità era 9,2 su 10 per entrambe.
4. Gli attacchi sono partiti prima della correzione. Le falle erano state segnalate a PHP il 27 agosto, e la correzione era prevista per il 22 ottobre. Il 20 ottobre però sono trapelati i dettagli, con un esempio funzionante. PHP ha anticipato tutto di un giorno, ma i primi tentativi di attacco sono stati registrati la mattina del 21, ore prima che la correzione uscisse alle 16 italiane. Entro sera decine di indirizzi avevano mandato centinaia di richieste, e nei pacchi c’erano programmi per trasformare il server in un robot al servizio di altri, porte di servizio per tornare quando si vuole e strumenti per attacchi a pagamento.

Perché un plugin di sicurezza non bastava

Un plugin di sicurezza è una pagina del quaderno di WordPress: entra in gioco quando l’insegnante apre il quaderno. Qui il danno succedeva prima, mentre il pacco veniva disfatto. Per lo stesso motivo non bastava la cache: la fotografia della lavagna serve a chi chiede di leggere una pagina, ma un pacco va sempre dall’insegnante.

Le pezze provvisorie e la correzione vera

Prima che le versioni corrette fossero disponibili su tutti i server, circolavano tre rimedi temporanei. Tutti e tre hanno un prezzo.

• Spegnere l’avanzamento del caricamento (session.upload_progress.enabled = 0): l’insegnante non tiene più il foglietto. Chiude la strada più usata per la seconda falla, ma non il difetto del post-it, e non tocca la prima falla. In compenso non rompe quasi niente.
• Togliere il limite alla memoria (memory_limit = -1): la cattedra diventa infinita, quindi l’insegnante non viene mai interrotto. Però uno studente malintenzionato può riempire l’intera scuola, cioè la memoria del server, e far cadere tutti i siti e il database. Io non l’ho usato.
• Rifiutare i pacchi alla porta: il server respinge tutte le richieste multipart prima che arrivino all’insegnante. È la pezza più efficace, ma ferma anche i moduli di contatto e i caricamenti di file, che usano proprio quel formato.

La correzione vera è un insegnante che riordina come si deve: le nuove versioni di PHP non prendono per buone le righe scritte a metà e staccano i post-it a fine lezione. Lo dicono gli stessi sviluppatori nel loro avviso: le misure provvisorie riducono il rischio, ma l’unica scelta sicura è aggiornare.

Quali versioni di PHP sono corrette

• PHP 8.5: dalla 8.5.12 in poi
• PHP 8.4: dalla 8.4.27 in poi
• PHP 8.3: dalla 8.3.36 in poi
• PHP 8.2: dalla 8.2.35 in poi (ma la 8.2 smette di ricevere correzioni il 31 dicembre 2026)

Per PHP 8.1 e le versioni più vecchie non esiste una correzione ufficiale. Alcuni fornitori la applicano per conto loro, ma un sito che gira ancora su quelle versioni dovrebbe comunque passare a una più recente.

Cosa ho fatto sui siti dei miei clienti

Mi sono messo al lavoro il giorno stesso dell’annuncio.

• Sui server che gestisco direttamente ho installato le versioni corrette di PHP appena sono state disponibili. Dove la correzione non era ancora pronta, ho messo nel frattempo le pezze provvisorie, e le ho tolte solo dopo l’aggiornamento. Poi ho controllato server per server che girasse davvero la versione nuova.
• Sull’hosting condiviso di Aruba Business, dove stanno una parte dei siti, l’aggiornamento spetta ai sistemisti di Aruba. Lo hanno completato e ce l’hanno confermato.

Oggi tutti i server e gli hosting di Seo ergo Web hanno le correzioni applicate. Se sei un mio cliente non devi fare niente: niente da installare, nessuna password da cambiare.

Se il tuo sito sta altrove

Puoi vedere la versione di PHP direttamente da WordPress: Strumenti → Salute del sito → Info → Server. Confrontala con l’elenco qui sopra.

Un’avvertenza: alcuni hosting applicano la correzione lasciando il vecchio numero di versione, quindi un numero “vecchio” non vuol dire per forza che il sito sia scoperto. Nel dubbio chiedi al tuo fornitore se ha già applicato le correzioni per CVE-2026-109618 e CVE-2026-109619. Se non sai a chi chiedere, scrivimi: ci guardo io.