Come verificare se le tue app self-hosted utilizzano una versione vulnerabile di PHP

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Conceptual guide: CHECK THE RUNNING PHP. Identify service; Inspect runtime; Verify vendor fix.

Un host può eseguire più versioni di PHP contemporaneamente. La versione restituita da una shell SSH può appartenere a uno strumento da riga di comando, mentre un sito pubblico usa un altro runtime. Per valutare le vulnerabilità PHP di ottobre 2026, associa ogni risultato della versione a un'applicazione e a un servizio effettivi.

Controlla l'ambiente che serve l'applicazione, non solo il PHP da riga di comando dell'host. Confronta il ramo runtime esatto o la revisione del pacchetto della distribuzione con l'avviso di sicurezza applicabile, tenendo conto dei backport documentati dal fornitore, e rimuovi eventuali pagine diagnostiche temporanee dopo il controllo.

1. Individua le applicazioni basate su PHP

Elenca le applicazioni, i metodi di installazione e i percorsi di accesso esterno. Consulta la documentazione dell'applicazione o i metadati del pacchetto per determinare se usa PHP. Includi i servizi accessori, come i processi cron e le code, se usano la stessa immagine dell'applicazione.

Non dedurre l'uso di PHP dalla marca del NAS. Un dispositivo che esegue un insieme di applicazioni richiede una valutazione per ogni servizio.

2. Esamina una distribuzione Compose

docker compose ps
docker compose images
docker compose exec -T app php -v
docker compose exec -T app php --ini

Esegui questi comandi dalla directory del progetto Compose previsto; sostituisci app con il servizio che contiene PHP. I comandi identificano i container attuali e interrogano il binario all'interno di quel servizio. Se PHP viene eseguito in un servizio php o fpm separato, esamina invece quel servizio.

L'assenza dell'eseguibile php non dimostra che l'applicazione sia sicura. Immagini minimali, percorsi binari alternativi o servizi runtime separati potrebbero richiedere il metodo di ispezione indicato dal manutentore. Non installare pacchetti in un container di produzione solo per completare il controllo della versione.

3. Esamina PHP installato sull'host

command -v php
php -v
php --ini

Questi comandi descrivono la versione di PHP della shell. Poi controlla la configurazione del server web e il gestore dei servizi per identificare il pool PHP-FPM, il modulo Apache o un altro gestore che serve il sito. Verifica la versione del pacchetto di quel componente e l'avviso di sicurezza del fornitore. La documentazione di PHP spiega che le posizioni e il comportamento della configurazione variano in base all'interfaccia del server.

Se una dashboard fornisce informazioni private sul runtime del servizio web effettivo, può integrare l’inventario. Non lasciare online una pagina pubblica phpinfo(); potrebbe rivelare dettagli non pertinenti al controllo.

4. Confronta le prove con l’avviso di sicurezza

Per l’incidente del 21 ottobre, le release di sicurezza upstream sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Una release successiva supportata dello stesso ramo può includere queste correzioni. Se una distribuzione applica patch di sicurezza retroportate, fai riferimento alla revisione del pacchetto e all’avviso di sicurezza, invece di approvare o rifiutare un pacchetto basandoti solo sul numero che sembra corrispondere a quello upstream.

Registra il risultato in uno di questi tre stati: correzione confermata, vulnerabilità confermata oppure irrisolto in attesa di prove dal fornitore. Per il software fuori supporto, pianifica un aggiornamento a una versione supportata o una correzione esplicita da parte di un fornitore che ne garantisca la manutenzione. Un risultato irrisolto deve rimanere visibile nell’elenco delle attività di manutenzione.

5. Verifica cosa succede dopo l’aggiornamento

Ripeti gli stessi controlli dopo la distribuzione, includendo worker e container separati. Registra l’identificativo dell’immagine o la revisione del pacchetto e lo stato del riavvio. Verifica una normale richiesta autenticata e le funzioni che la tua famiglia usa davvero.

Su un cloud personale ZimaCube 2, conserva questo registro insieme alla configurazione delle app e alle istruzioni per i backup. Il risultato utile è una dichiarazione verificabile come «questa applicazione usa questo runtime aggiornato», anziché «il NAS è stato aggiornato». Se trovi un container interessato, consulta la guida agli aggiornamenti collegata prima di modificare i volumi di dati.

Scopri ZimaCube 2 NAS cloud personale per la casa per configurare il tuo spazio di archiviazione privato e le tue applicazioni self-hosted. La sicurezza del software dipende dai servizi installati, dalla loro configurazione e dagli aggiornamenti verificati.

Continua la serie sulla sicurezza di PHP

Fonti e ambito

Verificato il 22 ottobre 2026. I consigli per la distribuzione devono essere adattati alla propria applicazione e alla documentazione del fornitore; questi articoli non attestano la presenza di vulnerabilità specifiche nei prodotti.