PHP2Shell CVE-2026-109618 e 109619: RCE senza credenziali nel motore PHP, in Italia 285.149 servizi su versioni potenzialmente vulnerabili

Su 741.523 servizi PHP rilevati in Italia, 285.149 usano versioni potenzialmente vulnerabili a PHP2Shell, pari all'81,9% di quelli con versione identificata: è il dato di esposizione al 25 ottobre 2026 con cui ACN ha chiesto lo stesso giorno di aggiornare subito, a partire dai sistemi esposti su internet. Il nome, dato dai ricercatori, indica due vulnerabilità del motore PHP, la CVE-2026-109618 e la CVE-2026-109619, entrambe con CVSS v4.0 pari a 9.2, che consentono a un attaccante remoto senza credenziali di eseguire codice con i privilegi del processo PHP. Il progetto PHP le ha corrette il 21 ottobre e ACN le aveva segnalate lo stesso giorno, aggiornando il proprio alert il 23 per le prove di concetto (PoC) funzionanti in circolazione. Il primo tentativo di sfruttamento noto risale al 17 ottobre, quando le falle erano ancora zero-day, e il 24 ottobre è stata documentata un'esecuzione di codice riuscita in rete, su sistemi esca, mentre non risultano compromissioni confermate di sistemi in produzione. La percentuale si calcola sui soli servizi di cui si riconosce la versione, poco meno della metà del totale, e secondo ACN può includere sistemi già corretti senza cambio del numero di versione, come accade con i pacchetti di molte distribuzioni Linux.

Fra gli scopritori delle falle c'è Wiz Research, che le ha segnalate a PHP il 24 agosto dichiarando di aver usato modelli di intelligenza artificiale sia per trovarle sia per sviluppare l'exploit. La CVE-2026-109618 nasce dalla gestione dell'esaurimento della memoria: quando una richiesta costruita ad arte, anche di tipo multipart, porta PHP oltre il limite, l'elaborazione viene interrotta di colpo mentre alcune strutture interne sono inizializzate solo in parte, e la pulizia di fine richiesta le tratta poi come valide. La CVE-2026-109619 è un use-after-free sullo stato globale: dopo un errore fatale, un timeout o un esaurimento di memoria, PHP conserva riferimenti a memoria già liberata che una richiesta successiva, servita dallo stesso processo, può riutilizzare, per esempio attraverso il monitoraggio dell'avanzamento degli upload di sessione o, su PHP 8.5, i backtrace degli errori fatali. Secondo PHP sono esposte tutte le installazioni che servono richieste web, con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed, e il rischio è più alto con mod_php, dove l'exploit dimostrato parte prima che venga eseguita una sola riga dell'applicazione. Wiz ha dimostrato l'attacco su WordPress, Drupal e Joomla, ma precisa che sono solo esempi: il difetto sta nell'interprete, e anche un'applicazione scritta senza errori resta esposta. È la differenza rispetto a wp2shell, la catena di RCE sul core di WordPress di cui avevamo scritto in un nostro precedente alert del 18 luglio sulle CVE-2026-63030 e CVE-2026-60137 di WordPress core: allora bastava aggiornare WordPress, questa volta l'aggiornamento va fatto un piano più sotto, sull'interprete.

Lo sfruttamento è cominciato prima della divulgazione. Amazon Threat Intelligence ha registrato il primo tentativo il 17 ottobre sulla propria rete di sistemi esca (honeypot) MadPot, quattro giorni prima delle patch, da un indirizzo di un servizio commerciale di anonimizzazione; il 21 ottobre, verso le 2 UTC, è comparso il primo PoC, dodici ore prima dell'uscita delle correzioni, e nelle ore successive ne sono arrivati altri con payload e infrastrutture diverse, segno secondo Amazon di più attori. Anche altre società che monitorano il traffico d'attacco avevano rilevato tentativi già prima della divulgazione, classificandoli tutti come non riusciti, finché il 24 ottobre il ricercatore Adel Karimi ha documentato su tre honeypot con PHP 8.4.26 e Apache mod_php 35 shell aperte da due indirizzi IP di provider di hosting. La catena è coerente con la CVE-2026-109618: prima la fase di esaurimento della memoria, poi una richiesta con un cookie di sessione sovradimensionato che fa trapelare indirizzi di memoria e permette di aggirare l'ASLR, la protezione che rende casuale la disposizione della memoria dei processi. Dopo l'esecuzione l'attaccante ha verificato utente, nome host e architettura e ha provato a scrivere file di prova e a contattare server esterni, senza un secondo stadio osservato. BleepingComputer, che ha ripreso il report il 26 ottobre, ne parla come di sfruttamento ormai riuscito in rete, ma il dato va pesato: gli honeypot avevano un solo processo worker, una configurazione che il report stesso definisce favorevole all'attaccante, e l'affidabilità della catena su altre configurazioni non è stata misurata. Non risultano finora attribuzioni a gruppi noti.

