PHP2Shell: non è solo
un problema dei siti web

Il 21 ottobre 2026 il progetto PHP ha pubblicato quattro versioni correttive per due vulnerabilità critiche nell’interprete, CVE-2026-109618 e CVE-2026-109619, ribattezzate PHP2Shell. Entrambe valgono 9,2 su 10 nella scala CVSS (Common Vulnerability Scoring System) versione 4.0 e permettono a un attaccante remoto, senza credenziali, di eseguire codice sul server o di leggere la memoria del processo. La copertura di questi giorni parla quasi solo di siti web, WordPress in testa. Il punto che manca è un altro: il difetto è nel runtime, e PHP gira anche dentro la GUI dei firewall, nel captive portal, nei NAS (Network Attached Storage), nei centralini e nei sistemi di ticketing. Chi ha fatto l’inventario dei siti ha fatto metà del lavoro.

Cosa è successo tra il 17 e il 21 ottobre

Le due falle nascono dallo stesso punto debole: il modo in cui PHP gestisce gli errori fatali, in particolare l’esaurimento della memoria, mentre sta elaborando una richiesta. La CVE-2026-109618 interrompe PHP quando le strutture interne della richiesta sono inizializzate solo in parte, e la pulizia successiva tratta dati non validi come validi. La CVE-2026-109619 lascia nello stato globale del worker riferimenti a memoria già liberata, che una richiesta successiva servita dallo stesso worker riusa prima che l’inizializzazione li azzeri. Il codice vulnerabile, secondo Wiz Research che ha scoperto i difetti il 19 agosto e li ha segnalati il 24, è presente da PHP 5.4, cioè dal 2012.

La divulgazione coordinata non ha retto. Il 17 ottobre gli honeypot di Amazon registrano un primo tentativo di sfruttamento, da una rete di anonimizzazione commerciale. Il 20 ottobre i dettagli tecnici trapelano in pubblico e il progetto PHP annuncia una release straordinaria per il giorno dopo. Il 21 ottobre alle 14:00 UTC escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35; Cloudflare aveva già attivato le protezioni del proprio WAF (Web Application Firewall) alle 03:02 UTC e dichiara di aver osservato traffico di attacco contro i propri clienti. Lo stesso pomeriggio l’ACN (Agenzia per la Cybersicurezza Nazionale) pubblica l’alert AL07/261021/CSIRT-ITA con impatto sistemico «Alto (65,64)», il CERT-EU l’advisory 2026-018 e il SANS Internet Storm Center porta il proprio livello di allerta a giallo. Al 22 ottobre non risultano compromissioni confermate su sistemi reali, ma i tentativi sono documentati e i proof of concept sono pubblici.

Per PHP 8.1 e precedenti il progetto non pubblica correzioni: l’ACN lo scrive in modo esplicito. Il team di sicurezza PHP ha però reso disponibili backport sorgente minimali per 7.4, 8.0 e 8.1, e le distribuzioni Linux e i fornitori LTS, avvisati in anticipo, stanno rilasciando pacchetti propri. Un dettaglio da segnare in agenda: PHP 8.2 esce dal supporto il 31 dicembre 2026.

Perché aggiornare WordPress non basta

La richiesta malevola viene elaborata da PHP prima che parta il codice dell’applicazione. Per questo aggiornare WordPress, il tema o i plugin non cambia nulla: va aggiornato l’interprete che esegue il sito, e se l’hosting è condiviso va chiesto all’hosting. Wiz ha dimostrato l’esecuzione di codice senza autenticazione sulle immagini ufficiali più recenti di WordPress, Drupal e Joomla, ma precisa che anche una pagina «Hello World» su un PHP vulnerabile è attaccabile. Il rischio più alto, secondo php.net, è su Apache con mod_php, dove l’attacco riesce con le impostazioni predefinite; PHP-FPM, php-cgi, FrankenPHP e LiteSpeed sono comunque interessati.

