In breve: per verificare una CVE nel changelog, cerchi CVE-2026-109618 e CVE-2026-109619 nel registro delle modifiche del pacchetto PHP installato: su Debian e Ubuntu in /usr/share/doc/<paket>/changelog.Debian.gz, sui sistemi RPM con rpm -q --changelog. Una corrispondenza, insieme allo stato del pacchetto, al confronto con la segnalazione di sicurezza ufficiale e all'ora di riavvio, costituisce una prova solida. Una mancata corrispondenza non è ancora la prova di una vulnerabilità aperta.
Perché una prova è più di «abbiamo aggiornato»
Dopo PHP2Shell molti vogliono sapere se i loro server sono sicuri: la direzione, il responsabile della protezione dei dati, i clienti con trattamento dei dati per loro conto, a volte l'assicuratore cyber. «Abbiamo aggiornato» è troppo poco. Serve un documento che un terzo possa verificare.
Il numero di versione spesso non è adatto, perché le distribuzioni inseriscono le correzioni come backport e il numero resta lo stesso. Il changelog del pacchetto è la base migliore. Lo scrive il responsabile del pacchetto e, per gli aggiornamenti di sicurezza, di norma elenca i numeri CVE corretti.
Dove si trovano i changelog
Ogni formato di pacchetto ha il proprio percorso. La panoramica seguente aiuta a raggiungere rapidamente il punto giusto.
| Sistema | Posizione del changelog | Comando per la ricerca |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | Archivio dei pacchetti della distribuzione | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | Database dei pacchetti RPM | rpm -q --changelog <paket> |
| Immagini container | nell'immagine, come per il sistema di base | eseguire il comando nel container |
Su Debian e Ubuntu la directory della documentazione di alcuni pacchetti binari rimanda con un link simbolico a un pacchetto comune, ad esempio php8.3-common. Se zgrep non trova il file, guardi la directory con ls -l /usr/share/doc/ | grep php.
Verificare la CVE nel changelog: come procedere
I comandi seguenti sono di sola lettura. Adatti i nomi dei pacchetti alla Sua installazione.
# Debian/Ubuntu: in locale, senza rete
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: riga iniziale della voce più recente con stato del pacchetto e data
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Famiglia RHEL: voce con data e stato del pacchetto
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Su Debian e Ubuntu lo stato del pacchetto compare nella riga iniziale di ogni voce, la data nella riga finale. Con RPM entrambi si trovano nella riga sopra le voci. Così vede non solo se la CVE è citata, ma anche con quale stato del pacchetto. Confronti questo stato con quello installato, ad esempio con dpkg-query -W o rpm -q. Se coincidono, la correzione è contenuta nel pacchetto in uso.
Pacchetti dei pannelli e container
I pannelli di hosting portano con sé pacchetti PHP propri, ad esempio Plesk o cPanel. Anche questi sono normali pacchetti DEB o RPM e il loro changelog si legge con gli stessi strumenti. Se i fornitori vi citino i numeri CVE o solo la nuova versione di PHP varia da caso a caso. Se il pacchetto indica la versione upstream 8.5.12, 8.4.27, 8.3.36 o 8.2.35, basta come prova; per i backport con il vecchio numero serve l'informazione del fornitore.
Nei container la prova appartiene all'immagine, non all'host. Verifichi i pacchetti nell'immagine dalla quale è stato avviato il container in esecuzione e annoti inoltre il digest dell'immagine. In questo modo si potrà ricostruire in seguito quale stato girava davvero, anche se nel frattempo l'immagine con lo stesso tag è stata ricostruita.
Se la CVE manca nel changelog
Una voce assente può avere più cause. Le esamini in quest'ordine:
- Pacchetto sbagliato: con più rami PHP o più fonti su un server, la risposta si trova spesso nel changelog di un altro pacchetto.
- Versione upstream invece della CVE: se la fonte distribuisce la nuova versione upstream, ad esempio 8.4.27, nel changelog può comparire soltanto «New upstream version». In tal caso il numero di versione stesso è la prova, perché php.net indica le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 come corrette.
- Formulazione diversa: alcuni responsabili citano numeri di bug o identificativi di advisory come GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp al posto della CVE.
- Confronto con la segnalazione di sicurezza: se la segnalazione ufficiale della Sua distribuzione, ad esempio una USN o il Debian Security Tracker, indica uno stato del pacchetto corretto e questo, o uno più recente, è installato, anche questa è una prova. Per Debian e Ubuntu trova gli stati nell'articolo Il mio pacchetto PHP è aggiornato?, per la famiglia RHEL in RHEL, AlmaLinux e Rocky Linux.
- Chiedere al fornitore: per i pacchetti dei pannelli, le build dell'hoster o le fonti di terzi aiuta solo una risposta scritta. Un modello è offerto dalla guida Chiedere all'hoster lo stato della patch.
Se dopo questi passaggi non resta alcuna prova, consideri il server come non aggiornato e adotti misure transitorie finché la questione non è chiarita.
Dalla corrispondenza alla prova
Una corrispondenza nel changelog dimostra che il pacchetto contiene la correzione. Non dimostra che i processi in esecuzione la utilizzino. Una prova completa contiene quindi cinque informazioni per ogni server e installazione di PHP:
- server, ramo PHP e modalità di esecuzione, ad esempio PHP-FPM o mod_php
- stato del pacchetto installato e fonte del pacchetto
- riferimento nel changelog o rimando alla segnalazione di sicurezza ufficiale
- momento dell'aggiornamento e ora di avvio dei processi PHP in esecuzione
- nome della persona che ha eseguito la verifica e data del controllo
Salvi gli output grezzi dei comandi come file di testo accanto alla prova. Sono più facili da ricostruire in seguito rispetto a un riepilogo fatto a memoria.
Una prova risponde solo alla domanda se la vulnerabilità fosse chiusa a partire da un certo momento. Per il periodo precedente servono i log a partire dal 20 ottobre 2026 ed eventualmente una ricerca di tracce. Il procedimento generale della verifica della versione è descritto nella pagina Verificare correttamente versione e stato della patch di PHP.
Come aiuta concretamente PHP SOS?
- Cerchiamo nei changelog di tutti i pacchetti PHP dei Suoi server e li confrontiamo con le segnalazioni di sicurezza ufficiali.
- Dove i changelog tacciono, chiariamo lo stato con la distribuzione, il fornitore del pannello o l'hoster.
- Controlliamo che i processi in esecuzione siano stati riavviati dopo l'aggiornamento.
- Con il servizio di patch PHP riceve la prova per ogni server in una forma che può trasmettere a terzi.
Domande frequenti
Perché la versione di PHP non basta come prova?
Molte distribuzioni recepiscono le correzioni di sicurezza come backport, senza cambiare la versione di PHP. Il numero di versione, in questo caso, non dice nulla sulla patch. Il changelog del pacchetto installato, invece, riporta i numeri CVE corretti.
Cosa significa se la CVE manca nel changelog?
Può voler dire che la correzione manca. Ma può anche darsi che il responsabile del pacchetto abbia formulato diversamente, ad esempio con un numero di bug o la versione upstream. In tal caso confronti lo stato del pacchetto con la segnalazione di sicurezza ufficiale oppure chieda al fornitore.
Per quanto tempo devo conservare la prova?
Finché può essere rilevante per verifiche interne, assicuratori o possibili questioni di protezione dei dati. La archivi insieme ai log a partire dal 20 ottobre 2026. Le scadenze concrete le chiarisca con il responsabile della protezione dei dati o con la consulenza legale.
Posso controllare il changelog anche senza accesso a Internet?
Sì. Debian e Ubuntu conservano in locale il changelog di ogni pacchetto in /usr/share/doc, i sistemi RPM lo salvano nel database dei pacchetti. Entrambi si possono leggere senza rete.