Due vulnerabilità raggruppate sotto gli identificativi CVE-2026-109618 e CVE-2026-109619 interessano il core di PHP e possono consentire a un attaccante di eseguire codice sui server senza autenticarsi o di leggere informazioni sensibili dalla memoria dei processi. Wiz Research ha comunicato la scoperta il 21 ottobre 2026, data in cui PHP ha pubblicato correzioni per diversi problemi di sicurezza relativi alla gestione della memoria nel motore del linguaggio.
La gravità indicata da Wiz raggiunge un punteggio CVSS di 9,2. Il rischio non è limitato a una specifica applicazione: secondo la ricerca, le vulnerabilità risiedono in PHP e possono interessare persino programmi semplici scritti in questo linguaggio. Wiz afferma che le vulnerabilità interessano versioni di PHP risalenti alla 5.4 e che ogni versione pubblicata nell’ultimo decennio presenta almeno uno dei problemi descritti.
Cosa può fare un attaccante
Wiz ha raggruppato quattro casi di vulnerabilità nella sicurezza della memoria sotto due CVE. Tra gli impatti dimostrati figurano la divulgazione della memoria dei processi, la corruzione della memoria e l’esecuzione di codice da remoto (RCE). La lettura della memoria può esporre password, token di autenticazione, chiavi API e certificati presenti nel processo, anche se l’attaccante non riesce a eseguire codice.
Per mostrare la portata del problema, il team ha sviluppato un exploit chiamato php2shell e ha dimostrato l’esecuzione remota senza autenticazione in WordPress, Drupal e Joomla, utilizzando le immagini dei container più recenti di queste piattaforme disponibili durante i test. Wiz sottolinea che questi sistemi sono stati usati come obiettivi dimostrativi: la vulnerabilità si trova nel motore PHP stesso e non richiede un difetto nel codice di WordPress, Drupal o Joomla.
PHP è utilizzato in una parte considerevole del web e costituisce la base di sistemi di gestione dei contenuti e altri servizi. Wiz Research stima che il linguaggio alimenti il 70% dei siti web del mondo. El Español ha pubblicato una stima diversa, pari al 75%. Le cifre non coincidono; entrambe le pubblicazioni descrivono comunque una tecnologia ampiamente diffusa, il cui livello di esecuzione condiviso può trasformare un difetto del motore in un problema per molte organizzazioni.
Perché gli errori di memoria sono importanti
I problemi descritti sono legati alla gestione degli errori fatali durante le richieste, in particolare degli errori di memoria insufficiente. Secondo Wiz, una richiesta interrotta può lasciare riferimenti interni obsoleti o uno stato della memoria incoerente. Se un processo riutilizza questo stato per gestire un’altra richiesta, il risultato può essere una lettura o una corruzione della memoria.
Uno dei pattern tecnici individuati è l’use-after-free: il programma conserva o utilizza un riferimento a un blocco di memoria dopo che questo è stato liberato. Un altro caso comporta una confusione di tipi in OPcache, che mantiene strutture compilate nella memoria condivisa. Si tratta di classi di errori difficili da sfruttare perché il risultato dipende da come la memoria è organizzata e riutilizzata, nonché dalle versioni, dalla configurazione e dal comportamento dell’applicazione.
Questo spiega anche perché aggiornare l’applicazione non sia necessariamente sufficiente. Se il problema si trova nell’interprete, qualsiasi servizio che esegua una versione vulnerabile di PHP può essere esposto, anche se il suo codice non presenta un errore equivalente. Per i team tecnici, l’inventario dei rischi deve includere le versioni dell’ambiente di esecuzione e i servizi che le utilizzano, non solo i repository di ciascuna applicazione.
Il ruolo dell’intelligenza artificiale
Wiz sostiene che i problemi fossero presenti nel codice da oltre un decennio, ma trasformarli in exploit funzionanti richiedeva di concatenare diversi errori, adattarsi alla disposizione della memoria di ciascun obiettivo e ripetere cicli di test e debug. Durante la ricerca, l’azienda ha utilizzato Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol, attribuendo a Gemini 4 Argon un contributo significativo nella scoperta, nello sviluppo dell’exploit, nel rilevamento degli attacchi e nella verifica della correzione.
Per i professionisti, il punto non è che l’IA elimini la necessità di competenze tecniche, ma che possa ridurre il lavoro necessario per esaminare le varianti e adattare un exploit a diversi ambienti. Wiz afferma che i modelli di frontiera, combinati con strumenti di test e debug, hanno reso praticabile un processo che in precedenza sarebbe stato difficile da implementare e scalare. La stessa capacità può aiutare a individuare e correggere i difetti, ma abbassa anche la barriera pratica per sfruttare vulnerabilità complesse.
Il lavoro ha incluso il coordinamento con il team PHP, Calif e OpenAI per la scoperta, la divulgazione e la verifica della patch. Wiz segnala inoltre di aver collaborato con fornitori e organizzazioni come Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva e Vercel per preparare indicazioni, rilevamenti e mitigazioni per chi non fosse in grado di aggiornare immediatamente.
Cosa dovrebbero fare i team
La misura principale è aggiornare PHP a una versione corretta, come raccomanda Wiz. Le organizzazioni dovrebbero individuare i server che eseguono PHP e verificare quale versione utilizza ciascuno, compresi gli ambienti di hosting e i servizi non gestiti dallo stesso repository dell’applicazione. Se non è possibile aggiornare subito, è opportuno applicare le mitigazioni disponibili per l’ambiente e controllare avvisi e registri alla ricerca di attività anomale.
Wiz consiglia di prestare attenzione, tra gli altri segnali, a richieste multipart insolite seguite da errori di memoria o ripetute risposte HTTP 500, cookie PHPSESSID di dimensioni o formato inaspettati e riavvii o modifiche inspiegabili dei processi PHP. L’azienda avverte che questi segnali possono orientare un’indagine, ma che la correzione tramite patch è l’unica soluzione completa ai problemi descritti.
PHP ha inoltre pubblicato un avviso informativo sul progresso del caricamento delle sessioni. Il team consiglia di disabilitare temporaneamente session.upload_progress.enabled fino alla successiva versione di correzione ordinaria, per proteggersi da un vettore RCE improbabile. PHP specifica che questo caso richiede una combinazione insolita: impostare session.serialize_handler su php_binary o php_serialize e poi modificarlo in php a runtime tramite ini_set() prima di chiamare session_start(), mantenendo abilitato il progresso del caricamento. Se l’applicazione non modifica in questo modo il gestore di serializzazione, PHP indica che la funzionalità può rimanere abilitata. L’organizzazione prevede di pubblicare un avviso completo per CVE-2026-115560 con la prossima versione; si tratta di un avviso aggiuntivo con condizioni specifiche, non di una descrizione di tutte le vulnerabilità di PHP2Shell.
Un problema di sicurezza che non si risolve con la patch
Wiz indica che i quattro casi descritti non esauriscono le possibili varianti di questo pattern nel codice PHP e che la patch corregge il problema alla radice, eliminando le varianti individuate. Per gli amministratori, il passo immediato è installare l’aggiornamento applicabile e verificare che i processi eseguano effettivamente la versione corretta.
La divulgazione lancia un avvertimento a sviluppatori e responsabili della sicurezza: la complessità tecnica non garantisce più che un difetto datato sia difficile da sfruttare. La revisione del codice, i test, la gestione della memoria e una risposta coordinata restano necessari; è inoltre essenziale considerare i componenti condivisi, come il motore di un linguaggio, parte integrante della superficie di attacco.
Fonti: Wiz Research, PHP.net, El Español
