PHP2Shell: quando l'engine diventa il bersaglio, ogni difesa a valle si spegne

PHP ha rilasciato patch critiche il 20 ottobre 2026 per due vulnerabilità nel core del linguaggio, CVE-2026-109618 e CVE-2026-109619, che permettono esecuzione remota di codice con punteggio CVSS v4.0 9.2. L'aspetto che altera il quadro di rischio non è la sola criticità del CVSS, ma la posizione dell'exploit nel lifecycle della richiesta: su Apache mod_php l'esecuzione avviene prima che qualsiasi codice applicativo venga caricato, rendendo inutili WAF e secure coding practices tradizionali.

Il meccanismo: corrompere lo stato prima che esista il codice

CVE-2026-109618 sfrutta un errore di gestione memoria nel core PHP. Quando un out-of-memory interrompe un'operazione vulnerabile, il motore lascia i dati della richiesta parzialmente inizializzati. Le routine di cleanup elaborano quello stato invalido, aprendo un percorso verso l'esecuzione remota di codice. La sequenza non richiede che l'applicazione esegua logiche complesse: l'exploit agisce sul motore stesso, non sul codice che gira sopra.

CVE-2026-109619 è un use-after-free cross-request. PHP mantiene riferimenti a dati di richiesta dopo che la memoria di backing è stata liberata. Una richiesta successiva gestita dallo stesso worker accede a quei riferimenti obsoleti prima che l'inizializzazione li resetti. I ricercatori hanno dimostrato esecuzione remota di codice attraverso questa sequenza, secondo quanto riportato dalla fonte.

Entrambe le vulnerabilità risiedono nel lifecycle management delle richieste PHP, un layer che le applicazioni non controllano e non possono validare. Questa è la radice del problema: il confine di sicurezza si sposta dal perimetro applicativo al runtime stesso.

mod_php: l'architettura legacy come superficie di attacco privilegiata

Il dato che Qualys segnala con nettezza è la posizione temporale dell'exploit su mod_php. Il provvedimento citato riporta testualmente che "PHP reports a demonstrated exploit that can trigger before application code runs". Questa collocazione pre-application-code significa che nessuna validazione input, nessuna logica di autorizzazione, nessuna configurazione WAF è ancora attiva quando il payload viene eseguito.

mod_php resta l'architettura di deployment dominante per PHP su Apache, nonostante PHP-FPM sia considerato la modalità moderna. La persistenza di mod_php in hosting condiviso, pannelli di controllo legacy e installazioni enterprise crea una superficie massiccia che l'attaccante non deve neanche individuare con fingerprinting elaborato: è il default storico.

La fonte specifica che PHP-FPM richiede anch'esso patching. Il suo comportamento di startup blocca un percorso specifico di attacco out-of-memory, ma PHP ha validato esecuzione remota di codice nel lifecycle della sessione contro FPM in condizioni applicative idonee. FrankenPHP e LiteSpeed completano il quadro dei cinque SAPI interessati, estendendo la vulnerabilità a deployment containerizzati e ad alta performance.

Exploitation in-the-wild: tre conferme convergenti

La fonte cita tre indicatori indipendenti di exploitation attiva. Cloudflare ha riportato traffico di attacco targeting queste vulnerabilità, inclusi tentativi di evasione delle proprie protezioni. Amazon Threat Intelligence ha segnalato attività di attacco. Patchstack ha ricevuto segnalazioni di exploitation da hosting partners. Non emergono nel dossier cifre di sistemi compromessi o entità target specifiche, e la fonte non distingue tra attacchi mirati e scanning massivo.

"Cloudflare has reported attack traffic targeting these vulnerabilities, including attempts to evade its protections" — Qualys Threat Research Unit

La convergenza di tre osservatori su traffic analysis, threat intelligence e segnalazioni da infrastruttura ospitata rende l'exploitation in-the-wild un dato documentato, non una proiezione. Il dato tattico rilevante è che gli attaccanti stanno già investendo in evasion techniques contro protezioni edge, il che indica interesse operativo concreto oltre alla mera disponibilità di proof-of-concept.

Memory disclosure e l'impatto oltre l'esecuzione

Oltre alla RCE, i ricercatori hanno dimostrato disclosure unauthenticated della memoria del worker PHP. La memoria esposta può contenere password, token di autenticazione e API keys, secondo quanto riportato dalla fonte. Questo vettore non richiede che l'exploit raggiunga l'esecuzione di codice: l'accesso a strutture dati residui in memoria è sufficiente a compromettere segreti di sessioni precedenti o di altri tenant in ambienti multi-user.

La combinazione di RCE unauthenticated e memory disclosure amplifica il rischio per hosting provider, piattaforme e-commerce e infrastrutture cloud-native dove worker PHP servono richieste multiple e potenzialmente multi-tenant. Non è necessario che l'attaccante ottenga persistenza: l'estrazione di credenziali o token può essere obiettivo sufficiente, con riuso su altri servizi.

Cosa fare adesso

Gli operatori devono applicare le patch PHP rilasciate il 20 ottobre 2026 per tutte le versioni supportate. Per le installazioni su rami EOL 7.4, 8.0 e 8.1, PHP ha reso disponibili backport limitati che vanno valutati caso per caso in base alla criticità del sistema.

La disabilitazione della feature session upload-progress con restart del servizio è la mitigazione documentata dalla fonte. Gli amministratori di mod_php devono considerare la migrazione a PHP-FPM come cambio architetturale, pur mantenendo l'attenzione sul patching dato che FPM resta vulnerabile a condizioni applicative specifiche.

Qualys ha rilasciato undici QID di detection per PHP2Shell, inclusi 389102 e 39033 per identificazione unauthenticated. I team di sicurezza devono utilizzare queste signature per mappare l'esposizione reale dell'inventario, con priorità sui sistemi mod_php non documentati e sui deployment multi-tenant dove il rischio di cross-contaminazione da memory disclosure è massimo.

La lezione del lifecycle: quando il runtime tradisce

La ricerca su PHP2Shell rientra in un pattern più ampio: la migrazione di vulnerabilità critiche dai layer applicativi ai runtime e ai linguaggi stessi. Quando il difetto è nel motore, ogni applicazione scritta in quel linguaggio eredita la vulnerabilità indipendentemente dalla qualità del proprio codice. mod_php, in questo senso, non è solo una scelta tecnologica obsoleta: è l'architettura che espande la superficie di un bug engine-level a una frazione massiva del web.

Il dato che resta da verificare è la diffusione effettiva delle patch nei sistemi EOL e la capacità degli operatori di identificare deployment mod_php non documentati. La fonte non fornisce metriche di adozione né timeline di exploitation successiva al rilascio delle correzioni. Il rischio rimane concentrato sulla distanza tra disponibilità del fix e applicazione pratica, una distanza che per PHP legacy si misura spesso in anni.

FAQ

La disabilitazione di upload-progress protegge completamente?
La fonte documenta questa mitigazione ma non specifica se copra entrambe le CVE o solo un percorso di attacco. Il dossier non permette di escludere che altri vettori restino aperti.

PHP-FPM è sicuro se configurato correttamente?
No. La fonte afferma esplicitamente che PHP-FPM richiede patching e che è stata validata RCE nel lifecycle della sessione in condizioni applicative idonee. Il blocco di un percorso OOM specifico non equivale a protezione completa.

Esiste conferma di compromissioni riuscite?
Il dossier riporta attack traffic, exploitation reports e attività di attacco confermate, ma non fornisce evidenza di sistemi compromessi con successo o entità target specifiche.

Fonti

• blog.qualys.com