Cos'è PHP2Shell? Le vulnerabilità critiche di PHP (CVE-2026-109618 / 109619) e la risposta di Partnerfy

In breve: PHP2Shell è il nome dato a due vulnerabilità di sicurezza critiche del core di PHP, corrette il 21 ottobre 2026: CVE-2026-109618 e CVE-2026-109619. Entrambe hanno ottenuto un punteggio di 9,2 (critico) sulla scala CVSS v4.0. Nel caso peggiore, all'attaccante non serve alcun account: bastano richieste HTTP appositamente predisposte per eseguire codice sul web server (RCE). Il problema non è nella sua applicazione, ma in PHP stesso. Anche un codice WordPress o Laravel impeccabile, o un semplice sito «Hello World», è quindi a rischio se gira su una versione vulnerabile di PHP. L'unica soluzione completa è aggiornare PHP alla 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o al pacchetto corretto della sua distribuzione) e riavviare tutti i worker PHP. In Partnerfy non abbiamo aspettato la patch ufficiale: circa tre ore prima del rilascio abbiamo attivato una mitigazione temporanea sui nostri server, eseguito backup completi degli account e rafforzato le difese livello per livello. In questo articolo spieghiamo come è emersa la vulnerabilità, che cos'è dal punto di vista tecnico, che cosa deve fare Lei e che cosa abbiamo fatto noi.

Questo articolo si rivolge a titolari d'azienda e team tecnici il cui sito web, piattaforma e-commerce o software su misura gira su PHP. I dettagli tecnici si basano sull'annuncio di sicurezza ufficiale del progetto PHP, sulle GitHub Security Advisories (GHSA) di PHP e sulle pubblicazioni dei ricercatori che hanno scoperto le falle. Dove le fonti si contraddicono, lo diciamo esplicitamente. La situazione evolve rapidamente. Articolo aggiornato al 21 ottobre 2026, in serata.

Che cos'è PHP2Shell e perché è così grave?

PHP è uno dei linguaggi server-side più diffusi sul web. WordPress, WooCommerce, Drupal, Joomla, Magento e Laravel girano tutti su PHP. Tre caratteristiche rendono PHP2Shell così grave:

• Nessuna autenticazione richiesta. L'attaccante non ha bisogno di registrarsi sul suo sito, conoscere una password o compilare un modulo. Bastano richieste appositamente predisposte.
• Può scattare prima che venga eseguito il codice dell'applicazione. Secondo il progetto PHP, il rischio è massimo nelle installazioni Apache mod_php. Qui è stato dimostrato che una richiesta non autenticata può innescare l'attacco prima che venga eseguito qualsiasi codice applicativo. Plugin aggiornati, codice pulito e controlli di sicurezza interni all'applicazione non chiudono questa strada.
• L'impatto è estremamente ampio. Secondo il progetto PHP, l'esposizione riguarda «tutte le installazioni PHP che servono richieste web»: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. Secondo Wiz, uno dei team che hanno scoperto le falle, ogni versione di PHP rilasciata nell'ultimo decennio, risalendo fino alla 5.4, è interessata da almeno una delle due vulnerabilità. Questa affermazione sulla portata è di Wiz: l'advisory ufficiale di PHP elenca solo i rami supportati 8.2–8.5.

I giudizi sono netti. Wiz definisce queste falle «tra le vulnerabilità più gravi scoperte in PHP». Secondo dichiarazioni riportate dalla stampa, il National Cyber Security Centre (NCSC) del Regno Unito ha raccomandato di scollegare dalla rete i sistemi che non possono ricevere subito la patch. Anche il CERT-EU ha consigliato di isolare le applicazioni esposte su internet finché la patch non è stata applicata. Il ricercatore di sicurezza Kevin Beaumont ha riassunto bene il quadro: «La situazione di PHP porterà a una massa di incidenti».

Come è emersa? La cronologia

La storia di PHP2Shell inizia nel 2024 e si trasforma in una delle settimane più turbolente del 2026 per la sicurezza informatica. Tutti gli orari sono in UTC.

Al momento della pubblicazione, nessuna fonte pubblica ha confermato che un server specifico sia stato effettivamente compromesso tramite queste falle. Ma i tentativi sono iniziati e i ricercatori si aspettano una lunga coda. Nelle parole dell'esperto di incident response Hal Pomeranz: «Questa vicenda avrà una lunga coda».

