PHP2Shell: l'IA aiuta a scoprire due falle critiche del core PHP risalenti al 2012

Il 21 ottobre 2026 il progetto PHP ha pubblicato quattro release di emergenza per correggere due vulnerabilità a livello di motore che consentono l'esecuzione di codice remoto non autenticata. Le correzioni sono arrivate in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e le due falle, CVE-2026-109618 e CVE-2026-109619, sono valutate CVSS v4.0 9,2. La debolezza di fondo è vecchia. Secondo l'analisi tecnica di Calif, il percorso di codice interessato più datato risale a PHP 5.4.0, una release del 2012, di oltre dieci anni fa. Parte di ciò che rende il caso notevole è quante volte la debolezza era già stata notata e messa da parte.

01Due bug, una sola causa

Entrambe le falle risiedono nel runtime di PHP, non in WordPress, Magento o in qualche plugin. Calif ha riferito che un attaccante non autenticato potrebbe eseguire codice su installazioni standard di Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel e Symfony, tra gli altri. Sansec osserva che, essendo la falla nel motore, gli store sono colpiti anche quando il loro codice è pulito.

Il meccanismo comune è il modo in cui PHP gestisce le condizioni fatali. Quando una richiesta supera il proprio memory_limit (128 MiB per impostazione predefinita) o incontra un altro errore fatale, il motore in C non può srotolare lo stack passo dopo passo. Chiama zend_bailout(), un wrapper di longjmp(). Un longjmp abbandona qualunque codice C fosse in esecuzione, senza dare modo di completare le strutture dati lasciate a metà.

La tabella hash alla base di ogni array PHP, compreso $_POST, mostra il problema. L'analisi di Calif, riportata da Pentera, mostra che il contatore delle voci viene incrementato prima che la chiave sia allocata, quindi uno slot viene conteggiato come attivo prima che esistano la sua chiave e il suo valore. Se l'allocazione della chiave supera memory_limit, il bailout scatta esattamente in quel punto. Un campo con un nome annidato induce PHP a inserire il nome esterno come nuova chiave dell'array, quindi l'attaccante controlla la lunghezza della chiave. Dimensionandola in modo da superare memory_limit, il bailout cade sull'allocazione. La successiva pulizia si fida della voce inizializzata solo a metà.

Le due CVE si distinguono lungo il ciclo di vita della richiesta:

• CVE-2026-109618: corruzione della memoria durante la gestione dell'esaurimento di memoria, innescata all'avvio della richiesta, prima dell'esecuzione di qualsiasi script applicativo.
• CVE-2026-109619: lo stato interno di proprietà della richiesta sopravvive dopo la liberazione della memoria che lo sostiene, e una richiesta successiva sullo stesso worker può usare quello stato obsoleto prima che la normale inizializzazione lo azzeri. Rapid7 riferisce che l'advisory conferma una RCE contro mod_php tramite la funzione di backtrace degli errori fatali di PHP 8.5, attiva per impostazione predefinita, e una RCE legata al ciclo di vita delle sessioni contro mod_php e FPM.

CISA indica come superfici esposte Apache con mod_php (che PHP considera a rischio più alto), PHP-FPM, php-cgi, FrankenPHP e LiteSpeed.

02Perché è rimasto nascosto

Forzare una condizione di esaurimento di memoria è facile da descrivere e difficile da realizzare da remoto. Per impostazione predefinita PHP limita gli upload in ingresso con post_max_size, pari a 8 MiB. Una richiesta così piccola non può normalmente esaurire un heap da 128 MiB. Calif ha trovato il modo di aggirare il limite. PHP verifica post_max_size rispetto al Content-Length dichiarato ma non lo applica ai byte effettivamente consumati, quindi Apache può passare richieste multipart HTTP/1.1 chunked o HTTP/2 senza lunghezza, prive di una lunghezza dichiarata significativa. Una seconda via esaurisce memory_limit con una richiesta multipart che resta sotto post_max_size.

La configurazione conta comunque. CrowdStrike afferma che il percorso con codifica URL da lei dimostrato richiede approssimativamente memory_limit < 4 × post_max_size, condizione che i valori predefiniti di PHP non soddisfano. Allo stesso modo Rapid7 ha rilevato che le proof of concept pubbliche funzionano ciascuna solo contro una specifica combinazione di sistema operativo, versione di PHP e web server, e nessuna appare affidabile in modo generalizzato. Questo è un limite degli strumenti pubblici attuali. Non rende sicuro lasciare il bug dov'è.

La storia spiega il decennio di oscurità. Le ricostruzioni concordano che l'idea dell'interruzione al raggiungimento del limite di memoria fu pubblicata da Stefan Esser nel 2004. Un problema correlato di esaurimento di memoria nel parsing multipart fu segnalato nel 2020 (secondo alcune fonti nel 2019), e un audit di OSTIF/Quarkslab del 2024 segnalò un bug affine senza però dimostrarne lo sfruttamento. Ogni volta una corruzione plausibile non aveva un percorso dimostrato verso l'esecuzione di codice, e quindi restava un bug di robustezza a bassa priorità. Trasformare «potrebbe corrompere la memoria» in «fornisce in modo affidabile una shell» richiede uno sforzo prolungato e specializzato, ed è proprio quello sforzo a essere cambiato.

03Che cosa ha fatto davvero l'IA

