PHP2Shell su Synology: come abbiamo applicato le patch a sei siti in un solo giorno

PHP2Shell CVE-2026-109618 e CVE-2026-109619 sono due vulnerabilità critiche del motore PHP che consentono l'esecuzione di codice remoto senza autenticazione. I dettagli sono trapelati il 20 ottobre 2026, un giorno prima della divulgazione coordinata, e il progetto PHP ha rilasciato versioni di emergenza il 21 ottobre. Poiché il bug risiede nell'interprete e non in alcuna applicazione, l'applicazione di patch a WordPress, Joomla o MediaWiki non ha alcun effetto. L'unica vera soluzione è una nuova build di PHP. Gestiamo sei siti WordPress pubblici su hardware Synology e, a causa di PHP2Shell, ognuno di essi ha dovuto essere ricostruito nella stessa settimana. Questa guida illustra in cosa consiste effettivamente il bug, come applicarlo su DSM tramite Package Center, come gestirlo quando il sito viene eseguito in un container e il difficile confronto tra la versione rilasciata da Synology e quella realizzata finora dagli altri produttori di NAS.

Punto SynoPower Club:I nostri sei siti sono stati aggiornati entro un giorno lavorativo dalla pubblicazione dell'avviso di sicurezza PHP2Shell, e ciò non è stato possibile grazie a imprese eroiche, bensì grazie alla pubblicazione da parte di Synology di pacchetti corretti nella stessa data dell'avviso. Synology-SA-26:14 è stato rilasciato il 22 ottobre con stato "Risolto" e una tabella completa delle versioni corrette fino a PHP 7.4. Lo stesso giorno, QNAP ha pubblicato QSA-26-18 con stato "In fase di correzione" e la dicitura "Da annunciare" in ogni cella relativa alla versione corretta, e ASUSTOR ha risposto eliminando la versione legacy di PHP da App Central anziché applicarvi una patch. Se ospitate un sito web pubblico su un NAS, questa lacuna non è un dettaglio di marketing. È la differenza tra aggiornare un pacchetto e dover rimuovere il vostro sito da internet in attesa dell'aggiornamento.

Cos'è PHP2Shell e perché è diverso

PHP2Shell non è un singolo bug, ma un insieme di errori correlati di sicurezza della memoria nel modo in cui PHP gestisce la pulizia dopo una richiesta che ha esaurito la memoria. PHP utilizza longjmp() per sfuggire a errori fatali, inclusi quelli di memoria insufficiente, e quel salto salta il codice di pulizia che normalmente riporterebbe il motore a uno stato noto. Parte di quello stato è globale e sopravvive alla richiesta successiva gestita dallo stesso processo worker.

CVE-2026-109618 riguarda la vulnerabilità di memoria insufficiente. Una richiesta HTTP appositamente creata esaurisce il limite di memoria mentre i dati della richiesta sono solo parzialmente inizializzati, quindi la routine di pulizia attraversa strutture che non sono mai state completate. CVE-2026-109619 riguarda la vulnerabilità di tipo use-after-free: lo stato globale che punta alla memoria di richiesta liberata può essere letto da una richiesta successiva sullo stesso worker, ed è così che il bug si trasforma in esecuzione di codice o divulgazione di memoria.

Due caratteristiche rendono PHP2Shell peggiore dei soliti avvisi PHP. In primo luogo, è pre-autenticazione. Entrambe le vulnerabilità si attivano prima che venga eseguita qualsiasi autenticazione a livello di applicazione, quindi un sistema di login, un plugin per la gestione degli abbonamenti o una password di amministratore non proteggono nulla. In secondo luogo, la variante di divulgazione della memoria espone la memoria del processo worker, e un processo worker PHP su un sito WordPress contiene credenziali di database, token API e chiavi di pagamento. Una lettura riuscita non ha bisogno di raggiungere l'esecuzione del codice per rovinarti la settimana.

Le due vulnerabilità CVE di PHP2Shell sono state valutate con un punteggio CVSS v4.0 di 9.2 dal team di sicurezza di PHP. Synology, nel proprio avviso di sicurezza, ha assegnato loro un punteggio di 9.8 su CVSS v3.1. Scale diverse, stessa conclusione. Le segnalazioni di exploit sono contrastanti: watchTowr afferma di aver rilevato tentativi contro la sua rete honeypot, mentre Bitdefender non ha segnalato nulla nella sua telemetria al momento della stesura di questo articolo e QNAP dichiara di non aver ricevuto segnalazioni di exploit specificamente mirati ai prodotti QNAP.

