Il progetto PHP ha distribuito il 21 ottobre 2026 quattro aggiornamenti di sicurezza per correggere due vulnerabilità critiche che consentono, in determinate condizioni, l’esecuzione remota di codice senza autenticazione sui server interessati. Le versioni correttive sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, rilasciate per risolvere CVE-2026-109618 e CVE-2026-109619, entrambe classificate con un punteggio di gravità CVSS 4.0 pari a 9,2 su 10. Le vulnerabilità interessano componenti interni dell’interprete e non dipendono necessariamente dalla presenza di errori nel codice delle applicazioni web ospitate. La loro individuazione è avvenuta attraverso attività di ricerca che hanno coinvolto Calif, OpenAI e Wiz, con l’impiego di modelli di intelligenza artificiale avanzati per l’analisi dei meccanismi di esecuzione del linguaggio. La portata dell’intervento è particolarmente rilevante perché PHP viene utilizzato, secondo le stime richiamate da Wiz, da circa il 70% dei siti web e costituisce una componente fondamentale di numerosi sistemi di gestione dei contenuti, servizi applicativi e piattaforme commerciali.
La vulnerabilità CVE-2026-109618 riguarda problemi di corruzione della memoria associati alla gestione di condizioni di esaurimento delle risorse, mentre CVE-2026-109619 coinvolge la persistenza e l’utilizzo non corretto di stati globali interni dell’interprete. Le analisi tecniche hanno individuato condizioni di use-after-free nei meccanismi di deserializzazione collegati all’avanzamento degli upload e nella gestione dei backtrace prodotti dagli errori fatali, oltre a problemi di type confusion nel componente OPcache. Queste anomalie appartengono alla categoria dei difetti di sicurezza della memoria e possono verificarsi quando PHP gestisce richieste che determinano errori fatali, compresi quelli relativi all’esaurimento della memoria disponibile. Un attaccante può sfruttare specifiche sequenze di richieste per provocare comportamenti inattesi nell’interprete, fino a ottenere l’esecuzione di codice nel contesto del processo PHP. Sono state inoltre dimostrate possibilità di lettura non autorizzata della memoria dei processi, con il rischio di esporre password, token di autenticazione, chiavi API, certificati e altre informazioni temporaneamente presenti nell’ambiente di esecuzione.
Le condizioni di esposizione comprendono le principali configurazioni utilizzate per pubblicare applicazioni PHP, fra cui PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. La gravità è particolarmente elevata nelle installazioni mod_php, per le quali è stata dimostrata una possibilità di sfruttamento attraverso richieste non autenticate prima ancora che venga eseguito il codice dell’applicazione. Le ricostruzioni condotte dai ricercatori indicano che almeno una delle vulnerabilità interessa tutte le versioni PHP distribuite nell’ultimo decennio e che determinati percorsi vulnerabili risalgono addirittura a PHP 5.4.0. La possibilità di attacco varia in funzione della versione dell’interprete e della Server Application Programming Interface utilizzata, ma i ricercatori hanno documentato percorsi sfruttabili anche con configurazioni predefinite. Wiz ha riunito le tecniche di sfruttamento in una dimostrazione denominata php2shell, verificando la possibilità di eseguire codice remoto senza autenticazione su immagini container aggiornate di WordPress, Drupal e Joomla.
Le verifiche di Calif hanno inoltre documentato l’esecuzione remota di codice prima dell’autenticazione su ambienti comprendenti WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 e WHMCS. In determinate condizioni, il comportamento vulnerabile è stato riprodotto anche su script PHP arbitrari. L’ampiezza dei sistemi coinvolti deriva dal fatto che il difetto risiede nell’interprete e nei relativi meccanismi di gestione della memoria, non in una specifica applicazione. L’aggiornamento del solo CMS, del framework oppure dei componenti applicativi non è quindi sufficiente se l’installazione PHP sottostante continua a utilizzare una versione vulnerabile. Il progetto PHP ha precisato che non esistono mitigazioni alternative complete e che l’installazione delle versioni corrette rappresenta l’unica soluzione sicura. Sono state indicate alcune configurazioni temporanee capaci di ridurre l’esposizione a singoli percorsi di attacco, ma senza eliminare il problema complessivo. I fornitori delle distribuzioni Linux e dei servizi di supporto a lungo termine hanno ricevuto anticipatamente le correzioni; sono stati inoltre predisposti backport minimi per PHP 7.4, 8.0 e 8.1, versioni che non ricevono più aggiornamenti ordinari. PHP 8.2 raggiungerà invece la fine del supporto il 31 dicembre 2026.
La scoperta delle vulnerabilità è il risultato di più attività di ricerca parzialmente indipendenti. Calif ha avviato una verifica di sicurezza il 30 luglio 2026, utilizzando GPT-5.6 Sol nel quadro dell’iniziativa Patch the Planet di OpenAI. La ricostruzione degli eventi colloca i primi risultati all’inizio di agosto, con una segnalazione di esecuzione remota di codice non condizionata trasmessa ai responsabili di PHP l’11 agosto e una successiva dimostrazione condivisa il 14 agosto. OpenAI ha individuato indipendentemente la stessa causa originaria, mentre Wiz ha condotto ulteriori analisi utilizzando Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol. Fra il 19 e il 24 agosto Wiz ha identificato le vulnerabilità, confermato lo sfruttamento su Drupal e WordPress e trasmesso le informazioni al gruppo di sicurezza PHP. Nei mesi successivi, i ricercatori hanno coordinato le verifiche e l’elaborazione delle correzioni, mentre OpenAI ha identificato ulteriori vettori di attacco nel settembre 2026. La gestione coordinata è stata particolarmente complessa anche per la storia del problema: vulnerabilità connesse ai limiti di memoria di PHP erano già state individuate nel 2004, mentre segnalazioni successive erano emerse nel 2020 e durante un audit finanziato dalla Sovereign Tech Agency e condotto da OSTIF e Quarkslab nel 2024. In quest’ultimo caso il problema era stato riconosciuto senza arrivare alla dimostrazione dello sfruttamento, e le attività di correzione avevano subito interruzioni e rinvii.
La divulgazione coordinata è stata accelerata dalla circolazione anticipata degli identificativi CVE su forum e social network il 20 ottobre 2026, accompagnata da indicazioni inesatte sull’orario di pubblicazione degli aggiornamenti e da un punteggio di gravità erroneamente indicato come 10,0. Pur non essendo trapelati i dettagli tecnici dello sfruttamento, il gruppo di sicurezza PHP ha anticipato la comunicazione e spostato il rilascio delle correzioni dal 22 al 21 ottobre, alle 14:00 UTC. La disponibilità pubblica delle informazioni ha determinato una rapida crescita dell’attività di attacco: secondo quanto comunicato dal CEO di Cloudflare Matthew Prince, i tentativi rilevati erano già nell’ordine delle migliaia prima della divulgazione e sono aumentati a decine di migliaia nei primi 45 minuti, a centinaia di migliaia entro due ore e successivamente a milioni. Le autorità di sicurezza informatica hanno sollecitato l’applicazione immediata delle correzioni, indicando la temporanea disattivazione dei servizi vulnerabili come misura da considerare quando non sia possibile proteggerli tempestivamente. Un problema operativo specifico riguarda l’individuazione di tutte le installazioni PHP presenti nelle infrastrutture, comprese quelle incorporate in servizi di hosting, applicazioni di terze parti e sistemi non immediatamente censiti.
OpenAI ha accompagnato la divulgazione con un programma di sostegno alle attività difensive, annunciando un miliardo di dollari in accesso sovvenzionato a Daybreak per gli operatori impegnati nella sicurezza e pubblicando un controllo delle versioni PHP sotto forma di skill per Codex nel repository openai/php2shell-checker. L’iniziativa si basa sulla possibilità che modelli AI avanzati identifichino vulnerabilità critiche prima della loro scoperta da parte di attaccanti, consentendo ai manutentori del software di intervenire durante un intervallo di vantaggio difensivo. Nel caso di PHP, l’intervento coordinato ha prodotto correzioni per due difetti presenti da molti anni nell’interprete, ma la loro effettiva eliminazione dalle infrastrutture dipende dalla distribuzione degli aggiornamenti e dalla capacità degli operatori di identificare ogni istanza vulnerabile, comprese quelle meno visibili all’interno di ambienti applicativi complessi.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)