Il fattore AI: la distanza tra patch ed exploit ora si misura in ore

C'è un altro dettaglio che fa di PHP2Shell una storia tipicamente del 2026: i modelli AI hanno avuto un ruolo sia nella scoperta della falla sia nell'individuazione del percorso di sfruttamento. Il team Codex Security di OpenAI ha segnalato in modo indipendente una delle scoperte. Wiz, da parte sua, scrive: «I modelli AI di frontiera hanno ridotto sostanzialmente quella barriera, trasformando una falla di lunga data in un exploit». Un bug rimasto teorico nel 2024 è diventato un'arma nel 2026 con l'aiuto delle macchine. Per chi difende, il messaggio è chiaro: il conto alla rovescia parte nel momento in cui viene rilasciata una patch e il lusso del «ce ne occupiamo nel fine settimana» non esiste più.

Che cosa succede sotto il cofano? Due falle, due cause principali diverse

Entrambe le vulnerabilità sono bug di sicurezza della memoria. Entrambe riguardano il modo in cui PHP gestisce gli errori fatali (in particolare quelli di esaurimento della memoria) che si verificano durante l'elaborazione di una richiesta. I meccanismi, però, sono diversi.

CVE-2026-109618: dati «a metà» nel momento in cui la memoria si esaurisce

Quando durante una richiesta viene superato il limite di memoria (out-of-memory, OOM), PHP esce bruscamente dal contesto corrente con un meccanismo chiamato longjmp() e interrompe la richiesta. L'advisory ufficiale descrive così il problema: in determinati punti, la memoria della richiesta diventa raggiungibile prima di essere stata completamente inizializzata. Se un'allocazione di memoria fallisce proprio in quel momento, PHP non tiene correttamente conto di questa uscita anticipata e la memoria resta in uno stato non valido. La routine di chiusura della richiesta legge poi questi dati rimasti a metà e agisce di conseguenza. Il risultato è una corruzione della memoria e, se l'attacco è costruito correttamente, l'esecuzione di codice.

Pensi alla cucina di un ristorante: un cameriere sta scrivendo una comanda quando viene chiamato altrove all'improvviso, e la comanda resta a metà. Il personale di chiusura la considera completa ed esegue tutto ciò che vi è scritto. Se un attaccante può completare a piacere quella comanda a metà, finisce per dirigere la cucina.

Come fa, allora, l'attaccante a colpire proprio quel momento? Le tecniche elencate nell'advisory sfruttano il formato multipart/form-data usato per il caricamento dei file:

• Le richieste multipart che non dichiarano una lunghezza del contenuto utilizzabile possono superare il controllo iniziale di post_max_size.
• Una singola parte multipart può contenere un numero illimitato di intestazioni.
• I campi file vuoti non vengono conteggiati nel limite max_file_uploads, ma creano comunque array di metadati dei file.
• I nomi di campo annidati moltiplicano il lavoro di costruzione degli array.

In sintesi, l'attaccante prepara una richiesta che porta PHP al limite della memoria proprio nel momento sbagliato. Come sottolinea Wiz, PHP analizza le richieste multipart all'avvio della richiesta, prima che sia completata la normale inizializzazione dei moduli. Apache mod_php, inoltre, esegue la routine di chiusura in modo incondizionato, anche se l'avvio della richiesta fallisce. Ecco perché l'intera catena può completarsi senza che venga eseguita una sola riga del codice della sua applicazione. La RCE completa è stata confermata via HTTP contro mod_php in una tipica configurazione prefork con più worker, con i limiti predefiniti di input e memoria di PHP. PHP-FPM è un caso diverso, perché il processo worker viene terminato quando l'avvio della richiesta fallisce: l'analisi del codice sorgente indica che anche FPM potrebbe essere interessato, ma per questa falla non è stato ancora dimostrato un exploit completo contro FPM.

CVE-2026-109619: il «fantasma» della richiesta precedente