PHP2Shell contro un normale exploit di WordPress

La maggior parte delle minacce che colpiscono un sito WordPress pubblico deriva da vulnerabilità dei plugin. Lo schema è ben noto: un plugin rilascia un endpoint REST non funzionante, uno scanner lo rileva, si aggiorna il plugin e la falla si chiude. PHP2Shell rompe completamente questo schema, rendendo superfluo e inutile l'incessante verifica dei plugin.

Aspetto	CVE tipico del plugin	PHP2Shell
Dove vive l'insetto	Codice dell'applicazione (plugin o tema)	L'interprete PHP stesso
Chi può attivarlo?	Spesso richiede un ruolo di abbonato o di amministratore.	Nessuno. Pre-autenticazione, prima che venga eseguita la logica dell'app.
L'aggiornamento di WordPress è utile?	Di solito sì	No. Gli aggiornamenti del core e dei plugin sono irrilevanti.
Un WAF lo impedisce	Di solito, una volta che esiste una regola	In parte. Le regole della forma della richiesta non riescono a trovare il percorso OOM.
Cosa lo risolve effettivamente?	Aggiornamento del plugin	Una nuova build di PHP, nient'altro.
Raggio d'esplosione	Un sito, una funzionalità	Tutti i siti PHP presenti sul server, tutti in una volta

Quell'ultima riga è il motivo per cui PHP2Shell si è trasformato in un'intera giornata di lavoro anziché in un pomeriggio. Un singolo pacchetto PHP condiviso su un NAS può trovarsi dietro una dozzina di host virtuali di Web Station, e una singola immagine container può essere la base per diversi siti. L'applicazione delle patch non è per sito, ma per runtime, e bisogna elencare i runtime prima di poter affermare che qualcosa è stato fatto.

Come capire se il tuo NAS è esposto

Valutare la propria esposizione a PHP2Shell inizia distinguendo due questioni distinte. Il sistema contiene una build PHP vulnerabile? E questa build è accessibile da Internet? Synology fa esplicitamente questa distinzione: DSM include un componente PHP interno utilizzato dal sistema operativo e Synology afferma che non ha moduli accessibili dall'esterno e quindi nessuna superficie di attacco esposta. Il rischio assegnato a tale componente è minimo e la patch è prevista per una versione successiva di DSM, in modo che le scansioni di vulnerabilità smettano di segnalarlo.

I pacchetti rilevanti per PHP2Shell sono quelli che forniscono PHP al web. Synology elenca Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station e WordPress. Se hai installato e hai accesso a uno qualsiasi di questi pacchetti, rientri nell'ambito di applicazione.

Controlla direttamente le versioni anziché affidarti a una dashboard. In Package Center, i pacchetti PHP installati mostrano la loro versione nel riquadro e l'avviso di aggiornamento indica la build di destinazione. Da una shell, chiedi direttamente al runtime:

# Synology Pacchetto PHP (regola il percorso in base alla versione in esecuzione) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Un sito containerizzato docker exec php -v

Il motivo per insistere su php -v Quando si effettua un audit per PHP2Shell, il problema è che ogni segnale è falso. L'output di compilazione può segnalare un esito positivo pur riutilizzando un livello memorizzato nella cache, una dashboard può mostrare un pacchetto come aggiornato quando il worker in esecuzione non lo è, e un'intestazione di risposta HTTP può essere rimossa da una CDN prima ancora che tu la veda. Due dei nostri sei siti sono stati segnalati come funzionanti dalle rispettive schermate di amministrazione, pur utilizzando ancora un interprete non aggiornato.

Applicazione di patch a PHP2Shell su Synology in 4 passaggi

Per un sito Web Station su DSM, l'intera soluzione per PHP2Shell consiste in un aggiornamento del Centro pacchetti. Synology pubblica aggiornamenti di sicurezza PHP per DSM 7.4, 7.3 e 7.2 e, dopo l'aggiornamento del pacchetto PHP, i pacchetti dipendenti si riavviano automaticamente, risolvendo così il problema. Mail Station rappresenta un'eccezione documentata e richiede un aggiornamento manuale.

Lo screenshot qui sopra proviene da una delle nostre macchine, scattato la mattina successiva all'avviso di PHP2Shell. Si noti che il pannello "Novità" indica direttamente la versione upstream, consentendo di confrontare il suffisso di build Synology con la release di PHP senza dover fare supposizioni. Synology Calendar compare nello stesso elenco di aggiornamenti alla versione 3.0.4-21435, che è esattamente la versione indicata nell'avviso.

