Le due vulnerabilità critiche di PHP battezzate PHP2Shell, CVE-2026-109618 e CVE-2026-109619, sono state sfruttate diffusamente in attacchi reali. Il 26 ottobre la CISA, l’agenzia statunitense per la sicurezza informatica, le ha aggiunte al catalogo delle vulnerabilità note e attivamente sfruttate (KEV, Known Exploited Vulnerabilities).

La prima conferma di uno sfruttamento riuscito è arrivata nel fine settimana da Adel Karimi, detection and response lead di Perplexity. I suoi honeypot – sistemi esca messi online per attirare gli aggressori e studiarne le mosse – hanno registrato un’esecuzione di codice da remoto (RCE, remote code execution) contro un’installazione Apache con mod_php, il modulo che integra PHP nel server web, con PHP 8.4.26. La risposta del sistema conteneva un dump di cookie da 800 KB, e un indirizzo di funzione ricavato da quel dump compare nel payload eseguito subito dopo.

Marcus Hutchins, ricercatore di Expel, ha confermato i risultati di Karimi e li ha giudicati uno degli esempi di sfruttamento più efficaci tra quelli visti fino a quel momento. Lo stesso Karimi invita però alla cautela: la catena è stata dimostrata su una configurazione specifica e non è necessariamente applicabile ad altre situazioni differenti per versione di PHP, configurazione del server o applicazioni eseguite.

Fino a questa evidenza il quadro era diverso. Amazon Threat Intelligence aveva visto tentativi di attacco quattro giorni prima delle patch, ma Dataminr riferiva ancora giovedì di sole scansioni, tentativi di fingerprinting ed exploit non funzionanti. La CISA non ha ancora diffuso dettagli sugli attacchi in corso e ha imposto alle agenzie federali statunitensi di mettere in sicurezza i sistemi entro giovedì 29 ottobre.

Come funzionano le due falle

Secondo la PHP Foundation, entrambe le vulnerabilità riguardano la gestione della memoria e degli errori, parti del motore che quasi ogni richiesta attraversa. La CVE-2026-109618 nasce da una corruzione di memoria: se una richiesta raggiunge il limite di memoria (memory_limit) in un momento sfortunato, PHP può lasciare dati interni inizializzati solo in parte e poi trattarli come validi. Su Apache con mod_php una richiesta non autenticata può innescare il problema prima che giri qualsiasi codice applicativo, e l’esecuzione di codice è stata dimostrata con le impostazioni predefinite. L’RCE è stata confermata anche su PHP-FPM, la modalità basata su processi separati, attraverso percorsi del codice applicativo.

La CVE-2026-109619 dipende invece da uno stato globale residuo: un errore fatale in un punto critico può lasciare riferimenti a memoria appartenuta a una richiesta precedente. Una richiesta successiva, gestita dallo stesso worker, può usare quella memoria già liberata (use-after-free). Il punteggio di gravità è 9,2 su 10 nella scala CVSS 4.0.

Le patch e la terza vulnerabilità

Ricordiamo che le versioni patchate di PHP sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Il ramo 8.1 e i precedenti non ricevono più correzioni di sicurezza: chi li usa deve migrare a una versione successiva o verificare se il fornitore della distribuzione Linux offre un backport, cioè la correzione portata su una versione più vecchia.

Venerdì 23 ottobre il team di PHP ha reso nota la CVE-2026-115560, una terza RCE al momento senza patch. Secondo l’avviso, è sfruttabile solo con una combinazione insolita di configurazione e codice applicativo che il team giudica improbabile nella pratica. La patch sarà quindi gestita nel ciclo di rilascio ordinario, pubblicando l’avviso completo con la prossima versione. La mitigazione indicata è impostare session.upload_progress.enabled=0; chi l’ha già applicata per PHP2Shell non deve fare altro.

Questa impostazione resta comunque un rimedio provvisorio anche per PHP2Shell: VirusTotal avverte che, secondo l’analisi della comunità, potrebbe non coprire ogni vettore. La funzione è presente da PHP 5.4.0 ed è attiva per impostazione predefinita.

Una divulgazione andata storta

La vicenda ha messo sotto pressione anche il processo di divulgazione coordinata. Secondo la PHP Foundation, il 20 ottobre, due giorni prima della data prevista, circolavano online i numeri delle CVE, con una data di rilascio sbagliata. Il progetto ha quindi anticipato il rilascio al 21 ottobre. Una società di sicurezza che aveva segnalato le falle ha poi pubblicato per errore un video con un proof of concept, e la Foundation sostiene che Chainguard abbia rotto l’embargo pubblicando immagini già corrette oltre sei ore prima del rilascio. La stessa Foundation ammette un ritardo strutturale: il problema di memoria era emerso già nel 2024, durante un audit esterno, ma la correzione si è bloccata per mesi tra compromessi di compatibilità e scarsità di risorse.

Un aspetto ormai evidente è che la divulgazione di vulnerabilità deve diventare una disciplina professionale, con figure addestrate e procedure che determinino chi riceve le informazioni e quando. La disponibilità di strumenti di intelligenza artificiale in grado di sviluppare exploit funzionanti a partire dalla notizia della vulnerabilità o dall’analisi della patch rendono necessario un processo robusto, una distribuzione rapida e un’altrettanto veloce applicazione delle patch.

Che cosa devono fare i team IT

La priorità è aggiornare PHP al ramo corretto, verificando anche i sistemi che non dichiarano la versione e le istanze dentro container o servizi gestiti. Dove l’aggiornamento richiede tempo, si può disattivare session.upload_progress.enabled e riavviare il servizio PHP, tenendo presente che la misura può non bastare. Le regole dei web application firewall (WAF), come quelle rilasciate da Cloudflare il 21 ottobre per i payload noti, aiutano ma non sostituiscono la patch, e servono a poco se i server di origine sono raggiungibili direttamente da Internet.