L'attribuzione è più complicata di quanto suggeriscano i titoli. Calif afferma di aver trovato la prima falla il 1° agosto 2026 nell'ambito dell'iniziativa «Patch the Planet» di OpenAI e di averla segnalata a PHP l'11 agosto. Un'analisi secondaria afferma che Calif descrive un'analisi condotta dall'IA e guidata da un'ipotesi di un ricercatore, mentre Wiz descrive un contributo dell'IA lungo tutta la catena: scoperta, sviluppo dell'exploit, rilevamento degli attacchi e validazione delle patch. La stessa analisi riferisce che Codex Security di OpenAI ha presentato in modo indipendente un rapporto sulla causa radice l'11 agosto e ulteriori vettori di attacco il 18 settembre. I nomi dei modelli (GPT-5.6 Sol e, per Wiz, anche Gemini 4 Argon) provengono da fonti secondarie, non dall'advisory di PHP.

Non tutti ritengono che si tratti di un'IA che scopre qualcosa di nuovo. Un critico sostiene che ogni tassello di PHP2Shell fosse già presente nei dati di addestramento pubblici. Questa lettura è coerente con la cronologia sopra riportata. E rende anche il punto più netto. Il contributo del modello sembra meno l'individuazione di una nuova classe di bug e più il paziente lavoro di tracciare percorsi di esecuzione, concatenare primitive e costruire un exploit funzionante. Un resoconto descrive agenti IA che hanno rintracciato difetti nell'ordine di inizializzazione delle tabelle hash e percorsi in cui una tabella di stato non valida veniva referenziata durante il parsing dei POST. Gli audit umani si erano fermati prima.

04Divulgazione, fughe di notizie e corsa alle patch

Il processo coordinato è stato turbato. PHP aveva annunciato il 20 ottobre che la release sarebbe arrivata il 21 ottobre alle 14:00 UTC. Bitdefender riferisce che Chainguard ha pubblicato immagini container contenenti la correzione oltre sei ore prima del rilascio, violando l'embargo. Aggiunge che PHP afferma che nessun dettaglio tecnico è trapelato, ma che un video di un exploit ha accelerato lo sviluppo delle proof of concept. I ricercatori di Sansec si aspettavano attacchi di massa entro 15 minuti dal rilascio, secondo Ars Technica. Funzionari di Amazon hanno dichiarato che gli attaccanti hanno iniziato a tentare di sfruttare la falla «su larga scala», secondo l'articolo di Tech Xplore. Il 26 ottobre CISA ha aggiunto entrambe le CVE al catalogo Known Exploited Vulnerabilities.

La mappa delle patch è disomogenea. AWS elenca come intervalli interessati 8.5.0–8.5.11, 8.4.0–8.4.26, 8.3.0–8.3.35 e 8.2.0–8.2.34, senza alcuna correzione upstream per PHP 5.4–8.1. Tenable aggiunge che il team di PHP ha fornito backport minimi del codice sorgente per le versioni dalla 7.4 alla 8.1, mentre dalla 5.4 alla 7.3 il progetto non offre nulla. Le impostazioni provvisorie aiutano solo in parte. Per CVE-2026-109618 l'advisory suggerisce memory_limit=-1 impostato in modo non sovrascrivibile, un post_max_size basso e limiti alla dimensione delle richieste sul proxy. Calif avverte che rimuovere il tetto di memoria aumenta il rischio che il server esaurisca la memoria. La posizione di PHP è che nessuna modifica di configurazione mitiga completamente queste vulnerabilità. Chi gestisce parchi di server deve inoltre riavviare PHP-FPM o il web server affinché il runtime corretto venga effettivamente caricato.

05Che cosa significa per il codice legacy

La lezione pratica riguarda l'economia dello sfruttamento. Michael Daniel della Cyber Threat Alliance ha dichiarato all'AFP che il tempo che separa la proof of concept dai kit di exploit, un tempo di mesi, si misura ora in ore o giorni. Ha anche affermato che il tasso storico di sfruttamento, il 5–6% delle vulnerabilità, non mostra segni di crescita, quindi a cambiare è la velocità, non il volume. L'espressione dell'ex funzionario NSA Rob Joyce, citata da Daniel, è «grande incendio boschivo purificatore del software obsoleto».

Ne derivano tre conseguenze ingegneristiche:

1. «Sfruttabilità non dimostrata» è una difesa più debole. Una segnalazione chiusa nel 2024 per mancanza di una proof of concept può ora essere riaperta a basso costo. Un triage che dipende dalla scarsità dello sforzo dell'attaccante invecchierà male.
2. Il fine vita è un confine di sicurezza. Le applicazioni su PHP 8.1 o precedenti o eseguono backport di provenienza incerta o non hanno alcuna correzione. Il costo della migrazione è ormai un costo di patching.
3. L'IA difensiva scala solo se scala anche il triage. Daniel avverte che gran parte del rumore in arrivo è irreale o riguarda software mai esposto a internet, quindi i maintainer hanno bisogno di filtri migliori man mano che i report generati dall'IA si moltiplicano.

Ciò che resta da dimostrare è l'equilibrio nel lungo periodo. Daniel si aspetta che l'IA venga rivolta al software prima della sua distribuzione, il che potrebbe significare meno bug di questo tipo nel codice nuovo. Per ora, una falla di memory safety in un runtime C che era sopravvissuta per 14 anni, a un audit e a una segnalazione precedente è stata trovata, trasformata in arma e corretta in circa 11 settimane. Gli strumenti di IA che hanno colmato quel divario sono disponibili anche agli attaccanti.