Hai aggiornato PHP? Potresti avere ancora PHP2Shell dentro firewall e router

Le vulnerabilità PHP2Shell continuano a minacciare firewall, router e dispositivi industriali, anche dopo la pubblicazione delle correzioni ufficiali del 21 ottobre 2026. Il problema riguarda soprattutto gli apparati che incorporano l’interprete PHP nel firmware: aggiornare il componente vulnerabile non è semplice come installare un pacchetto su un server Linux. Serve un intervento del produttore e, talvolta, una nuova release dell’intero sistema operativo.

Le due falle principali, CVE-2026-109618 e CVE-2026-109619, possono consentire l’esecuzione remota di codice (RCE) senza autenticazione.

PHP, nato nel 1995 e progressivamente adottato anche per realizzare interfacce di amministrazione, è presente in numerosi prodotti di sicurezza e piattaforme industriali: per questo il rischio interessa dispositivi che spesso proteggono l’accesso alle reti aziendali.

Secondo il National Cyber Security Centre dei Paesi Bassi, al 4 novembre 2026 risultavano censiti 948 prodotti potenzialmente interessati, con 215 classificati come vulnerabili e 185 già corretti: versione, configurazione ed esposizione dei servizi determinano il rischio effettivo.

Perché PHP2Shell rappresenta un problema per i firewall

Un prodotto firewall offre funzionalità molto più articolate del semplice filtraggio dei pacchetti: VPN, gestione dei certificati, autenticazione, monitoraggio e interfacce Web di configurazione. Alcuni fornitori utilizzano PHP proprio per implementare queste funzionalità.

Le vulnerabilità PHP2Shell, come abbiamo spiegato in altri nostri articoli, colpiscono il motore del linguaggio. La prima riguarda una gestione anomala dell’esaurimento della memoria, capace di lasciare strutture interne in uno stato inconsistente; la seconda coinvolge riferimenti a memoria non più valida che possono persistere tra richieste HTTP successive.

Un aggressore può sfruttare queste condizioni attraverso richieste opportunamente costruite, senza dipendere da eventuali problemi lato applicativo. La tecnica risulta particolarmente pericolosa con Apache e mod_php, dove alcuni percorsi vulnerabili si attivano prima dell’esecuzione dello script.

Le dimostrazioni pubblicate dai ricercatori hanno inoltre evidenziato la possibilità di aggirare la protezione ASLR sfruttando perdite di informazioni dalla memoria.

Gli attacchi ai firewall Palo Alto dimostrano che il rischio è concreto

Dream Research ha documentato una campagna di aggressione che ha compromesso 25 sistemi Palo Alto Networks sfruttando PHP2Shell insieme alla vulnerabilità Linux CVE-2026-46300, utilizzata per ottenere privilegi estesi.

Gli aggressori hanno raggiunto anche un server di gestione interno, predisponendo tunnel SSH inversi e tentando ulteriori attacchi contro Active Directory. Abbiamo già ricostruito come PHP2Shell abbia permesso di violare i firewall e raggiungere la rete aziendale.

Facendo leva sulle vulnerabilità alla base di PHP2Shell, un firewall può diventare un punto d’ingresso privilegiato, anziché costituire una barriera contro gli attacchi.

Il vero ostacolo: PHP incorporato nei firmware e versioni obsolete

Il progetto PHP ha corretto le vulnerabilità nelle versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Numerosi apparati, tuttavia, integrano versioni precedenti, talvolta appartenenti a rami che non ricevono più manutenzione ordinaria. Come accennato in apertura, installare direttamente una versione PHP recente all’interno di un dispositivo acquistato o fornito da terze parti non è un’opzione prevista per l’amministratore: l’interprete fa parte di un firmware che comprende componenti proprietari, librerie e servizi strettamente integrati.

Il produttore deve quindi applicare le correzioni al codice utilizzato, verificarne la compatibilità e distribuirle attraverso aggiornamenti dedicati.

Negli ambienti industriali intervengono ulteriori difficoltà: cicli di manutenzione rigidi, requisiti di continuità operativa e apparati che non possono essere riavviati senza programmare un fermo.

Il problema interessa anche prodotti industriali e piattaforme di comunicazione. Siemens ha pubblicato un avviso di sicurezza per RUGGEDCOM APE1808, in relazione alle versioni PAN-OS vulnerabili installate su questi sistemi.

Cisco ha segnalato prodotti interessati, tra cui Expressway, Duo Access Gateway e alcune piattaforme wireless industriali. Le condizioni di sfruttamento non sono però identiche: per determinati prodotti l’attaccante deve già possedere privilegi amministrativi. Il relativo advisory Cisco distingue le release coinvolte e quelle correttive.

Come individuare i dispositivi vulnerabili e proteggerli

Il primo intervento consiste nel censire gli apparati, registrando modello, firmware e servizi di amministrazione disponibili. L’inventario deve comprendere anche sistemi meno evidenti, come appliance di gestione, gateway e dispositivi industriali: abbiamo già visto come individuare installazioni PHP nascoste e potenzialmente vulnerabili.

Non basta controllare la versione PHP dichiarata nelle intestazioni HTTP: alcuni produttori applicano backport delle patch senza modificare la numerazione principale. Fanno fede gli advisory ufficiali e la versione esatta del firmware.

In attesa degli aggiornamenti, è essenziale impedire l’accesso pubblico alle interfacce di amministrazione, consentendo le connessioni soltanto da reti dedicate, jump server (server intermedio utilizzato dagli amministratori per accedere in modo controllato a dispositivi e sistemi che non devono essere raggiungibili direttamente da Internet) o indirizzi autorizzati. È inoltre essenziale verificare che le interfacce dati non espongano accidentalmente servizi di gestione.

Sulle installazioni PHP amministrabili direttamente, è inoltre caldamente consigliata la disattivazione della direttiva session.upload_progress.enabled al fine di ridurre alcuni percorsi di attacco. La misura richiede però una verifica della configurazione e non sostituisce le patch, come spiegato nell’approfondimento sulle mitigazioni PHP2Shell.

Se il firewall è già compromesso, aggiornare potrebbe non bastare

Una patch elimina la vulnerabilità, ma non garantisce la rimozione di eventuali componenti malevoli già presenti: gli attacchi documentati hanno utilizzato webshell, script persistenti e tunnel SSH per mantenere l’accesso ai sistemi compromessi.

Per gli apparati precedentemente esposti bisogna quindi analizzare log, configurazioni, connessioni anomale e indicatori di compromissione; se si rilevassero evidenze di intrusione, può risultare necessario ripristinare il dispositivo da immagini affidabili e sostituire le credenziali coinvolte.

PHP2Shell evidenzia un problema che va oltre le singole vulnerabilità: la sicurezza di un’appliance dipende anche dai componenti software incorporati, spesso invisibili all’amministratore e aggiornabili soltanto dal produttore. Conoscere queste dipendenze e isolare correttamente le interfacce di gestione diventa fondamentale per ridurre i rischi.