I processi worker di PHP non gestiscono una sola richiesta per poi terminare: lo stesso processo serve molte richieste una dopo l'altra. PHP mantiene uno stato globale, per esempio quello di errori, sessioni, oggetti ed estensioni. L'advisory spiega che una parte di questo stato è conservata dal worker, ma punta in realtà a memoria che appartiene a una singola richiesta. Se una richiesta termina in un momento imprevisto, questi puntatori restano indietro. La richiesta successiva che arriva allo stesso worker tocca questo stato obsoleto prima che la normale inizializzazione abbia avuto modo di reimpostarlo. È un classico bug di tipo use-after-free (uso di memoria già liberata). Con un layout dell'heap costruito strategicamente, può portare alla piena esecuzione remota di codice.

L'analogia: in un hotel la tessera dell'ospite precedente funziona ancora e il nuovo ospite entra prima che la camera sia stata pulita. Dentro ci sono ancora le cose dell'ospite precedente.

Questa falla ha anche una dimensione di fuga di dati. Secondo Wiz, la divulgazione della memoria può includere password, token di autenticazione, chiavi API e certificati appartenenti ad altre richieste o al server stesso. Uno dei percorsi confermati è la funzione session upload progress. Questa funzione è attiva per impostazione predefinita e l'applicazione non deve nemmeno chiamare session_start(): la gestione della sessione può attivarsi prima della normale inizializzazione della sessione. L'advisory indica inoltre come secondo percorso confermato quello del backtrace degli errori fatali in PHP 8.5. La RCE tramite il ciclo di vita della sessione è stata confermata sia su mod_php sia su PHP-FPM.

Una nota importante: secondo le descrizioni ufficiali di PHP, CVE-2026-109618 riguarda i dati rimasti a metà nel momento in cui la memoria si esaurisce, mentre CVE-2026-109619 riguarda lo stato obsoleto che resta tra una richiesta e l'altra. Alcune fonti (tra cui Wiz) associano le tecniche di attacco ai numeri CVE in modo diverso. In questo articolo seguiamo le GitHub Security Advisories di PHP.

Chi è interessato? Tabella delle versioni

L'applicazione che utilizza non fa differenza. Wiz ha eseguito le sue dimostrazioni sulle immagini ufficiali di WordPress, Drupal e Joomla. Non perché queste piattaforme siano vulnerabili di per sé, ma perché girano tutte su PHP. Aggiornare il core di WordPress o i plugin non corregge questa vulnerabilità; a dover essere aggiornato è PHP stesso, sul server.

Per dare un'idea della scala: secondo l'analisi di Mallory basata sui dati di Shodan, al 20 ottobre su internet c'erano circa 884.000 server che dichiaravano PHP 8.1 o versioni precedenti nelle intestazioni HTTP. Queste versioni non possono ricevere patch ufficiali. È un conteggio delle intestazioni, non un numero verificato di sistemi interessati, ma mostra quanto potrebbe essere lunga la coda.

Che cosa ha fatto Partnerfy? Una difesa a 6 livelli che non ha aspettato la patch

Quando è trapelata la notizia della vulnerabilità, il quadro era limpido: la patch ufficiale era ancora lontana ore, mentre gli attaccanti si stavano già preparando. Per di più, con tutto il mondo che cercava di scaricare gli aggiornamenti nello stesso momento, i repository dei pacchetti erano sotto forte carico e si bloccavano. Non ci siamo quindi accontentati di un «aspettiamo la patch». Abbiamo costruito la nostra difesa livello per livello.

1. Risposta anticipata: una mitigazione temporanea ore prima della patch ufficiale

Il nostro team DevOps ha seguito da vicino la notizia della fuga di informazioni e le prime valutazioni tecniche e, circa tre ore prima del rilascio della patch ufficiale, ha disattivato session.upload_progress.enabled su tutto il server. È esattamente la mitigazione temporanea che PHP raccomanda per CVE-2026-109619. E non ci siamo limitati ad azionare l'interruttore: lo abbiamo azionato nel punto giusto. Il team di PHP richiede che questa impostazione venga applicata a livello di configurazione principale (php.ini / configurazione del server), non tramite ini_set() o .user.ini. La nostra modifica è stata fatta esattamente a quel livello e verificata nella configurazione attiva.

2. Il livello edge: filtrare gli attacchi prima che raggiungano il server