Un errore comune di PHP2Shell che vale la pena segnalare agli utenti di Web Station: una macchina DSM può avere installati contemporaneamente diversi rami di PHP e ogni host virtuale è associato a un profilo. L'aggiornamento del profilo predefinito non risolve il problema di un sito associato a un ramo diverso. Elenca prima i profili, aggiornali tutti e poi verifica l'associazione di ogni sito nella sezione Servizi Web.

Quali pacchetti DSM sono interessati?

La dichiarazione relativa all'aggiornamento Synology di PHP2Shell è più circoscritta di quanto il panico abbia lasciato intendere. Sono interessati solo i sistemi che eseguono determinati pacchetti dipendenti da PHP, e Synology Drive non è esplicitamente tra questi. IDrive è presente nell'elenco, ma è un software di terze parti.

• Visibile sul web e con la massima priorità. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer e phpMyAdmin. Questi forniscono PHP a chiunque riesca ad accedervi.
• Posta e calendario. Mail Station richiede un aggiornamento manuale dopo il pacchetto PHP. Il calendario Synology ha una propria build fissa alla versione 3.0.4-21435.
• La componente interna del DSM. Presente ma non raggiungibile dall'esterno, la patch è stata rimandata a una successiva versione di DSM, il rischio è stato valutato minimo da Synology.
• I contenitori non sono coperti. Il runtime PHP all'interno di Container Manager è a tua completa disposizione per essere aggiornato. Nessun aggiornamento di pacchetto lo modificherà, ed è proprio questa la ragione più comune per cui un utente NAS pensa di aver finito quando in realtà non è così.

Se si utilizza ancora una versione di DSM precedente alla 7.2, Synology consiglia di disabilitare temporaneamente i pacchetti interessati fino a quando non sarà disponibile una versione corretta. La versione 7.2 di DSM è indicata come non più supportata, nonostante abbia ricevuto questi aggiornamenti PHP.

Il caso più critico per PHP2Shell riguarda PHP 7.3 e versioni precedenti. La versione Synology non risolverà il problema con la 7.3 perché il ramo è obsoleto e il progetto upstream non ha pubblicato nulla per la 7.3 e le versioni precedenti. Alcune distribuzioni Linux hanno incluso backport per vecchi rami di sviluppo, ma un pacchetto PHP per la versione Synology non è un pacchetto di distribuzione. Se un sito richiede la versione 7.3 o 5.6 per funzionare, non verrà rilasciata alcuna patch e le opzioni più realistiche sono spostare il sito su un ramo supportato, proteggerlo con un WAF (Web Application Firewall) o rimuoverlo da internet.

Come i proprietari di siti container gestiscono PHP2Shell

Cinque dei nostri sei siti utilizzano WordPress in Docker anziché Web Station, ed è qui che PHP2Shell diventa interessante, perché Package Center non può esservi d'aiuto. L'ambiente di runtime è quello contenuto nell'immagine, e ricostruire un'immagine non è la stessa cosa che aggiornarla.

Il primo errore di PHP2Shell che abbiamo riscontrato, e quello che più probabilmente incapperà in altri casi, è che la ricostruzione di un'immagine personalizzata riutilizza il livello base memorizzato nella cache. Un pin non bloccato DA Il tag non significa "nuovo". Una delle nostre immagini era stata ricostruita quattro giorni prima e conteneva ancora una build PHP di luglio 2025, con oltre un anno di aggiornamenti di sicurezza obsoleti, perché nulla aveva costretto Docker a scaricare nuovamente la base.

# Sbagliato: riutilizza silenziosamente qualsiasi livello base sia memorizzato nella cache locale docker build -t mysite . # Corretto: scarica sempre di nuovo l'immagine base docker build --pull -t mysite . # Quindi avvia solo il servizio che intendi, senza avviare i servizi inattivi docker compose up -d --no-deps wordpress # E verifica ciò che conta davvero docker exec wordpress php -v

Il secondo errore di PHP2Shell è più grave perché segnala un successo. Inoltrando l'output di compilazione tramite coda nasconde un errore di compilazione, poiché il codice di uscita di una pipeline appartiene all'ultimo comando in essa e imposta -e non viene mai eseguito. Il passaggio di composizione ricrea quindi il container dalla vecchia immagine, stampa Avviato e ti allontani da un sito non patchato che sembra appena distribuito. Controlla il risultato della build da solo e verifica con php -v dopo.

