Il 21 ottobre 2026, poco prima della release di sicurezza di PHP, è stato pubblicato online un exploit pubblico per la vulnerabilità soprannominata “PHP2Shell”. L’autore, identificato con lo pseudonimo J4ck3LSyN, ha rilasciato due script destinati a sfruttare le falle CVE‑2026‑109618 e CVE‑2026‑109619, entrambe con un punteggio CVSS 9.2.

Contesto e impatto delle vulnerabilità

PHP è il linguaggio server‑side più diffuso al mondo, impiegato in piattaforme come WordPress, Drupal e Joomla. Una vulnerabilità di esecuzione di codice remoto (RCE) su PHP può consentire a un attaccante di eseguire comandi arbitrari sul server, compromettendo l’intera infrastruttura web.

Le due CVE individuate nel 2026 hanno specifiche differenti:

    • CVE‑2026‑109618: si verifica quando una richiesta HTTP viene interrotta a metà e il server mantiene in memoria dati parziali, creando una condizione di use‑after‑free.
    • CVE‑2026‑109619: coinvolge uno stato globale di PHP che continua a puntare a una zona di memoria già liberata, consentendo l’esecuzione di codice non autorizzato.

Entrambe le vulnerabilità sono state corrette nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, rilasciate il 21 ottobre.

La cronologia degli eventi

Il 20 ottobre PHP ha annunciato una release di sicurezza fuori calendario per il giorno successivo, senza fornire dettagli sui bug. Hacker News ha segnalato il post di J4ck3LSyN con un PoC alle 11:25 UTC del 21 ottobre, mentre la società di sicurezza offensiva watchTowr ha confermato l’esistenza delle falle nello stesso pomeriggio.

Alle 12:51 UTC, Abdulrahman Alamri (@xabdul) ha twittato che la patch sarebbe stata disponibile alle 14:00 UTC in Arabia Saudita, suggerendo che l’autore dell’exploit avesse deciso di pubblicare il codice prima di tale orario. Tuttavia, le patch sono state effettivamente rilasciate alle 13:52 UTC, anticipando l’orario previsto.

Nonostante la rapida diffusione del PoC, le società di threat intelligence come Recorded Future e Insikt Group hanno sottolineato che gli script non funzionano: l’autore ha successivamente invalidato la teoria del “cached‑pointer” su cui si basava l’intera catena di sfruttamento.

Il PoC e le sue limitazioni

Recorded Future ha spiegato che i due script di J4ck3LSyN si basavano su un puntatore in cache, ipotizzato per provocare un use‑after‑free. Dopo ulteriori analisi, l’autore ha ammesso che la teoria era errata, rendendo i PoC non operativi.

L’ISC SANS ha aggiunto che, pur non essendo affidabili, i PoC mostrano comunque la struttura tipica di un exploit funzionante, ma non costituiscono un indicatore affidabile del livello di sicurezza di un server.

Valutazione delle fonti e del rischio

Per chi gestisce infrastrutture web, un PoC rilasciato prima della patch richiede tre domande chiave:

    • Chi ha verificato realmente l’exploit?
    • Il meccanismo corrisponde alla descrizione ufficiale delle CVE?
    • L’autore ha aggiornato il PoC dopo la correzione?

Nel caso di J4ck3LSyN le risposte sono: nessuna verifica indipendente, mancata corrispondenza con le descrizioni ufficiali e un aggiornamento parziale che ha annullato la teoria originale.

Il punteggio CVSS ha generato confusione: un post su Hacker News citava CVSS 10.0, mentre PHP ha assegnato 9.2 secondo la versione 4.0 dello standard. Per gli amministratori, la differenza è marginale perché la mitigazione rimane la stessa.

Attacchi osservati prima della patch

Amazon, tramite SecurityWeek, ha segnalato tentativi di sfruttamento quattro giorni prima del rilascio delle patch. Cloudflare ha riportato attacchi precoci, e watchTowr ha osservato tentativi attivi contro entrambe le CVE. Tuttavia, nessuna di queste fonti ha collegato direttamente gli attacchi al codice di J4ck3LSyN.

Questo indica che il rischio era reale e preesistente al PoC pubblico: i server non aggiornati erano già bersagli di attori malevoli.

Chi ha realmente scoperto le vulnerabilità?

Secondo Imperva, le vulnerabilità sono state segnalate congiuntamente dai ricercatori di Wiz, OpenAI, Calif e Quarkslab, quest’ultimo accreditato anche per CVE‑2026‑109618. J4ck3LSyN non compare nella lista dei ricercatori riconosciuti.

Wiz ha dimostrato l’esecuzione di codice senza autenticazione contro WordPress, Drupal e Joomla, confermando l’impatto pratico delle falle.

Misure consigliate per gli amministratori

La soluzione definitiva è l’aggiornamento alle versioni 8.5.12, 8.4.27, 8.3.36 o 8.2.35 di PHP. Gli amministratori devono verificare che i fornitori di distribuzioni Linux o hosting condiviso abbiano effettivamente incluso il fix, poiché spesso le patch vengono retro‑portate senza modificare il numero di versione.

Se l’aggiornamento non è immediatamente possibile, si consiglia di applicare mitigazioni temporanee:

    • Disattivare session.upload_progress.enabled, impostazione attiva di default che può essere sfruttata in combinazione con le vulnerabilità.
    • Impostare opcache.enable = 0, come suggerito da Imperva, sebbene nessuna di queste configurazioni chiuda completamente le falle.
    • Implementare regole di blocco a livello web server (Nginx, Apache, ModSecurity, Caddy, lighttpd, FrankenPHP, Cloudflare). Le regole sono disponibili nel repository php2shell-hardening e includono controlli sui POST multipart prima che raggiungano il motore PHP.

Conclusioni

PHP2Shell rappresenta un caso emblematico di vulnerabilità critica resa pubblica prima della patch ufficiale, ma con un exploit non funzionante. Il vero pericolo risiede nelle due CVE, già sfruttate da attori maligni prima dell’annuncio della correzione. L’unica risposta efficace è mantenere PHP aggiornato e, in caso di restrizioni, adottare le mitigazioni temporanee proposte.

La comunità di sicurezza deve continuare a monitorare le fonti indipendenti, evitare di attribuire la rottura dell’embargo a un singolo individuo e promuovere una divulgazione responsabile per limitare l’esposizione dei sistemi vulnerabili.