{"id":22083,"date":"2026-10-23T05:56:32","date_gmt":"2026-10-22T21:56:32","guid":{"rendered":"https:\/\/synopower.club\/?p=22083"},"modified":"2026-10-23T05:56:32","modified_gmt":"2026-10-22T21:56:32","slug":"synology-php2shell-emergency-patch","status":"publish","type":"post","link":"https:\/\/synopower.club\/it\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell su Synology: come abbiamo applicato le patch a sei siti in un solo giorno"},"content":{"rendered":"

PHP2Shell<\/strong> CVE-2026-109618 e CVE-2026-109619 sono due vulnerabilit\u00e0 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\u00e9 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 \u00e8 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.<\/p>\n\n\n\n

\n

Punto SynoPower Club:<\/strong>I nostri sei siti sono stati aggiornati entro un giorno lavorativo dalla pubblicazione dell'avviso di sicurezza PHP2Shell, e ci\u00f2 non \u00e8 stato possibile grazie a imprese eroiche, bens\u00ec grazie alla pubblicazione da parte di Synology di pacchetti corretti nella stessa data dell'avviso. Synology-SA-26:14 \u00e8 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\u00e9 applicarvi una patch. Se ospitate un sito web pubblico su un NAS, questa lacuna non \u00e8 un dettaglio di marketing. \u00c8 la differenza tra aggiornare un pacchetto e dover rimuovere il vostro sito da internet in attesa dell'aggiornamento.<\/p>\n<\/blockquote>\n\n\n\n

Cos'\u00e8 PHP2Shell e perch\u00e9 \u00e8 diverso<\/h2>\n\n\n\n

PHP2Shell non \u00e8 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()<\/code> 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 \u00e8 globale e sopravvive alla richiesta successiva gestita dallo stesso processo worker.<\/p>\n\n\n\n

CVE-2026-109618 riguarda la vulnerabilit\u00e0 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\u00e0 di tipo use-after-free: lo stato globale che punta alla memoria di richiesta liberata pu\u00f2 essere letto da una richiesta successiva sullo stesso worker, ed \u00e8 cos\u00ec che il bug si trasforma in esecuzione di codice o divulgazione di memoria.<\/p>\n\n\n\n

Due caratteristiche rendono PHP2Shell peggiore dei soliti avvisi PHP. In primo luogo, \u00e8 pre-autenticazione. Entrambe le vulnerabilit\u00e0 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.<\/p>\n\n\n\n

Le due vulnerabilit\u00e0 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.<\/p>\n\n\n\n

\"Synology-SA-26:14
Synology-SA-26:14, pubblicato il 22 ottobre 2026 alle 19:45 UTC+8 con stato Risolto.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell contro un normale exploit di WordPress<\/h2>\n\n\n\n

La maggior parte delle minacce che colpiscono un sito WordPress pubblico deriva da vulnerabilit\u00e0 dei plugin. Lo schema \u00e8 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.<\/p>\n\n\n\n

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

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

Come capire se il tuo NAS \u00e8 esposto<\/h2>\n\n\n\n

Valutare la propria esposizione a PHP2Shell inizia distinguendo due questioni distinte. Il sistema contiene una build PHP vulnerabile? E questa build \u00e8 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 \u00e8 minimo e la patch \u00e8 prevista per una versione successiva di DSM, in modo che le scansioni di vulnerabilit\u00e0 smettano di segnalarlo.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Controlla direttamente le versioni anzich\u00e9 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:<\/p>\n\n\n\n

# 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<\/code><\/pre>\n\n\n\n
Il motivo per insistere su php -v<\/code> Quando si effettua un audit per PHP2Shell, il problema \u00e8 che ogni segnale \u00e8 falso. L'output di compilazione pu\u00f2 segnalare un esito positivo pur riutilizzando un livello memorizzato nella cache, una dashboard pu\u00f2 mostrare un pacchetto come aggiornato quando il worker in esecuzione non lo \u00e8, e un'intestazione di risposta HTTP pu\u00f2 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.<\/p>\n\n\n\n
Applicazione di patch a PHP2Shell su Synology in 4 passaggi<\/h2>\n\n\n\n
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\u00ec il problema. Mail Station rappresenta un'eccezione documentata e richiede un aggiornamento manuale.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Consulta l'avviso<\/h3>\n
Apri il file Synology-SA-26:14 e prendi nota della versione corretta per ogni ramo di PHP che hai installato. Le versioni di destinazione sono 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 e 8.4.27-0051. PHP 7.3 non ha una correzione perch\u00e9 \u00e8 fuori supporto.<\/p>\n<\/div>\n<\/div>\n
\n
Aggiornamento tramite Centro pacchi<\/h3>\n
In DSM, apri Centro pacchetti e controlla la sezione Installati. Ogni pacchetto PHP vulnerabile mostrer\u00e0 "Aggiornamento disponibile" con la nuova versione online. Fai clic su "Aggiorna" per ogni ramo PHP elencato e aggiorna Synology Calendar e Mail Station, se li hai installati.<\/p>\n<\/div>\n<\/div>\n
\n
Lascia che i dipendenti riavviino<\/h3>\n
I pacchetti che dipendono da PHP si riavviano automaticamente al termine dell'aggiornamento del pacchetto PHP, ed \u00e8 proprio questo riavvio a rendere effettiva la correzione. Mail Station rappresenta un'eccezione e deve essere aggiornato manualmente tramite il Centro pacchetti.<\/p>\n<\/div>\n<\/div>\n
\n
Verificare l'interprete in esecuzione<\/h3>\n
Non fidarti della dashboard. Esegui il comando `php -v` sul percorso del pacchetto o all'interno del container e verifica che il numero di build corrisponda all'avviso. Quindi controlla che ogni host virtuale di Web Station sia associato a un profilo che hai effettivamente aggiornato.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Il
Il Centro pacchetti offre PHP 8.2.35-0171, la build indicata nell'avviso.<\/figcaption><\/figure>\n\n\n\n
Lo screenshot qui sopra proviene da una delle nostre macchine, scattato la mattina successiva all'avviso di PHP2Shell. Si noti che il pannello "Novit\u00e0" 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 \u00e8 esattamente la versione indicata nell'avviso.<\/p>\n\n\n\n
\"Synology
La finestra di dialogo di aggiornamento denominata PHP 8.2.35-0171, pubblicata da Synology Inc.<\/figcaption><\/figure>\n\n\n\n
Un errore comune di PHP2Shell che vale la pena segnalare agli utenti di Web Station: una macchina DSM pu\u00f2 avere installati contemporaneamente diversi rami di PHP e ogni host virtuale \u00e8 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.<\/p>\n\n\n\n
Quali pacchetti DSM sono interessati?<\/h2>\n\n\n\n
La dichiarazione relativa all'aggiornamento Synology di PHP2Shell \u00e8 pi\u00f9 circoscritta di quanto il panico abbia lasciato intendere. Sono interessati solo i sistemi che eseguono determinati pacchetti dipendenti da PHP, e Synology Drive non \u00e8 esplicitamente tra questi. IDrive \u00e8 presente nell'elenco, ma \u00e8 un software di terze parti.<\/p>\n\n\n\n