In breve: se dopo l'aggiornamento php -v mostra la stessa versione, di solito dipende da un backport: la distribuzione recepisce solo la correzione di sicurezza nella propria versione PHP esistente, il numero resta lo stesso. Ubuntu 24.04 segnala così ancora 8.3.6, benché il pacchetto sia corretto contro PHP2Shell. Chiarisca la questione tramite stato del pacchetto e changelog, e verifichi inoltre che il sito giri davvero con il nuovo codice.
Un momento tipico dopo PHP2Shell
L'admin ha installato l'aggiornamento, tutto senza errori. Per controllo digita php -v e vede la stessa versione di prima. L'aggiornamento non ha funzionato? Il server è ancora aperto? Questa domanda è tra le più frequenti dal 21 ottobre 2026.
La buona notizia: nella maggior parte dei casi è tutto a posto. La cattiva: ci sono anche casi in cui lo stesso numero indica effettivamente un problema. Questo articolo aiuta a distinguere le due situazioni.
Perché le distribuzioni non cambiano il numero
Le distribuzioni aziendali e LTS promettono stabilità. All'interno di un rilascio, comportamento e interfacce dovrebbero cambiare il meno possibile. Un salto da PHP 8.3.6 a 8.3.36 porterebbe però numerose correzioni di errori e piccole modifiche di comportamento che potrebbero disturbare le applicazioni.
Per questo molti manutentori di pacchetti recepiscono solo la concreta correzione di sicurezza nella loro versione esistente. Questo procedimento si chiama backport. La versione upstream, che PHP stesso segnala con php -v, resta uguale. Ciò che cambia è lo stato del pacchetto, assegnato dalla distribuzione.
Nell'esempio di Ubuntu 24.04 si presenta così: PHP segnala 8.3.6. Lo stato corretto del pacchetto è però, secondo USN-8948-1, 8.3.6-0ubuntu0.24.04.13. Conta la parte finale. Debian con PHP2Shell ha deciso diversamente e per bookworm e trixie ha distribuito le nuove versioni upstream 8.2.35 e 8.4.27. La panoramica per rilascio è nell'articolo Debian e Ubuntu: il mio pacchetto PHP è aggiornato?.
Vale la pena scomporre una volta una versione di pacchetto del genere. Nell'esempio 8.3.6-0ubuntu0.24.04.13: la parte prima del trattino è la versione upstream, cioè ciò che PHP stesso segnala. Dopo segue la revisione della distribuzione. ubuntu0.24.04 rimanda al rilascio, l'ultimo numero conta le revisioni. Ogni correzione di sicurezza aumenta questo numero. Con Ubuntu Pro compare in aggiunta un suffisso come +esm5, con gli aggiornamenti di sicurezza di Debian uno come ~deb12u1. Chi sa leggere queste parti riconosce a colpo d'occhio se un pacchetto sia stato modificato dopo una segnalazione di sicurezza.
Dove compare ovunque il vecchio numero
Il numero invariato compare non solo in php -v. Si trova anche in punti visibili dall'esterno o analizzati da strumenti:
| Luogo | Che cosa vi compare | Conseguenza |
|---|---|---|
php -v e php -i |
versione upstream, data di build | gli admin dubitano dell'aggiornamento |
| pagina phpinfo | versione upstream | stesso effetto nel browser |
header X-Powered-By |
versione upstream, se expose_php è attivo |
gli scanner esterni segnalano una vulnerabilità |
| pannelli di hosting come Plesk | versione upstream | visualizzazione ad esempio di 8.2.34 nonostante la patch |
| scanner di vulnerabilità | confronto per numero | falso allarme con i backport |
Gli scanner esterni sono un caso a parte. Chi li usa può ricevere dopo PHP2Shell rilievi per server corretti da tempo. Non ignori questi rilievi in blocco, ma documenti per ogni server lo stato del pacchetto e annoti il rilievo come verificato. Un ulteriore motivo per nascondere all'esterno le indicazioni di versione è nell'articolo expose_php e header del server.
Quando lo stesso numero è un segnale d'allarme
Ci sono tre situazioni in cui il numero invariato indica effettivamente un problema:
- La fonte dei pacchetti fornisce la versione upstream. Se PHP proviene da una fonte che normalmente distribuisce la versione upstream attuale, come Debian con PHP2Shell o fonti di terze parti come Remi e sury.org, dopo l'aggiornamento dovrebbe comparire 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Se vi compare ancora il vecchio numero, il pacchetto non è stato aggiornato.
- Sta verificando l'installazione sbagliata.
php -vmostra la riga di comando. Se il sito gira con un'altra versione, ad esempio da un pannello di hosting o da una Software Collection, l'output non dice nulla sul sito. - Lo stato del pacchetto non è cambiato. Se anche lo stato del pacchetto è lo stesso di prima dell'aggiornamento, l'aggiornamento per questo pacchetto non è arrivato, ad esempio perché era bloccato o manca la fonte.
Per i non tecnici si può riassumere così: il numero di versione descrive il modello, lo stato del pacchetto lo stato di manutenzione. Due server con la stessa versione di PHP possono differire nettamente in sicurezza. Non chieda quindi al Suo IT o al Suo fornitore di servizi la versione, ma la prova della patch.
Come chiarire la questione in cinque minuti
I comandi seguenti sono di sola lettura. Gli esempi partono da Ubuntu o Debian e PHP 8.3; sui sistemi RHEL usi rpm -q invece di dpkg-query.
# 1. Che cosa segnala PHP stesso, compresa la data di build?
php -v
# 2. Quale stato del pacchetto è installato, da quale fonte?
apt policy php8.3-fpm
# 3. Il changelog contiene i numeri CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Da quando girano i processi PHP del sito?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
La data di build nell'output di php -v è un indizio, ma non una prova. La prova affidabile la fornisce la voce del changelog. Come trovarla e conservarla, se è formulata diversamente o manca, lo descrive l'articolo Documentare i numeri CVE nel changelog del pacchetto.
Dopo ogni verifica annoti entrambi i numeri: la versione upstream da php -v e lo stato del pacchetto. Chi in seguito chiede perché il server abbia «ancora 8.3.6» riceve così una risposta chiara.
La verifica generale tramite versione, pacchetto e processi la riassume la pagina Verificare correttamente versione e stato della patch di PHP.
Come aiuta concretamente PHP SOS?
- Chiariamo per ogni server se un numero di versione invariato sia un backport o un aggiornamento mancante.
- Valutiamo i rilievi degli scanner di vulnerabilità e documentiamo i falsi allarmi con stato del pacchetto e changelog.
- Verifichiamo quale installazione PHP il sito usi effettivamente e se i suoi processi siano stati riavviati.
- Nel servizio patch PHP documentiamo affiancati versione upstream e stato del pacchetto.
Domande frequenti
Il mio server è privo di patch se php -v mostra il vecchio numero?
Non necessariamente. Molte distribuzioni recepiscono le correzioni come backport nella versione esistente. Ubuntu 24.04 mostra ad esempio ancora 8.3.6, benché il pacchetto sia corretto secondo USN-8948-1. Decisivi sono lo stato del pacchetto e il changelog.
Perché il mio scanner di sicurezza segnala una vulnerabilità nonostante l'aggiornamento?
Molti scanner leggono solo il numero di versione, ad esempio dall'header X-Powered-By. Con i backport ciò porta a falsi allarmi. Verifichi lo stato del pacchetto e documenti il risultato, invece di ignorare semplicemente il rilievo.
Può succedere che php -v mostri un numero nuovo, ma il sito no?
Sì. php -v mostra la riga di comando. Il sito può girare tramite un'altra installazione o tramite processi avviati prima dell'aggiornamento. Verifichi quindi anche il servizio FPM o Apache e il loro orario di avvio.
La data di build nell'output di php -v aiuta?
È un indizio, ma non una prova. Una data di build successiva al 21 ottobre 2026 è coerente con un pacchetto corretto, ma non dimostra che la correzione sia contenuta. La voce del changelog è la prova migliore.