PHP2Shell: due falle di PHP che consegnano il server prima ancora del sito

Questa volta il problema non è WordPress o Prestashop o il plugin dimenticato ma PHP stesso

Quando leggiamo di una vulnerabilità critica in un sito PHP siamo abituati a cercare immediatamente il componente responsabile, il plugin non aggiornato, il modulo scritto male, il CMS vecchio oppure quella funzione lasciata online anni fa e mai più guardata, ma con CVE-2026-109618 e CVE-2026-109619 questo riflesso rischia di farci perdere proprio la gravità del problema perché la falla si trova nel motore PHP, cioè sotto l'applicazione, ed è per questo che Wiz Research (un gruppo multidisciplinare di esperti di sicurezza) ha dato all'intera ricerca un nome molto efficace, PHP2Shell. Il 21 ottobre 2026 il progetto PHP ha pubblicato in emergenza PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 dichiarando che entrambe le vulnerabilità possono consentire Remote Code Execution senza autenticazione, con punteggio CVSS v4.0 pari a 9,2, ed ha usato una formulazione insolitamente netta per un progetto maturo come PHP, ovvero "non esistono mitigazioni complete e l'aggiornamento è l'unica soluzione realmente affidabile".

La cosa che rende questa vicenda molto diversa da tante altre CVE è che l'attaccante non deve necessariamente trovare un errore nella nostra applicazione, ma come Wiz ha dimostrato pre-authentication RCE su installazioni di WordPress, Drupal e Joomla, espressamente che quei CMS sono stati scelti come bersagli rappresentativi e la vulnerabilità risiede nel runtime, tanto che perfino una applicazione Hello World può trovarsi esposta se gira sopra una versione vulnerabile e se ricorrono le condizioni necessarie all'exploit. Questo significa che possiamo avere codice applicativo perfettamente aggiornato, nessuna SQL injection, nessun plugin compromesso e nessuna password debole e continuare ugualmente ad avere una superficie critica perché l'errore nasce nel modo in cui PHP interrompe, pulisce e riutilizza la memoria fra una richiesta HTTP e l'altra.

CVE-2026-109618 : un upload troppo grande che manda PHP in OOM? Anche, ma non solo.

La descrizione più immediata di CVE-2026-109618 è corretta ma va precisata, perché non basta inviare un file enorme e sperare che il server finisca la RAM perchè PHP dispone del proprio memory_limit e quando una richiesta supera quella soglia il motore deve interrompere l'esecuzione in una situazione nella quale continuare ad allocare memoria non è più possibile. Il problema in questo caso sta proprio nel meccanismo di risoluzione dell'errore, perchè per uscire rapidamente da alcuni percorsi PHP utilizza un meccanismo di bailout basato su longjmp(), cioè un salto fuori dal punto nel quale il motore si trova senza attraversare necessariamente la stessa sequenza ordinaria di ritorni e cleanup che avrebbe seguito in una conclusione normale della richiesta, ed il problema scoperto dai ricercatori è che alcune strutture interne potevano risultare già pubblicate come se fossero utilizzabili mentre una loro inizializzazione non era ancora realmente terminata, quindi un OOM nel momento sbagliato lasciava il motore in una specie di "terra di mezzo" nella quale il dato esisteva abbastanza da essere ritrovato dal cleanup ma non abbastanza da essere valido.

In termini meno astratti possiamo immaginare una struttura interna alla quale PHP abbia già riservato un posto e che il resto del motore consideri ormai presente, mentre l'allocazione necessaria per completarla fallisce. Il bailout interrompe il percorso, la richiesta comincia a essere smontata e il codice di pulizia incontra quella struttura credendo che sia stata inizializzata correttamente. A quel punto può leggere un puntatore non inizializzato, interpretare come valido un valore che non lo è oppure lavorare sopra memoria che nel frattempo contiene dati controllabili attraverso altre allocazioni. Non siamo quindi davanti ad un normale crash per memoria esaurita ma ad una violazione delle assunzioni interne del memory management, ed è questa differenza che trasforma un errore apparentemente di disponibilità in una primitiva di corruzione della memoria.