Il nostro sito aziendale, partnerfy.co, e i progetti che serviamo dietro Cloudflare sono protetti dalla rete edge di Cloudflare. Cloudflare ha distribuito per impostazione predefinita il suo primo set di regole WAF contro i vettori PHP2Shell noti nelle prime ore del 21 ottobre. Di conseguenza, una quota significativa delle richieste sospette viene filtrata prima ancora di raggiungere i nostri server. Poiché risulta che gli attaccanti stiano modificando i payload per aggirare le regole iniziali, non consideriamo mai questo livello sufficiente da solo: gli altri livelli sono subito dietro.

3. Hardening della configurazione PHP: bloccare la mossa successiva dell'attaccante

La configurazione PHP dei nostri server era stata sottoposta ad hardening molto prima di questa crisi. Le funzioni che eseguono comandi di sistema (system, popen, proc_open e simili) sono disattivate; l'inclusione remota di file (allow_url_include) è disattivata. Siamo franchi: una RCE a livello di memoria potrebbe, in teoria, aggirare queste restrizioni. Nel mondo reale, però, la prima mossa di un attaccante è di solito aprire una shell di comandi, scaricare strumenti o piazzare una web shell. Queste restrizioni rendono quei passaggi critici di post-exploitation molto più difficili e molto più rumorosi. E rumore significa farsi scoprire.

4. Isolamento degli account: anche se si apre una porta, il corridoio resta chiuso

Ogni account sui nostri server gira nella propria «gabbia» isolata del file system. Anche se in un account si verificasse lo scenario peggiore, la capacità dell'attaccante di spostarsi lateralmente verso i file e i processi di altri account sarebbe fortemente limitata. Un anello spezzato non significa che si spezzi l'intera catena.

5. Backup per gli scenari di disastro: pronti al peggio

In vista della finestra di patching, abbiamo eseguito backup completi degli account sui nostri server. L'obiettivo è semplice: se qualcosa va storto, la domanda non è «che cosa abbiamo perso?», ma «a quale punto di ripristino pulito torniamo?». Una buona strategia di sicurezza non consiste solo nel bloccare gli attacchi, ma anche nel saper tornare rapidamente a uno stato pulito se un attacco va a segno.

6. Patch, riavvii e ricerca degli indicatori

Man mano che i pacchetti ufficiali con la patch arrivano nei canali delle distribuzioni, li applichiamo ai nostri server e poi riavviamo tutti i worker PHP. Il riavvio non è negoziabile: i vecchi worker che restano in esecuzione continuano a usare il vecchio codice. Poiché la patch introduce un nuovo limite rigido di memoria, stiamo rivedendo anche le nostre impostazioni di memoria alla luce di questa novità.

Nel frattempo abbiamo passato al setaccio i nostri log di accesso alla ricerca degli indicatori descritti dai ricercatori. Un esempio concreto: circa tre ore dopo il rilascio della patch, una serie di richieste POST ha colpito la root del nostro sito e percorsi come /api e /app da un unico indirizzo IP cloud che si spacciava, uno dopo l'altro, per vari bot di motori di ricerca e di AI (CCBot, Amazonbot, ClaudeBot e altri). Ognuna di queste richieste è stata respinta con un 403 dal livello di sicurezza lato server prima di poter raggiungere la nostra applicazione. Non possiamo affermare con certezza che si trattasse di tentativi PHP2Shell, ma la tempistica e lo schema delle false identità sono coerenti con la scansione di massa iniziata dopo la patch. Al momento della pubblicazione, non abbiamo rilevato alcun segno di compromissione sui nostri sistemi.

L'approccio di Partnerfy: non affidiamo mai la sicurezza a una sola serratura. Filtraggio sull'edge, hardening sul server, isolamento tra gli account, backup alle spalle, risposta rapida in prima linea. Se un livello viene violato, quello successivo è già in servizio.

Che cosa deve fare? Una checklist passo dopo passo

1. Individuare la versione di PHP