C’è un secondo effetto, meno citato: la CVE-2026-109618 permette anche di leggere la memoria del processo PHP senza arrivare all’esecuzione di codice. In quella memoria passano password, token di sessione, chiavi API e, secondo Sansec, anche chiavi private TLS. Chi scopre di essere stato esposto non chiude l’incidente con la patch: deve ruotare i segreti.

È la stessa conclusione a cui eravamo arrivati nell’articolo sulle vulnerabilità di WordPress: il problema non è il singolo plugin, è avere un interprete in ascolto su Internet per servire pagine che non cambiano. Un sito statico, generato in fase di build e distribuito da una CDN, non ha PHP, non ha worker, non ha nulla da aggiornare questa settimana. Il nostro sito è fatto così, e così è l’ hosting gestito che proponiamo su Azure Static Web Apps.

PHP non gira solo nei siti: firewall, NAS, centralini, ITSM

Molti apparati di rete e molte applicazioni aziendali hanno un’interfaccia web scritta in PHP. Il produttore la aggiorna con il firmware, quindi la versione di PHP non la sceglie l’azienda e spesso nessuno sa quale sia. Nei due giorni dopo la patch gli advisory dei produttori sono arrivati a ondate, e raccontano quattro situazioni diverse.

Firewall open source. pfSense e OPNsense hanno la GUI e il captive portal in PHP. Entrambi hanno pubblicato i pacchetti corretti il 21 ottobre: OPNsense con un hotfix per l’edizione Community e per la Business, pfSense con nuovi pacchetti PHP per le versioni supportate, da installare da shell e non dalla GUI. Il captive portal è il caso peggiore: è un servizio PHP progettato per rispondere a client non fidati, in hotel, negozi, sale d’attesa e reti ospiti, e va riavviato dopo l’aggiornamento. La GUI invece risponde di default solo sulla LAN: se è così, resta una questione di igiene, non un’emergenza.

Firewall e apparati commerciali. Alcuni grandi produttori hanno dichiarato vulnerabile l’interfaccia web di gestione delle proprie appliance e, al 22 ottobre, non hanno ancora una data per la correzione; altri hanno un elenco lungo di prodotti «in verifica» e nessuno confermato. In entrambi i casi la raccomandazione è la stessa: gestione raggiungibile solo da indirizzi interni fidati e, in attesa del fix, nessuna porta di gestione su Internet.

NAS. I sistemi operativi di alcuni NAS usano PHP nei componenti web e nelle applicazioni; al 22 ottobre un produttore molto diffuso segna tutte le versioni come «in correzione» e chiede di togliere il NAS da Internet, usare la VPN e fermare i servizi non necessari. Altre piattaforme NAS non usano PHP nel sistema, ma lo usano le app installate, come il cloud di file o un CMS: lì si aggiorna l’app, non il firmware.

Centralini, ITSM e il resto. I centralini open source hanno la GUI di amministrazione in PHP: le versioni recenti su una distribuzione supportata ricevono il PHP corretto dai repository della distribuzione, quelle vecchie girano su rami di PHP senza supporto e restano scoperte. Lo stesso vale per sistemi di ticketing, wiki, frontend di monitoraggio, webmail e pannelli di hosting: non va aggiornata l’applicazione, va aggiornato il PHP che ci sta sotto, con il pacchetto della distribuzione o del fornitore; nelle versioni cloud gestite dal fornitore se ne occupa lui.

Per ogni apparato non coperto da un advisory vale una domanda sola, da fare al fornitore: la GUI esegue PHP, con quale versione, e da dove è raggiungibile?

Cosa fare in azienda, in questo ordine