Wiz ha documentato più varianti appartenenti alla stessa famiglia. Una coinvolge la gestione dell'upload progress delle sessioni durante il parsing multipart, una fase particolarmente delicata perché può avvenire molto presto nella vita della richiesta, prima che l'applicazione PHP abbia davvero iniziato a fare il proprio lavoro, ed un'altra consente perfino la divulgazione remota di memoria appartenente al processo. Quest'ultimo punto è importante perché ci ricorda che il danno non comincia necessariamente con una shell: se un processo PHP contiene password, token, cookie, chiavi API oppure altri segreti temporaneamente presenti in memoria, una vulnerabilità di memory disclosure può diventare già da sola una compromissione gravissima.

Il dettaglio più inquietante: in mod_php l'attacco può arrivare prima del nostro codice

Il progetto PHP considera a rischio tutte le installazioni PHP che servono richieste web, comprendendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed, ma indica mod_php come scenario a rischio particolarmente elevato perché è stata dimostrata una catena nella quale una richiesta non autenticata può raggiungere il percorso vulnerabile prima che il codice applicativo venga eseguito. Questo cambia parecchio il modo in cui normalmente ragioniamo sulla difesa: una validazione inserita nell'applicazione, un controllo nel framework oppure un filtro scritto nel CMS possono non avere ancora avuto la possibilità di intervenire quando PHP sta già processando il corpo HTTP e costruendo le proprie strutture interne.

PHP-FPM non è magicamente al sicuro. Alcuni percorsi di fallimento iniziale possono terminare il worker prima che lo stato corrotto diventi riutilizzabile e questo rende determinate varianti più difficili rispetto a mod_php, motivo per cui Red Hat valuta alcuni scenari FPM come condizionali, ma Wiz e il PHP Security Team hanno comunque dimostrato percorsi di RCE anche con FPM attraverso fasi applicative e stato persistente. La differenza corretta non è quindi mod_php vulnerabile e FPM sicuro, ma mod_php più direttamente esposto ad alcune catene e FPM dipendente maggiormente dalla configurazione e dal comportamento dell'applicazione.

CVE-2026-109619: quando la richiesta finisce ma un pezzo di lei rimane vivo

La seconda vulnerabilità è forse ancora più interessante dal punto di vista architetturale perché sfrutta una proprietà fondamentale dei server PHP moderni: il processo che esegue una richiesta spesso non muore quando quella richiesta termina. Un worker PHP-FPM oppure un processo Apache con mod_php può gestire molte richieste una dopo l'altra, e per ragioni di prestazioni PHP mantiene una quantità di stato globale e di strutture persistenti che sopravvivono al ciclo di vita del singolo script. È perfettamente normale, fino a quando nessun puntatore globale continua a indicare memoria che apparteneva alla richiesta precedente e che è stata ormai liberata.

CVE-2026-109619 nasce proprio qui. In alcuni percorsi un fatal error può interrompere l'esecuzione prima che tutto lo stato venga riportato ad una condizione pulita, oppure può ripopolare una struttura dopo che il reset è già avvenuto, e il risultato è un riferimento che sopravvive mentre la memoria alla quale puntava viene restituita all'allocator. Quando lo stesso worker riceve una richiesta successiva, quel riferimento può essere consultato prima che la normale inizializzazione lo sostituisca. In sicurezza questo ha un nome classico, use-after-free: il programma utilizza un oggetto dopo che lo spazio di memoria che lo conteneva non appartiene più a quell'oggetto.

Il rischio diventa evidente se pensiamo che la memoria liberata non resta necessariamente vuota. Può essere riutilizzata per una nuova stringa, un nuovo buffer oppure un'altra struttura prodotta dalla richiesta successiva, e il vecchio puntatore continua a guardare lo stesso indirizzo credendo di trovarci ancora l'oggetto precedente. Se l'attaccante riesce a influenzare ciò che viene riallocato in quella zona, un semplice errore di stato può trasformarsi in corruzione controllata della memoria e da lì, con una catena sufficientemente sofisticata, in esecuzione di codice.

Non c'è soltanto il worker sporco: OPcache porta il problema nello stato condiviso

Ridurre CVE-2026-109619 al concetto di richiesta precedente che sporca quella successiva sarebbe comunque incompleto. Wiz ha documentato anche una variante che coinvolge OPcache, cioè proprio il componente che normalmente utilizziamo per migliorare le prestazioni conservando in memoria condivisa strutture PHP già compilate. Durante la persistenza di uno script, OPcache mantiene indici e mappe che devono rimanere coerenti fra stato locale del processo e stato condiviso. Un fallimento di allocazione nel momento sbagliato può far avanzare il riferimento locale senza pubblicare correttamente quello condiviso, lasciando strutture parzialmente persistite che indicano slot considerati ancora disponibili dal resto del sistema.

