PHP2Shell, la falla era nota dal 2024: la PHP Foundation ammette due anni di ritardi nella sicurezza

📌 In sintesi

• La PHP Foundation conosceva i primi segnali del problema dal 2024, quando un audit di Quarkslab aveva fatto emergere anomalie nella gestione della memoria. All’epoca non era stato dimostrato un exploit.
• La correzione è rimasta bloccata per difficoltà tecniche e decisionali. La Foundation riconosce un fallimento strutturale dovuto ai processi interni e alla carenza di sviluppatori specializzati.
• Le vulnerabilità PHP2Shell sono state corrette soltanto il 21 ottobre 2026, dopo le segnalazioni di Calif, OpenAI e Wiz. Gli amministratori devono installare le versioni PHP aggiornate.

La PHP Foundation ammette che i primi segnali della vulnerabilità alla base di PHP2Shell erano conosciuti già nel 2024, quasi due anni prima della pubblicazione delle patch di emergenza del 21 ottobre 2026. Il problema era emerso durante un audit indipendente del codice PHP, ma l’assenza di un percorso di sfruttamento dimostrato e le difficoltà nel correggere la gestione della memoria avevano rallentato gli interventi. La ricostruzione trova conferma nel resoconto ufficiale della PHP Foundation. L’organizzazione riconosce esplicitamente un fallimento strutturale nella gestione della vulnerabilità, riaprendo il dibattito sulla sicurezza dei progetti open source da cui dipendono milioni di servizi digitali.

PHP2Shell, i primi segnali individuati durante l’audit del 2024

Nel 2024, la PHP Foundation finanzia attraverso la Sovereign Tech Agency un controllo indipendente del codice PHP, organizzato da OSTIF ed eseguito da Quarkslab. Durante la correzione di un problema individuato dall’audit, uno sviluppatore del progetto scopre anomalie nella gestione degli errori di memoria, riconducibili alla causa della futura CVE-2026-109618. Il team ipotizza un possibile sfruttamento, ma non individua un percorso concreto capace di dimostrare l’esecuzione remota di codice. Le difficoltà riguardano anche le possibili correzioni: alcune rischiano di compromettere la compatibilità con le estensioni, altre possono introdurre nuove condizioni di denial of service. Il processo decisionale basato sul consenso impedisce di scegliere rapidamente una soluzione, mentre gli sviluppatori con conoscenze approfondite del motore PHP sono pochi e impegnati su numerose attività. La Foundation riconosce che il lavoro viene ripetutamente sospeso e ripreso. Non sostiene che nel 2024 fosse già disponibile un exploit funzionante, ma ammette che il problema tecnico era stato individuato e che il sistema organizzativo non era riuscito a risolverlo.

Leggi anche: PHP2Shell, 22,6 milioni di istanze esposte: CERT-AGID pubblica i test

Calif, OpenAI e Wiz dimostrano il rischio reale nell’agosto 2026

La situazione cambia nell’estate del 2026. Il ricercatore Ryan A. di Calif segnala l’11 agosto una tecnica di esecuzione remota di codice collegata alla stessa causa individuata due anni prima. OpenAI identifica indipendentemente il problema e presenta ulteriori vettori di attacco, mentre Wiz comunica nuove modalità di sfruttamento il 24 agosto. Le ricerche dimostrano che le anomalie nella gestione della memoria possono compromettere server PHP accessibili da Internet. Da quel momento la correzione diventa una priorità assoluta. Il 21 ottobre arrivano le patch per CVE-2026-109618 e CVE-2026-109619, entrambe classificate con punteggio CVSS 9,2. Le versioni corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12, come documentato nell’approfondimento sulle patch PHP2Shell contro le due vulnerabilità RCE.

Continua con:

PHP2Shell attaccato prima delle patch, GitLab corregge una RCE CVSS 10

PHP2Shell, allarme CSIRT Italia: l’81,9% dei servizi PHP risulta vulnerabile

La PHP Foundation riconosce il fallimento organizzativo

L’aspetto più importante del caso riguarda le responsabilità nella manutenzione del software. La PHP Foundation attribuisce il ritardo alla combinazione tra processi decisionali inadeguati e risorse insufficienti, spiegando che il numero degli sviluppatori capaci di intervenire sulle parti più delicate del motore PHP è limitato. L’organizzazione ha già iniziato a modificare le proprie procedure, introducendo decisioni a maggioranza e rafforzando il team dedicato alla sicurezza. Il problema supera la singola vulnerabilità. Gli strumenti di analisi, compresi quelli basati sull’intelligenza artificiale, individuano difetti sempre più rapidamente, ma la loro correzione richiede sviluppatori esperti, finanziamenti e processi decisionali efficaci. La distanza tra capacità di scoperta e capacità di manutenzione diventa così una questione di sicurezza infrastrutturale. Intanto le vulnerabilità sono entrate nel catalogo KEV della CISA e sono stati documentati attacchi riusciti contro server di prova vulnerabili. La correzione del runtime PHP resta indispensabile, mentre le protezioni WAF rappresentano soltanto una difesa aggiuntiva. Il caso PHP2Shell dimostra che conoscere un difetto non basta: senza risorse e responsabilità decisionali chiare, una vulnerabilità apparentemente irrisolta può trasformarsi in un’emergenza globale.