Due piccole note. Etichettate la vecchia immagine prima di ricostruirla, perché un'immagine mantiene la sua etichetta e offre un punto di ripristino gratuito, molto più economico di uno snapshot. Inoltre, non aspettatevi che un aggiornamento dell'immagine aggiorni l'applicazione: il punto di ingresso ufficiale delle immagini di WordPress copia i file principali solo quando la directory principale è vuota, quindi ricreare un container su un'immagine più recente lascia l'installazione esistente esattamente dov'era. Abbiamo verificato questo su una copia di staging prima di passare alla produzione e la versione di WordPress non è cambiata.

Perché disabilitare session.upload_progress copre solo metà del problema

La mitigazione PHP2Shell che circola per le macchine che non possono essere patchate è impostare session.upload_progress.enabled = 0, e su DSM che si trova in Web Station sotto Impostazioni linguaggio script, nella scheda Core del profilo PHP. Vale la pena farlo. Non è una soluzione definitiva e il divario è importante.

Il percorso di caricamento della sessione è solo uno dei modi per accedere alla vulnerabilità. La variante di divulgazione della memoria viene raggiunta tramite la normale gestione delle richieste multipart e non richiede affatto la funzionalità di sessione, quindi disattivandola si lascia aperta quella via. Il progetto PHP ha dichiarato esplicitamente che non esistono soluzioni complete e che l'aggiornamento è l'unica soluzione sicura. Imunify360 segnala che attualmente nessuna regola blocca il percorso di accesso alla memoria insufficiente di CVE-2026-109618, ed Elastic osserva che l'impostazione di caricamento chiude i percorsi di sessione confermati, ma non tutte le varianti.

Vedrai anche limite_memoria = -1 È stato suggerito, sulla base della logica che il bug si verifica a causa di una condizione di memoria insufficiente. Consideratelo un compromesso, non una vittoria. Rimuovere il limite su un server web pubblico trasforma una modalità di errore in un'altra, e su un NAS con un budget di memoria condivisa induce il pool di processi a saturare l'intera macchina.

Il filtro edge è il livello PHP2Shell che apporta un reale valore aggiunto, perché intercetta il traffico decrittografato, cosa che il router non può fare. Cloudflare ha implementato la protezione tramite regole gestite per PHP2Shell, AWS ha aggiunto la copertura per CVE-2026-109619 nella versione 2.3 del suo gruppo di regole gestite per PHP e Azure Front Door ha rilasciato la regola 99006001, disabilitata per impostazione predefinita. Su GitHub sono presenti regole della community per Snort e Suricata, ma al momento della stesura di questo testo non erano ancora stati pubblicati set di regole ufficiali per Snort e Emerging Threats, quindi una funzionalità di prevenzione delle intrusioni del NAS non sarà di aiuto in questo caso. In ogni caso, non può leggere all'interno di TLS.

Quale produttore di NAS ha effettivamente spedito una soluzione?

Questa è la parte della storia di PHP2Shell che dovrebbe influenzare la vostra decisione di acquisto. PHP upstream è stato rilasciato il 21 ottobre. Ecco la situazione dei quattro principali produttori di NAS per consumatori e professionisti il giorno successivo, secondo quanto riportato dalle loro pagine informative e non da articoli di stampa.

Fornitore	Consultivo	Stato	Versioni corrette pubblicate
Synology	Synology-SA-26:14, 22 ottobre 2026	Risolto	Sì. Tutte le versioni da PHP 7.4 a 8.4, oltre a Calendar e Mail Station.
QNAP	QSA-26-18, 22 ottobre 2026	Fissaggio	No. Su ogni riga c'è scritto "Da annunciare"
ASUSTOR	Dismissione di Legacy PHP, 22 ottobre 2026	Pensione, non una toppa	No. PHP 7, 7.3, 7.4 e 8.1 rimossi da App Central
UGREEN	Nessun risultato trovato	Sconosciuto	Nessun avviso rilevato per UGOS Pro

Synology ha pubblicato una tabella completa delle versioni di PHP2Shell lo stesso giorno dell'avviso, contrassegnandolo come Risolto. Un proprietario di DSM che lo ha letto ha potuto eseguire un'azione nel pomeriggio: aprire il Centro pacchetti, fare clic su Aggiorna e verificare. Questo è l'intero percorso di risoluzione, ed è per questo che le nostre macchine Web Station sono state aggiornate in pochi minuti anziché in giorni.