• Inventario di dove gira PHP. Siti e portali, anche quelli «dimenticati»; GUI di firewall e router; captive portal; NAS e videosorveglianza; centralino; ITSM, wiki, monitoraggio, webmail; container e app installate sul NAS. Per ciascuno: versione di PHP che serve le richieste (non quella della riga di comando, che può essere diversa) e da quali reti è raggiungibile.
• Chiudere ciò che è esposto. Nessuna interfaccia di gestione e nessun captive portal direttamente su Internet. L’accesso remoto passa da VPN o da un accesso Zero Trust, e la GUI risponde solo a reti e indirizzi fidati. Se un servizio vulnerabile non può essere aggiornato né protetto, l’ACN raccomanda di valutare di metterlo offline fino all’aggiornamento.
• Aggiornare e riavviare i worker. PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure il pacchetto della distribuzione o del produttore che riporta le correzioni. Il nuovo binario entra in funzione solo dopo il riavvio di PHP-FPM o del server web, e del captive portal dove c’è. Verificare poi la versione dal lato web, non solo da shell.
• Mitigazioni temporanee, solo se la patch non c’è. Le impostazioni indicate da php.net riducono l’esposizione a percorsi specifici e non rendono sicura un’installazione: memory_limit senza limite imposto dall’amministratore, post_max_size basso, session.upload_progress.enabled disattivato con riavvio dei worker, fatal_error_backtraces disattivato su PHP 8.5. Non usare RLIMIT_AS o RLIMIT_DATA, che attivano proprio il percorso vulnerabile.
• Ruotare i segreti, se c’è stata esposizione. Dove un servizio vulnerabile è rimasto raggiungibile tra il 17 e il 21 ottobre, trattare come potenzialmente letti password applicative, token di sessione, chiavi API e certificati presenti in memoria, e ruotarli.
• Pianificare l’uscita dai rami vecchi. PHP 7.4, 8.0 e 8.1 non avranno versioni ufficiali; PHP 8.2 esce dal supporto il 31 dicembre 2026. Un’applicazione bloccata su un ramo vecchio è un problema da risolvere nei prossimi due mesi, non alla prossima emergenza.

Cosa cercare nei log, anche se hai già aggiornato

L’alert dell’ACN chiede un’analisi retrospettiva dei log «indipendentemente dall’applicazione degli aggiornamenti», e la ragione è la cronologia: quattro giorni di tentativi prima della patch, su cui nessuno stava guardando. La finestra da coprire parte almeno dal 17 ottobre. I segnali convergono tra ACN, Wiz, Amazon e gli advisory PHP:

• Richieste POST multipart anomale: filename molto lunghi, molte intestazioni per parte, dimensioni vicine al limite, campo PHP_SESSION_UPLOAD_PROGRESS presente.
• Errori ricorrenti di memoria esaurita, risposte HTTP 500 ripetute, «Maximum execution time exceeded», riavvii o ricambio inatteso dei worker PHP.
• Cookie PHPSESSID di risposta anomali, troppo grandi o malformati: è la traccia della lettura di memoria.
• Sul sistema: processi non previsti avviati dal worker web, file applicativi modificati, nuovi cron o account, connessioni in uscita non spiegate.

Un’avvertenza che viene dagli advisory PHP e che vale più di tutto l’elenco: l’assenza di errori nei log non è prova di sicurezza. I log storici possono essere stati raccolti senza le deprecazioni, e il malfunzionamento può avvenire prima che PHP scriva il messaggio. Chi deve firmare una relazione lo sappia prima di firmarla. Se qualcosa non torna, è il momento della risposta all’incidente, non di un altro grep.

Il punto strutturale: meno runtime esposti, meno emergenze

PHP2Shell non è il primo caso e non sarà l’ultimo: Heartbleed nel 2014 e Log4Shell nel 2021 avevano la stessa forma, un componente condiviso da tutti con un difetto che nessuno vedeva. Quello che un’azienda può decidere non è se il prossimo arriverà, ma quanta superficie gli offre. Tre scelte che riducono la superficie in modo permanente: un sito statico al posto di un CMS con interprete, che toglie PHP dal perimetro; un firewall gestito dal cloud con la GUI mai esposta, dove l’amministrazione passa da un controller e non da una porta aperta sul WAN; un accesso Zero Trust al posto delle porte di gestione pubblicate. A valle, un vulnerability assessment periodico dall’esterno dice quali interfacce rispondono davvero su Internet, che è spesso diverso da quello che si credeva.