Le vulnerabilità PHP2Shell mettono a rischio quasi tutti i web server PHP
Le vulnerabilità PHP2Shell consentono a un aggressore privo di account di eseguire codice tramite il PHP runtime, il motore software che elabora le pagine PHP su un web server. PHP ha rilasciato correzioni nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. L'avviso di sicurezza di PHP afferma che l'installazione di un runtime aggiornato è l'unica protezione completa.
Le due vulnerabilità sono CVE-2026-109618 e CVE-2026-109619. Ciascuna ha ricevuto un punteggio di 9,2 secondo CVSS v4.0, una scala standard per valutare la gravità delle vulnerabilità. I ricercatori di Wiz, Calif e OpenAI hanno segnalato i problemi, che interessano quasi tutte le versioni di PHP a partire da PHP 5.4. Poiché i difetti si trovano all'interno di PHP e non nel codice applicativo di un sito web, può risultare esposta persino una pagina di base priva di una logica applicativa complessa.
Secondo l'avviso, le modalità interessate per l'erogazione di PHP includono PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. Apache mod_php, che esegue PHP all'interno del web server Apache, presenta il rischio documentato più elevato. I ricercatori hanno dimostrato che una singola request non autenticata può attivare un exploit prima ancora che inizi l'esecuzione del codice del sito web. L'aggiornamento di WordPress, Laravel o di un'altra applicazione non corregge il motore PHP sottostante.
PHP-FPM, che esegue le attività PHP in processi separati, si comporta in modo diverso perché un worker si chiude quando una request non riesce nelle prime fasi della configurazione. L'analisi di PHP indica che PHP-FPM è suscettibile a una delle vulnerabilità, sebbene non sia stato dimostrato alcun exploit completo per questa modalità. È stato invece dimostrato che l'altra vulnerabilità consente la remote code execution, ossia l'esecuzione di comandi da un altro sistema, sia tramite mod_php sia tramite PHP-FPM. La modalità relativa a PHP-FPM dipende da un'operazione eseguita dall'applicazione in funzione.
L'impatto non si limita alla possibilità di assumere il controllo di un processo. I ricercatori hanno inoltre dimostrato di poter leggere la memoria attiva dei worker PHP su applicazioni che non controllavano. Tale memoria può contenere password, token di autenticazione, chiavi API e certificati associati ad altre request. Questa tecnica non richiede che l'aggressore ottenga prima la code execution e non dipende da una vulnerabilità nell'applicazione installata sopra PHP.
Gli amministratori devono installare PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, a seconda del branch in uso. Devono quindi riavviare Apache, PHP-FPM e qualsiasi altro worker PHP di lunga durata affinché venga caricato il codice corretto. PHP 8.1 e le versioni precedenti non sono più supportati dal progetto PHP, anche se il suo team di sicurezza ha pubblicato source backports, ossia correzioni adattate al codice meno recente, per PHP 7.4, 8.0 e 8.1. PHP 8.2 raggiungerà l'end of life il 31 dicembre 2026.
Le distribuzioni Linux e i fornitori di supporto a lungo termine hanno ricevuto le patch in anticipo. I loro pacchetti possono quindi contenere la correzione pur mantenendo un numero di versione PHP apparentemente meno recente. Debian consiglia di controllare nel changelog del pacchetto l'identificatore CVE pertinente, anziché affidarsi soltanto alla versione visualizzata.
Le modifiche temporanee alla configurazione affrontano soltanto alcune parti dell'attack surface. Per CVE-2026-109618, l'avviso consiglia di impostare memory_limit=-1 affinché le applicazioni non possano modificarlo, di mantenere basso post_max_size e di limitare le dimensioni delle request a livello di web server o proxy. PHP mette in guardia dall'utilizzare RLIMIT_AS o RLIMIT_DATA come alternative, perché possono attivare la stessa modalità vulnerabile. Per CVE-2026-109619, gli amministratori possono impostare session.upload_progress.enabled=0 e riavviare ogni worker. Sui sistemi PHP 8.5 è inoltre necessario impostare fatal_error_backtraces=0. La disattivazione dell'avanzamento dell'upload di sessione blocca le modalità confermate legate alle sessioni, ma non tutte le possibili varianti, e non ha alcun effetto su CVE-2026-109618.
L'aggiornamento introduce un limite rigido di memoria. Se tale limite viene raggiunto, PHP termina il processo senza eseguire gli shutdown handlers, ossia le attività normalmente svolte alla chiusura di una request. Dopo l'applicazione della patch, gli amministratori devono quindi verificare che memory_limit e post_max_size siano adeguati alle legittime esigenze delle loro applicazioni. Per individuare una possibile compromissione precedente, i ricercatori consigliano di cercare multipart requests insolite, comunemente utilizzate per l'upload di file e l'invio di moduli, seguite da errori relativi al limite di memoria o da ripetuti errori HTTP 500 del server. Altri segnali di allarme includono cookie di risposta PHPSESSID insolitamente grandi e riavvii inspiegabili dei worker PHP.
È già stato osservato traffico di attacco, ma al momento dell'ultimo aggiornamento non era stata confermata la compromissione di alcun server specifico. Cloudflare ha segnalato i primi attacchi e successivamente ha dichiarato che gli aggressori avevano modificato i propri payload per eludere le regole del firewall attivate per impostazione predefinita alle 03:02 UTC del 21 ottobre. L'azienda ha descritto tali regole come una misura temporanea e ha sollecitato l'installazione delle patch. watchTowr aveva inizialmente riferito, alle 11:26 UTC, che non risultavano exploit attivi, ma alle 14:19 UTC ha dichiarato di osservare tentativi attivi contro entrambe le vulnerabilità. In quel momento precedente, nessuno dei due CVE figurava nel catalogo Known Exploited Vulnerabilities della CISA.
Alcuni servizi sono stati disattivati a scopo precauzionale e non a causa di un'intrusione confermata. BambooHR ha sospeso il servizio negli Stati Uniti, in Canada e in Irlanda, avvertendo che l'elaborazione delle retribuzioni sarebbe stata interrotta senza indicare quando il servizio sarebbe stato ripristinato. Secondo NOS, sono stati disattivati anche servizi olandesi, tra cui MijnOverheid, DigiD, il sito web della camera bassa del parlamento, il centro nazionale per la cybersicurezza e diversi sistemi educativi. Il centro ha dichiarato di non aver osservato abusi, ma ha consigliato alle organizzazioni di installare le patch.
Il calendario della divulgazione è stato sconvolto prima che le correzioni diventassero disponibili. Un post su Hacker News del 20 ottobre ha indicato entrambi i CVE e ha affermato che la loro divulgazione era prevista per il 22 ottobre. PHP ha pubblicato un preavviso quella sera e ha anticipato la pubblicazione portandola vicino all'orario previsto per il rilascio, le 14:00 UTC del 21 ottobre. PHP assegna a entrambe le vulnerabilità un punteggio di 9,2, non il 10,0 indicato nella fuga di notizie. La PHP Foundation ha successivamente dichiarato che Calif aveva pubblicato per errore un video di un proof of concept funzionante intorno alle 20:00 UTC del 20 ottobre. Chainguard ha poi rilasciato alle 07:41 UTC del 21 ottobre immagini compilate contenenti la patch, circa sei ore prima della correzione ufficiale, consentendo di studiare le modifiche mentre gli altri utenti erano ancora in attesa.
Il codice vulnerabile esisteva da oltre un decennio. La PHP Foundation ha dichiarato che, durante un audit esterno del 2024, uno sviluppatore del core aveva notato segnali del problema di out-of-memory alla base di CVE-2026-109618, ma all'epoca non era stata individuata alcuna modalità concreta per ottenere la code execution. Le correzioni proposte rischiavano di causare problemi di compatibilità, condizioni di denial-of-service o modifiche per le estensioni di terze parti, e il lavoro si è bloccato mentre il piccolo team faticava a raggiungere una decisione. La Foundation ha descritto l'accaduto come un fallimento strutturale e ha affermato di aver successivamente modificato il proprio processo decisionale in materia di sicurezza, aggiungendo personale e strumenti.
Le segnalazioni presentate nel 2026 da Calif, OpenAI e Wiz hanno dimostrato un exploit funzionante e aumentato la priorità della vulnerabilità. I ricercatori hanno affermato che i modelli di intelligenza artificiale hanno aiutato uno di loro a completare in circa una settimana un lavoro che, a loro giudizio, avrebbe altrimenti richiesto mesi a un intero team.