Quando un altro worker riutilizza successivamente lo stesso slot per un oggetto differente, il vecchio metadato può interpretare quel puntatore come appartenente al tipo precedente. Questa è una type confusion, cioè il programma usa memoria valida ma la interpreta come il tipo di oggetto sbagliato, ed è una classe di vulnerabilità capace di produrre corruzioni molto profonde perché rompe le assunzioni sulle strutture condivise fra processi. Wiz ha utilizzato proprio questa primitiva per dimostrare una RCE non autenticata contro WordPress. È un dettaglio che considero importante perché mostra quanto sia fuorviante immaginare il problema come un semplice worker che andrebbe riavviato: alcune varianti arrivano a toccare uno stato condiviso che esiste precisamente per essere riutilizzato da più worker.

Esempio concreto: un ecommerce può essere compromesso senza avere una falla nell'ecommerce

Immaginiamo un negozio online perfettamente aggiornato che gira su PHP vulnerabile. Il front controller, il framework, i moduli di pagamento e perfino il tema possono non contenere nessuna vulnerabilità sfruttabile, ma se una richiesta costruita per raggiungere uno dei percorsi PHP2Shell ottiene esecuzione di codice, l'attaccante entra con i privilegi del processo web e da quel momento il confine di sicurezza non è più quello dell'applicazione ma quello del sistema operativo.

Non significa automaticamente diventare root, ed è importante dirlo con precisione. Una RCE PHP normalmente consegna inizialmente i privilegi dell'utente con cui gira Apache o PHP-FPM, per esempio www-data oppure un account dedicato al pool, ma in moltissime installazioni quell'utente può leggere il codice dell'applicazione e quindi file di configurazione, credenziali del database, secret utilizzati per firmare sessioni, password SMTP, token di servizi esterni oppure chiavi API lasciate nelle variabili d'ambiente. Un ecommerce compromesso in questo modo può quindi subire furto del database, manipolazione del catalogo, creazione di account amministrativi attraverso credenziali già disponibili al processo, modifica dei file scrivibili e inserimento di codice capace di intercettare dati o alterare ciò che il cliente vede durante il checkout. Se il pagamento avviene completamente su un provider esterno il server potrebbe non vedere mai il numero della carta, ma un attaccante che può modificare il front-end può comunque tentare di cambiare il flusso, sostituire destinazioni, raccogliere credenziali oppure introdurre uno skimmer nel codice servito ai browser.

Questo è il motivo per cui dire «il sito non ha falle» non è una difesa. L'applicazione può essere innocente e trovarsi ugualmente seduta sopra un runtime compromettibile.

Un secondo scenario grave: la RCE dura pochi minuti ma le credenziali rubate durano mesi

C'è poi uno scenario che considero ancora più pericoloso perché può sopravvivere alla semplice applicazione della patch. Un aggressore ottiene esecuzione per un tempo breve, legge i segreti che il processo può raggiungere e se ne va senza lasciare necessariamente una modifica evidente nei file. Può trattarsi della password del database, di un token per un servizio di storage, di credenziali SMTP, di un segreto JWT, di una chiave per un gateway esterno oppure di credenziali presenti in un file .env montato dentro un container.

A quel punto noi aggiorniamo PHP e chiudiamo la vulnerabilità, ma la credenziale rubata continua ad essere valida. Il server non è più vulnerabile a PHP2Shell e tuttavia l'incidente non è finito, perché il problema si è spostato fuori da PHP. È per questo che in un sistema rimasto esposto durante la finestra di rischio non basta chiedersi «ho installato 8.3.36?», occorre chiedersi anche se esista un motivo per sospettare compromissione precedente e, in caso affermativo, ruotare i segreti realmente accessibili al processo, controllare file modificati, account amministrativi, processi anomali e accessi ai servizi collegati.

Wiz ha dimostrato inoltre una variante di memory disclosure capace di leggere dati direttamente dalla memoria del worker senza arrivare prima alla RCE. In un processo web la memoria è un posto molto più interessante di quanto sembri, perché può contenere per pochi millisecondi proprio il token o la password che sul disco sono protetti correttamente. Una falla che legge memoria viva può quindi attraversare difese che erano state progettate pensando soltanto alla protezione dei file.

Un terzo scenario: il container limita il danno, ma non salva automaticamente l'applicazione