QNAP ha pubblicato un avviso nella stessa data, elencando una lunga serie di prodotti interessati, tra cui QTS 6.1.0, QTS 5.2.11 e versioni precedenti, QuTS hero h6.1.0, h6.0.x e h5.2.11 e versioni precedenti, QuTScloud c5.2.9 e versioni precedenti, Note Station 3, QNE ADRA, QVR Surveillance su modelli ARM32 e TVR OS. Ognuno di essi mostra lo stato "In fase di correzione" senza una versione di correzione. Poiché il runtime PHP fa parte dei componenti web di QTS, non esiste un pacchetto da aggiornare, quindi la correzione deve essere implementata tramite firmware.

Nel frattempo, QNAP offre alle vittime di PHP2Shell un elenco di misure di mitigazione, che vale la pena leggere attentamente per via di ciò che richiede: disabilitare il port forwarding del router e UPnP, rimuovere la pubblicazione dei servizi myQNAPcloud, spostare l'accesso remoto dietro una VPN, limitare le porte di gestione alle sottoreti attendibili, interrompere le applicazioni basate su PHP non necessarie, disabilitare il server web integrato se non utilizzato e controllare QuLog Center per individuare eventuali segni di compromissione. Si tratta di consigli validi per un dispositivo non aggiornato. Per chiunque ospiti un sito web pubblico, è anche una richiesta di disattivare il sito.

ASUSTOR ha intrapreso una terza strada. Il suo avviso, datato 22 ottobre e intitolato "Annuncio di ritiro di PHP legacy", rimuove PHP 7, PHP 7.3, PHP 7.4 e PHP 8.1 da App Central con effetto immediato, raccomanda di eseguire il backup dei dati importanti e invita gli utenti a utilizzare d'ora in poi solo PHP 8.3 o 8.4. La motivazione è difendibile, poiché gli sviluppatori originali rilasciano patch solo per la versione 8.2 e successive. L'effetto per chi utilizza una vecchia applicazione PHP è che il runtime scompare dallo store anziché essere corretto, e ASUSTOR non dichiara di aver rilasciato una build corretta di PHP 8.3 o 8.4. Si noti il contrasto con Synology, che ha pubblicato una build corretta di PHP 7.4, la 7.4.33-0131, proprio per gli utenti a cui ASUSTOR sta chiedendo di migrare.

Per UGREEN non siamo riusciti a trovare alcun avviso di sicurezza relativo a PHP2Shell per UGOS Pro. L'assenza di una dichiarazione pubblica non è di per sé prova che un prodotto sia vulnerabile, e UGOS Pro potrebbe semplicemente non includere un runtime PHP per il web. Tuttavia, se sei il proprietario, il silenzio non è una risposta su cui basare le tue azioni, e rappresenta di per sé una forma di esposizione al rischio.

Niente di tutto ciò rende Synology perfetto. Non risolverà i problemi di PHP 7.3, segnala DSM 7.2 come non più supportato e il suo componente PHP interno è ancora in fase di pianificazione anziché essere corretto. Il punto è più specifico e utile di una questione di brand: il giorno in cui un bug di esecuzione di codice remoto senza autenticazione è comparso nel motore PHP, un fornitore ha trasformato la correzione in un pulsante nel Centro pacchetti, mentre gli altri l'hanno trasformata in una lunga attesa.

Dove trovare ulteriori risorse ufficiali

Al momento della stesura di questo articolo, PHP2Shell ha solo due giorni di vita e la situazione è in continua evoluzione, quindi è consigliabile consultare fonti primarie piuttosto che riassunti. Non sono ancora disponibili video ufficiali da parte dei fornitori, pertanto l'elenco seguente si basa su documentazione e non su tutorial.

• Synology-SA-26:14 Questa è la tabella delle versioni autorevoli. Controllala di nuovo prima di applicare la patch, perché gli avvisi vengono rivisti.
• La dichiarazione Synology PSIRT Elenca i pacchetti interessati e spiega il componente interno di DSM e l'eccezione relativa a Mail Station.
• Gli avvisi GitHub upstream GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp sono collegati all'avviso Synology e descrivono il comportamento del motore piuttosto che il packaging del fornitore.
• QNAP QSA-26-18 È qui che apparirà la versione fissa del firmware se si utilizza QTS o QuTS hero. È la pagina da tenere d'occhio, non un articolo di notizie.
• Il tuo Centro pacchetti è l'ultima parola su ciò che è installato. L'avviso ti dice la build di destinazione, il riquadro ti dice cosa hai effettivamente e solo php -v ti dice cosa è in esecuzione.