Se usa cPanel, può controllarla nella schermata «MultiPHP Manager» o «Select PHP Version»; se ha accesso al server, usi php -v. Attenzione: la versione di PHP della riga di comando può essere diversa da quella che esegue il sito web. Il metodo più affidabile è chiedere al suo provider di hosting quale versione di PHP utilizza il sito, oppure verificarla con una pagina phpinfo() temporanea da eliminare subito dopo. Se è su un hosting condiviso, l'aggiornamento spetta al provider di hosting, non a Lei. Chieda oggi stesso: «Avete applicato la patch per PHP2Shell?»

2. Aggiornare e riavviare

Versioni di destinazione: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Nei pacchetti delle distribuzioni Linux, il numero di versione può apparire diverso. Come raccomanda anche Debian, cerchi il numero CVE nel changelog del pacchetto anziché fare affidamento sul numero di versione. Dopo l'aggiornamento, riavvii Apache, PHP-FPM e tutti i worker PHP a lunga esecuzione.

3. Se non può aggiornare subito: mitigazioni temporanee

Partiamo dall'avvertenza dello stesso progetto PHP: queste misure «riducono l'esposizione a specifici percorsi di attacco, ma non rendono sicura un'installazione». L'unica soluzione completa è aggiornare.

4. Se usa una vecchia versione di PHP: l'upgrade non può aspettare

PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti dal progetto PHP. Per un sito che gira su queste versioni, la vera soluzione non è una patch, ma un upgrade. Ricordi: anche il supporto di PHP 8.2 termina il 31 dicembre 2026. Passare oggi alla 8.2.35 la toglierà dai guai, ma se entrerà nel 2027 con la 8.2, alla prossima crisi non ci sarà alcuna patch per Lei. Se il suo codice legacy non gira sulle versioni più recenti di PHP, è il segnale che è arrivato il momento di un progetto di modernizzazione del software.

5. Verificare i segni di compromissione

Indicatori che i ricercatori raccomandano di verificare dopo l'applicazione della patch:

• Richieste multipart insolite seguite immediatamente da errori di limite di memoria o raffiche di risposte HTTP 500
• Cookie PHPSESSID inaspettatamente grandi o malformati
• Riavvii o crash inspiegabili dei worker PHP
• Processi php-fpm, httpd o apache2 che avviano una shell, un interprete o uno strumento di download (come sh, bash, curl o wget)
• Nuovi file nella web root (web shell), nuovi cron job, nuovi account utente

Poiché l'attacco avviene al di sotto del livello applicativo, può lasciare pochissime tracce nei log dell'applicazione. Controlli i log del web server e di PHP. Se qualcosa appare sospetto, isoli il server, conservi i log e poi indaghi. Poiché CVE-2026-109619 può portare anche alla divulgazione della memoria, in caso di dubbio conviene inoltre ruotare password dei database, chiavi API e segreti di sessione.

La lezione di questa crisi: la sicurezza non è un prodotto, è un riflesso

PHP2Shell ha reso evidenti tre cose. Primo: per quanto pulita sia la sua applicazione, la sicurezza dipende dalla piattaforma su cui gira. Secondo: nell'era dell'AI, la distanza tra patch ed exploit si è ridotta a una questione di ore. Terzo: quando si verificano fughe di notizie e violazioni dell'embargo, l'approccio «ci atteniamo al calendario ufficiale» crolla. Vince chi legge la notizia nella prima ora, applica la mitigazione temporanea, tiene pronti i backup e non affida mai la difesa a una sola serratura.

In Partnerfy questo riflesso è di serie nei nostri servizi di managed hosting e gestione dei server, sicurezza informatica e backup e disaster recovery. Come software house con sede a Sakarya e uffici in Turchia, Germania, Russia e Irlanda, possiamo aiutarla a stabilire su quale versione di PHP gira il suo sito, se è esposto a PHP2Shell e come prepararsi alla fine del supporto di PHP 8.2. Ci contatti e verifichiamo insieme il suo sito.

Fonti

• PHP: annuncio di sicurezza del 21 ottobre 2026
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (RCE tramite corruzione OOM)
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (RCE tramite stato globale obsoleto)
• The PHP Foundation: il rilascio di sicurezza di oggi e come stiamo rafforzando la sicurezza di PHP
• Wiz: ricerca su PHP2Shell
• Help Net Security: corrette le vulnerabilità PHP2Shell
• The Hacker News: PHP rilascia patch d'emergenza per due falle critiche

Domande frequenti