A doversene preoccupare è chiunque gestisca server web con PHP raggiungibili da internet, a cominciare dalle installazioni Apache con mod_php. Secondo BleepingComputer PHP è usato da circa il 70% dei siti web, e in Italia è la base di molti siti istituzionali, scolastici e comunali, costruiti su WordPress, Joomla, Drupal o su applicazioni scritte su misura. Chi è in hosting condiviso o gestito deve chiedere al fornitore se l'aggiornamento è stato fatto. Il punto più delicato sono i rami vecchi: secondo Wiz ogni versione di PHP uscita nell'ultimo decennio contiene almeno una delle due falle, e il codice vulnerabile risale fino a PHP 5.4, ma il progetto non rilascia più versioni per la 8.1 e precedenti. Per la 7.4, la 8.0 e la 8.1 il team di sicurezza di PHP ha pubblicato correzioni minime solo in forma di sorgente, per chi compila da sé; per il resto restano i pacchetti delle distribuzioni e dei fornitori di supporto esteso, che hanno ricevuto le patch in anticipo, oppure la migrazione a un ramo supportato, tenendo conto che la 8.2 esce a sua volta dal supporto il 31 dicembre. I siti PHP italiani rimasti indietro con gli aggiornamenti sono già stati bersaglio di campagne di sfruttamento, come quella dei defacement con webshell su siti non aggiornati da oltre tre mesi, descritta in un nostro precedente alert del 17 settembre sulla campagna di defacement in Italia tramite la CVE-2026-48907 di Joomla JCE. Resta poi aperta una terza vulnerabilità, la CVE-2026-115560, resa nota da PHP il 23 ottobre: un vettore di esecuzione di codice che il progetto giudica improbabile, perché richiede che l'applicazione cambi durante l'esecuzione il formato di serializzazione delle sessioni con il monitoraggio degli upload attivo. Le versioni del 21 ottobre non la correggono e la patch arriverà con il prossimo rilascio ordinario, di cui PHP non indica la data; nel frattempo PHP e ACN indicano di disattivare il monitoraggio dell'avanzamento degli upload di sessione, una misura da applicare anche sui sistemi già aggiornati.

• Versioni affette: per le CVE-2026-109618 e CVE-2026-109619, PHP 8.5 precedenti alla 8.5.12, 8.4 precedenti alla 8.4.27, 8.3 precedenti alla 8.3.36 e 8.2 precedenti alla 8.2.35, più tutti i rami 8.1 e precedenti, fuori supporto, risalendo fino alla 5.4 secondo Wiz, con qualsiasi modalità di esecuzione che serva richieste web (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed); sono interessati anche i prodotti che incorporano una versione di PHP affetta, fino alla patch del rispettivo fornitore. La CVE-2026-115560 riguarda anche le versioni corrette del 21 ottobre: l'esposizione dipende dalla configurazione e dal codice dell'applicazione, e la versione installata da sola non basta a stabilirla.
• Azione raccomandata: aggiornare subito a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure installare i pacchetti corretti della propria distribuzione, verificando che la correzione sia effettivamente applicata e riavviando PHP-FPM o Apache perché i processi in esecuzione carichino il codice nuovo; per la 8.1 e precedenti usare i backport della distribuzione o del fornitore di supporto esteso, oppure migrare a un ramo supportato, e se nessuna delle due strade è percorribile in tempi brevi valutare, come indica ACN, di mettere offline i servizi; impostare session.upload_progress.enabled a 0 nella configurazione principale di PHP o del pool FPM, perché le impostazioni applicate dal codice dell'applicazione o per singola cartella non bastano, e riavviare i worker, anche sui sistemi già aggiornati, dato che è l'unica misura disponibile per la CVE-2026-115560 (sulla CVE-2026-109619 chiude invece solo i percorsi confermati legati alle sessioni); dove la patch non è immediata, applicare anche le altre mitigazioni di PHP (fatal_error_backtraces a 0 su PHP 8.5, memory_limit a -1 con un post_max_size ridotto e un limite di memoria a livello di container), sapendo che chiudono solo alcuni percorsi d'attacco e non sostituiscono l'aggiornamento; dove esistono regole specifiche, configurare i WAF in modalità blocco, verificandone l'efficacia; chiedere al provider di hosting e ai fornitori dei prodotti con PHP incorporato lo stato delle patch; rivedere log ed eventi di sicurezza almeno dal 17 ottobre, data del primo tentativo noto, cercando richieste HTTP anomale, errori ricorrenti di esaurimento della memoria, interruzioni inattese dei processi PHP e, a valle, processi non previsti, file applicativi modificati e connessioni in uscita insolite.

Fonti: ACN, PHP, Wiz, Amazon, BleepingComputer, Adel Karimi