Per informazioni di base sull'esecuzione di siti pubblici su macchine virtuali Synology, consultare la nostra guida su spostamento di uno stack Docker tra guest VDSM copre le abitudini di snapshot e rollback che hanno reso possibile la sopravvivenza a questa emergenza.

Limiti e note di sicurezza di PHP2Shell

Applicare patch a PHP2Shell è semplice su DSM, ma ingannevole altrove, quindi è bene chiarire alcuni limiti prima di considerare il lavoro concluso.

L'aggiornamento del pacchetto PHP2Shell non equivale a un audit del sito. L'aggiornamento di PHP chiude la falla da quel momento in poi, ma se il server era raggiungibile da Internet tra il 20 e il 22 ottobre, lo era mentre era pubblico un exploit funzionante. Controlla i log per individuare un volume di richieste POST inaspettato, cerca file apparsi in directory scrivibili e ruota le credenziali che un operatore PHP potrebbe aver utilizzato. La variante di divulgazione della memoria rende la rotazione delle credenziali una precauzione ragionevole piuttosto che una paranoia.

La verifica di PHP2Shell deve essere indirizzata all'interprete in esecuzione. Dashboard, log di build e intestazioni di risposta ci hanno deluso almeno una volta durante questo round. Una CDN può rimuovere l'intestazione che avrebbe indicato la versione, una build può segnalare il successo riutilizzando un livello memorizzato nella cache e un riquadro del pacchetto può mostrare la versione corrente mentre un vecchio worker è ancora in esecuzione. Solo php -v all'interno della cosa che gestisce le richieste lo risolve.

I container non sono coperti da alcun avviso di sicurezza PHP2Shell fornito dai produttori. Vale la pena ripeterlo perché è il più comune falso senso di sicurezza su un NAS. Se il tuo sito è in esecuzione su Container Manager, il fatto che Package Center segnali che tutto è aggiornato non ti dice nulla sul tuo sito. Lo stesso vale per qualsiasi applicazione di terze parti che includa il proprio runtime.

Le soluzioni di mitigazione basate sulla configurazione sono per definizione parziali. Disabilitare l'avanzamento del caricamento della sessione è utile, la rimozione del limite di memoria sostituisce un rischio con un altro e la funzionalità di prevenzione delle intrusioni di un router non può ispezionare il traffico TLS che termina altrove. Considerate tutto ciò come tempo guadagnato mentre predisponete una patch definitiva, non come un sostituto di essa.

Le versioni di runtime obsolete non hanno alcun percorso PHP2Shell. PHP 7.3 e versioni precedenti non hanno ricevuto alcun aggiornamento né dal progetto principale né da Synology. Se un sito necessita effettivamente di una versione non supportata, la scelta da fare è tra migrazione, isolamento o rimozione da Internet. Non esiste una quarta opzione, e fingere il contrario significa che un sito legacy diventa la porta d'accesso a tutto il resto sulla stessa infrastruttura.

Infine, è consigliabile prestare attenzione agli avvisi piuttosto che al ciclo di notizie. Synology ha contrassegnato SA-26:14 come risolto e lo ha revisionato una volta entro sei minuti dalla pubblicazione. QNAP ha affermato che QSA-26-18 verrà aggiornato non appena saranno disponibili versioni corrette. Entrambe le pagine subiranno modifiche e i numeri di versione in questo articolo sono quelli pubblicati il 22 ottobre 2026.

Riferimenti

• Synology-SA-26:14 Avviso di sicurezza PHP2Shell, Pubblicato il 22 ottobre 2026, stato Risolto, con versioni corrette per PHP dalla 7.4 alla 8.4.
• Dichiarazione di Synology sulle vulnerabilità di PHP2Shell, la nota PSIRT elenca i pacchetti interessati e la copertura DSM.
• QNAP QSA-26-18, Stato: In fase di risoluzione, prodotti interessati elencati con versioni corrette. Da annunciare.
• Annuncio del ritiro di ASUSTOR Legacy PHP, rimuovendo PHP 7, 7.3, 7.4 e 8.1 da App Central.
• Help Net Security sulle versioni upstream di PHP2Shell, che copre PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 e i backport solo sorgente per i rami più vecchi.

Domande frequenti