Molte infrastrutture moderne eseguono PHP-FPM dentro Docker oppure Kubernetes e questo certamente migliora l'isolamento, ma anche qui bisogna evitare una falsa sicurezza. Una RCE dentro il container non equivale automaticamente ad una container escape e quindi non possiamo dire che l'attaccante abbia conquistato l'host, ma il container dell'applicazione possiede normalmente esattamente le risorse necessarie per fare il proprio lavoro: codice, configurazioni, connessione al database, rete verso Redis, servizi interni, volumi montati e spesso token con cui parlare ad altri componenti.

Se comprometto il processo PHP di un'applicazione containerizzata posso quindi non avere alcun bisogno di uscire dal container per produrre un danno enorme. Posso utilizzare i privilegi già concessi al workload e trasformare un principio corretto di least privilege nella misura reale del danno massimo: se il container può leggere soltanto una specifica banca dati, il danno può fermarsi lì; se può raggiungere reti interne estese, storage condivisi e credenziali cloud troppo potenti, la RCE diventa il primo anello di un movimento laterale molto più ampio. PHP2Shell non crea quella cattiva architettura, ma può essere il punto dal quale iniziare ad approfittarne.

Un quarto scenario: WordPress compromesso senza aspettare il plugin vulnerabile

Wiz ha dimostrato l'impatto proprio su WordPress, Drupal e Joomla nelle immagini container più recenti disponibili durante la ricerca. Questo dettaglio ha un valore pratico enorme perché abitualmente quando WordPress viene compromesso la prima indagine parte da plugin e temi, mentre in questo caso si può avere una installazione aggiornata che continua ad essere attaccabile per colpa della versione PHP sottostante.

Una volta ottenuti i privilegi del processo web, il resto dipende dalla configurazione. Se il processo può scrivere nel document root, la persistenza può passare attraverso modifiche ai file; se il filesystem è read-only il problema si restringe ma non scompare, perché database e servizi remoti possono restare raggiungibili; se wp-config.php è leggibile, le credenziali del database sono normalmente disponibili perché WordPress stesso deve poterle usare. La lezione più importante è che un CMS hardenizzato sopra un runtime vulnerabile non è realmente hardenizzato, esattamente come una porta blindata installata su una parete che può essere attraversata.

Perché Apache mod_php è il caso che mi preoccuperebbe di più

Il PHP Security Team indica esplicitamente Apache mod_php come scenario di rischio massimo fra quelli comuni perché una delle catene dimostrate raggiunge il bug durante il parsing della richiesta, prima del codice applicativo, con configurazioni molto vicine a quelle normali. In un processo Apache che incorpora direttamente il runtime PHP, inoltre, lo stato e la vita del worker seguono un modello diverso da un pool FPM separato e alcune primitive risultano più direttamente sfruttabili.

Questo non significa che chi usa Nginx più PHP-FPM possa ignorare l'emergenza, ma se dovessi stabilire una priorità operativa metterei immediatamente in cima i server Internet-facing ancora basati su mod_php e subito dopo qualsiasi FPM esposto attraverso applicazioni che accettano upload, multipart, importazioni o percorsi capaci di generare fatal error controllabili dall'esterno. Il CVSS v4 assegna ad entrambe le vulnerabilità 9,2 pur marcando la complessità dell'attacco come alta e la presenza di requisiti particolari, perché non servono autenticazione né interazione dell'utente e l'impatto può essere completo su confidenzialità, integrità e disponibilità.

La complessità dell'exploit non è più una consolazione come lo era qualche anno fa

Questa vicenda contiene anche una seconda storia che riguarda direttamente il modo in cui dobbiamo leggere le vulnerabilità complesse nell'era dell'AI. Wiz spiega che le primitive esistevano nel codice PHP da più di un decennio ma trasformarle in exploit affidabili richiedeva concatenare più errori, comprendere molto bene l'allocator, adattarsi alle differenze di versione, configurazione e layout della memoria e ripetere continuamente test e debugging. Era precisamente il genere di vulnerabilità che poteva essere teoricamente grave ma economicamente poco conveniente da weaponizzare su larga scala.

Nel 2026 questa assunzione è molto meno solida. Wiz ha utilizzato Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol durante ricerca, sviluppo degli exploit e validazione delle patch, mentre OpenAI ha comunicato che Calif aveva individuato indipendentemente una falla critica utilizzando GPT-5.6 Sol nell'ambito del programma Patch the Planet. Il punto non è fare pubblicità ad un modello, è osservare che una parte del lavoro specialistico necessario per adattare una exploit chain a versioni e configurazioni differenti può ormai essere accelerata enormemente da sistemi capaci di leggere codice, analizzare crash, proporre ipotesi e iterare sui risultati.

