Un NAS per l’accesso remoto, una porta di un container pubblicata o un gateway aperto tempo fa in via provvisoria: questi servizi possono sfuggire ai controlli. Per PHP2Shell contano tre domande: che cosa è raggiungibile, quale runtime elabora le richieste web e quali altre risorse può raggiungere quel servizio?
I primi due articoli della serie descrivono la situazione di sicurezza di PHP e la nostra risposta e il supporto dell’IA nella verifica dell’inventario. Qui affrontiamo i controlli pratici per aziende e privati che gestiscono un NAS. Un marchio non sostituisce un inventario. Nemmeno un firmware aggiornato dimostra che ogni pacchetto e ogni container in esecuzione sia stato aggiornato.
PHP2Shell riguarda il runtime che gestisce davvero le richieste web
CVE-2026-109618 e CVE-2026-109619 possono consentire l’esecuzione di codice prima dell’autenticazione nell’applicazione; entrambe hanno un punteggio CVSS v4.0 di 9,2. Il progetto PHP ha pubblicato le versioni corrette 8.2.35, 8.3.36, 8.4.27 e 8.5.12 il 21 ottobre 2026. I fornitori possono distribuire anche propri pacchetti con correzioni riportate su versioni precedenti. È quindi determinante l’avviso del fornitore, non il solo numero di versione.
Una pagina di accesso non offre automaticamente protezione in questo caso. Va verificato l’interprete che elabora effettivamente le richieste web, compresi i processi attivi. Una versione recente di PHP da riga di comando, da sola, non basta a dimostrarlo. Il principio vale per i server web tradizionali e per i runtime inclusi in applicazioni, appliance e immagini.
L’esposizione pubblica non si limita al port forwarding
L’inventario deve comprendere IPv4 e IPv6, regole del router, UPnP, nomi DDNS, destinazioni del reverse proxy, tunnel e accessi remoti mediati dal cloud. Per ciascun caso occorre ricostruire il percorso reale: un indirizzo IP pubblico non equivale a un’applicazione vulnerabile. Anche un relay del produttore non è automaticamente esposto allo stesso vettore di attacco. Viceversa, una regola dimenticata può rendere accessibile un servizio che doveva restare interno.
Includete siti, CMS, portali clienti, pannelli di hosting e interfacce di backup, monitoraggio e amministrazione. Lo stesso vale per piattaforme NAS, sistemi VoIP, telecamere, stampanti e gateway di controllo. Un dispositivo senza un componente PHP rilevante non è automaticamente interessato da queste due CVE. La sua accessibilità pubblica rimane comunque una domanda utile per la sicurezza.
Synology: valutare separatamente sistema e pacchetti
Synology circoscrive l’impatto ad alcuni pacchetti dipendenti da PHP, tra cui Web Station, WordPress, Calendar e MailStation. Il comunicato del 22 ottobre indica aggiornamenti PHP per DSM 7.4, 7.3 ed esplicitamente anche DSM 7.2, sebbene questa versione di DSM abbia raggiunto la fine del ciclo di vita. Per le versioni precedenti il produttore raccomanda di disattivare temporaneamente i pacchetti interessati.
PHP si aggiorna dal Centro pacchetti; MailStation richiede inoltre un aggiornamento manuale del proprio pacchetto. L’avviso non prevede una correzione per il pacchetto Synology PHP 7.3. Secondo il produttore, il PHP usato internamente da DSM ha un’esposizione diversa e non comprende moduli accessibili dall’esterno. Attenzione anche ai nomi: il pacchetto di terze parti IDrive non è Synology Drive, che il comunicato indica come non interessato.
Per le installazioni non ufficiali di DSM tramite XPEnology occorre valutare singolarmente dispositivo, loader, DSM e pacchetti. Questa combinazione non corrisponde a un sistema Synology normalmente supportato. Ciò non significa che gli aggiornamenti siano sempre impossibili o che ogni installazione sia vulnerabile. Un percorso di aggiornamento incerto è però un buon motivo per limitare l’accesso diretto da Internet e pianificare una gestione affidabile nel tempo.
QNAP: verificare lo stato aggiornato dopo il primo annuncio
Dalla revisione del 24 ottobre, l’avviso QNAP QSA-26-18 elenca correzioni per diversi rami QTS, QuTS hero e QuTScloud. Altre applicazioni indicate risultano ancora in stato «Fixing». Né «QNAP non ha ancora una patch» né «è tutto risolto» descrive correttamente la situazione. Contano il prodotto specifico, il ramo di versione e la relativa release corretta. Un aggiornamento del sistema QNAP non corregge automaticamente PHP nelle applicazioni di terze parti o nei container personalizzati.
Per i container servono due valutazioni distinte
Primo: il runtime nel container attivo è stato corretto? Aggiornare l’host non sostituisce una vecchia immagine. Immagine di base, pacchetti aggiuntivi e distribuzione realmente in esecuzione devono essere coerenti. Avere una nuova immagine disponibile localmente serve solo quando il servizio è stato ridistribuito con la versione corretta e ha superato i controlli funzionali.
Secondo: quali permessi e percorsi di rete possiede il servizio? Le reti bridge di Docker consentono generalmente connessioni in uscita e i container nella stessa rete bridge possono comunicare tra loro. Le destinazioni interne raggiungibili dipendono, tra l’altro, da routing e regole del firewall. Un container compromesso non prende quindi automaticamente il controllo dell’intera LAN. Credenziali condivise, mount dell’host non necessari, privilegi aggiuntivi o un socket Docker montato possono però ampliare molto le conseguenze. Reti separate, regole di uscita mirate e permessi minimi richiedono una verifica concreta.
Sette verifiche per la prossima sessione di lavoro
- Censire gli accessi: documentare dispositivi, applicazioni, porte pubblicate e servizi intermedi, con i rispettivi responsabili. Includere IPv6 e le regole temporanee dimenticate.
- Identificare i runtime: rilevare sistema, pacchetti, plugin e PHP web di ogni servizio. Verificare gli avvisi del fornitore e lo stato di manutenzione.
- Correggere e verificare: installare aggiornamenti o immagini adeguati, riavviare correttamente i servizi interessati e controllare la versione realmente attiva.
- Ridurre l’esposizione: chiudere gli accessi pubblici di amministrazione non necessari. Una VPN o una rete di amministrazione fidata può limitare l’accesso; anche dietro questa protezione restano necessari gli aggiornamenti.
- Testare percorsi e permessi: limitare l’accesso a database, NAS, backup e sistemi di gestione a quanto serve. Modificare le regole senza compromettere l’operatività e verificare poi le applicazioni legittime.
- Esaminare tracce e ripristino: valutare accessi, account e connessioni in uscita insoliti. Disporre di backup indipendenti protetti dalle modifiche non autorizzate e testare il ripristino; gli snapshot da soli non li sostituiscono.
- Seguire le eccezioni: documentare i sistemi senza una correzione disponibile, con un responsabile, una misura provvisoria e un piano di sostituzione o dismissione.
Una patch non conclude automaticamente l’analisi di un incidente
Sophos cita un tentativo di sfruttamento osservato da Amazon Threat Intelligence già il 17 ottobre, prima della divulgazione pubblica. Per i sistemi realmente esposti va quindi valutata anche l’attività precedente. Un aggiornamento riuscito non dimostra che prima non si sia verificato un accesso non autorizzato. In presenza di indizi di compromissione serve una risposta all’incidente organizzata, con adeguata conservazione delle evidenze e un ripristino controllato.
Dal 23 ottobre PHP segnala inoltre un ulteriore caso raro, dipendente dalla configurazione, relativo all’avanzamento degli upload di sessione. Le indicazioni aggiornate dei fornitori restano quindi rilevanti anche dopo il primo aggiornamento. Cambiare globalmente una configurazione senza conoscerne gli effetti operativi non è una buona scorciatoia.
Ciò che non deve necessariamente essere pubblico dovrebbe restare inaccessibile da Internet fino alla verifica. Questo riduce la superficie di attacco e non sostituisce la correzione. DAXS aiuta a identificare i servizi, stabilire le priorità e verificare l’efficacia delle misure in modo tracciabile. Parliamo del vostro ambiente.
Fonti: PHP: avvisi di sicurezza e versioni corrette · ENISA: identificare le applicazioni PHP e limitare l’esposizione · Synology: pacchetti interessati e versioni DSM · Synology-SA-26:14 · QNAP QSA-26-18: correzioni per prodotto · Docker: comportamento delle reti bridge · Sophos: esposizione, attività e analisi degli incidenti · NCSC-NL: panoramica delle dipendenze PHP · Red Hat: runtime, backport e indicazioni aggiuntive.