Wiz scrive esplicitamente che ciò cambia l'economia dell'exploit development: una complessità che prima costituiva una barriera pratica può diventare affrontabile in ore invece che in tempi molto più lunghi. È un cambiamento importante anche per chi amministra sistemi, perché la frase «sì, è critica, ma l'exploit è complicato» vale molto meno quando lo stesso software che aiuta i difensori a trovare il bug può aiutare qualcuno ad adattarne rapidamente una variante offensiva.

E infatti qualcuno stava già provando prima della pubblicazione

Il dato più delicato arriva da Amazon Threat Intelligence. La rete di honeypot MadPot ha registrato un tentativo di sfruttamento riconducibile a PHP2Shell il 17 ottobre 2026, quattro giorni prima della divulgazione pubblica, proveniente da un indirizzo associato ad una rete commerciale di anonimizzazione. AWS precisa correttamente che non sappiamo come l'attore abbia ottenuto le informazioni e che osservare un tentativo contro un honeypot non equivale a dimostrare la compromissione riuscita di un server di produzione, ma il fatto che traffico coerente con l'exploit fosse già presente durante l'embargo modifica parecchio la gestione del rischio.

Il 21 ottobre AWS ha poi osservato molteplici proof of concept circolare già nelle ore precedenti al rilascio pubblico, mentre watchTowr ha segnalato tentativi sui propri honeypot. In altre parole non siamo nella fase nella quale possiamo dire «patchiamo con calma perché ancora nessuno conosce i dettagli». I dettagli tecnici sono pubblici, le patch sono pubbliche, la ricerca di Wiz è estremamente approfondita e l'attività di probing è già stata osservata. Da questo momento il vantaggio temporale appartiene a chi aggiorna prima che uno scanner trovi il server dimenticato.

Quali versioni sono vulnerabili e perché PHP 8.1 o PHP 7 rappresentano un problema aggiuntivo

Le release upstream corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Le fonti coordinate, comprese Cloudflare e Google Cloud, indicano che la famiglia di bug raggiunge PHP 5.4 e le generazioni successive, quindi i vecchi PHP 5, PHP 7 e PHP 8.0 o 8.1 non diventano sicuri semplicemente perché non compaiono nell'elenco delle quattro release corrette: sono rami fuori supporto upstream e PHP non sta pubblicando nuove release di sicurezza per essi.

Qui esiste una sola cautela importante per gli amministratori Linux. Alcune distribuzioni enterprise applicano backport delle patch mantenendo una versione nominale che può sembrare più vecchia, quindi la verifica non deve limitarsi ciecamente all'output di php -v senza consultare l'advisory del proprio vendor. Se invece utilizziamo build upstream, container ufficiali oppure pacchetti che non ricevono backport specifici, la regola è molto semplice: dobbiamo arrivare almeno alla release corretta del ramo supportato, oppure migrare ad un ramo che lo sia.

Aggiornare WordPress non serve, aggiornare PHP sì

È una frase banale ma in questa emergenza è fondamentale. Aggiornare WordPress, Prestashop, Drupal, Joomla, Laravel, Symfony oppure il plugin di turno NON corregge CVE-2026-109618 e CVE-2026-109619 perché il codice vulnerabile si trova nel runtime PHP. Allo stesso modo cambiare password amministrativa, disabilitare XML-RPC oppure nascondere la pagina di login non chiude la falla.

Dopo l'aggiornamento bisogna inoltre assicurarsi che i vecchi worker siano realmente terminati. Su FPM questo significa applicare il nuovo pacchetto e riavviare o ricaricare correttamente il servizio secondo la procedura della distribuzione, mentre con mod_php occorre fare in modo che Apache non continui a mantenere processi costruiti con la vecchia libreria. Nei container significa ricostruire o sostituire l'immagine vulnerabile e verificare che non esistano repliche ancora in esecuzione con il vecchio runtime.

Un controllo minimo può partire dalla versione effettivamente utilizzata dal servizio web e non soltanto da quella della CLI, perché su macchine che ospitano più release PHP è comunissimo avere php -v che mostra una versione mentre il pool FPM del sito ne usa un'altra. Il principio corretto è inventariare ogni runtime PHP realmente esposto e confrontarlo con la correzione fornita dal progetto o dal proprio distributore.

Le mitigazioni temporanee esistono, ma PHP stesso dice di non fidarsi troppo

La documentazione ufficiale propone alcune riduzioni del rischio per chi non riesce ad aggiornare immediatamente, ma insiste sul fatto che nessuna sostituisce la patch. Per CVE-2026-109618 una mitigazione contro i percorsi confermati consiste nell'eliminare il memory_limit PHP impostandolo amministrativamente a -1 e spostare il vero limite di disponibilità a livello di container o cgroup, insieme a limiti conservativi sulla dimensione delle richieste e degli upload. Sembra controintuitivo togliere il limite di memoria per mitigare un bug da out-of-memory, ma il motivo è precisamente evitare il bailout PHP prevedibile e controllabile che porta nella condizione vulnerabile. Rimane comunque possibile un fallimento dell'allocazione sottostante e quindi non è una correzione completa.

Per CVE-2026-109619 il progetto suggerisce, fra le mitigazioni temporanee, di disabilitare session.upload_progress e riavviare tutti i worker, mentre su PHP 8.5 disabilitare fatal_error_backtraces blocca uno dei percorsi confermati. Anche qui il linguaggio dell'advisory è importante: bloccare una variante non significa aver eliminato l'intera classe di bug. WAF, limiti multipart e regole del reverse proxy possono ridurre l'esposizione ai percorsi oggi conosciuti, e Cloudflare, AWS ed altri provider hanno distribuito protezioni coordinate, ma nessun amministratore dovrebbe trasformare una regola WAF in una scusa per non aggiornare.

Dopo la patch resta la domanda più scomoda: qualcuno è già entrato?

Quando una vulnerabilità permette RCE pre-authentication ed esistono tentativi osservati prima della disclosure, la patch chiude la porta ma non ci dice se sia stata aperta ieri. Per i server Internet-facing che sono rimasti vulnerabili durante questa finestra considero ragionevole almeno una verifica mirata: richieste multipart anomale, errori OOM insoliti, uso inatteso dei meccanismi di session upload progress, processi figli avviati dal web server, file PHP modificati senza una ragione amministrativa, nuovi account applicativi, accessi inconsueti al database e utilizzo anomalo di credenziali che il processo PHP poteva leggere.

Non significa che ogni server non patchato sia già compromesso, e sarebbe allarmismo dirlo, ma significa che la sola assenza di un defacement non dimostra nulla. Un attaccante interessato alle credenziali non ha nessun motivo per cambiare la homepage, e chi ottiene un token valido può preferire abbandonare immediatamente la macchina e utilizzarlo da un'altra infrastruttura. Più il server contiene segreti di valore e più la risposta all'incidente deve comprendere il perimetro delle credenziali accessibili, non soltanto il filesystem.

Il vero insegnamento di PHP2Shell è che la sicurezza dell'applicazione finisce dove comincia quella del runtime

Queste due CVE sono interessanti perché rompono una separazione mentale molto diffusa. Noi sviluppatori tendiamo a pensare alla sicurezza del codice applicativo e i sistemisti alla sicurezza del runtime, del sistema operativo e della rete, ma un'applicazione web è il prodotto di tutti questi strati contemporaneamente. Una request può essere perfettamente innocua per il framework e pericolosa per il parser sottostante; un CMS può essere aggiornato e poggiare su un interprete vulnerabile; un container può essere isolato e contenere credenziali sufficienti a compromettere comunque il servizio; un WAF può bloccare la variante conosciuta e non quella che verrà pubblicata domani.

La cosa più impressionante di PHP2Shell non è quindi soltanto che due bug possano produrre una RCE, perché nella storia di PHP e del web abbiamo già visto vulnerabilità gravissime, ma che il punto di rottura sia un meccanismo interno utilizzato da più di dieci anni e che la sua exploitability pratica sia cambiata anche perché oggi disponiamo di strumenti AI capaci di accompagnare ricercatori ed attaccanti dentro una complessità che fino a pochi anni fa costituiva essa stessa una forma imperfetta di difesa.

Per chi amministra PHP la conseguenza pratica è molto meno filosofica: se il server usa una release vulnerabile, questo non è il fine settimana nel quale rimandare l'aggiornamento a lunedì. Il bug è nel motore, l'attacco può arrivare senza login e l'applicazione sopra di lui potrebbe non avere nemmeno il tempo di accorgersene!