In breve: se il Suo pacchetto PHP su Debian o Ubuntu sia aggiornato contro PHP2Shell lo riconosce dallo stato esatto del pacchetto, non dalla versione di PHP. Il 21 ottobre 2026 Ubuntu ha pubblicato pacchetti corretti per tutti i rilasci supportati, quelli più vecchi tramite Ubuntu Pro. Debian ha corretto php8.2 in bookworm e php8.4 in trixie. Confronti lo stato installato con dpkg --compare-versions e riavvii poi tutti i servizi PHP.
La domanda dietro la domanda
«Il mio pacchetto PHP è aggiornato?» suona come una domanda da sì o no. In pratica la risposta dipende da tre cose: da quale fonte proviene il pacchetto, quale stato è installato e se quello stato sia anche in esecuzione? Questo articolo risponde ai primi due punti per i pacchetti ufficiali di Debian e Ubuntu. Come verificare in generale versione e processi in esecuzione è in Verificare correttamente versione e stato della patch di PHP.
Abbiamo consultato le indicazioni nelle segnalazioni di sicurezza ufficiali di Ubuntu e nel Debian Security Tracker il 25 ottobre 2026. Entrambi i CVE, CVE-2026-109618 e CVE-2026-109619, vi sono elencati con gli stessi stati corretti.
Stati dei pacchetti corretti su Ubuntu
Ubuntu ha pubblicato le correzioni con due segnalazioni. USN-8948-1 copre i rilasci attuali, USN-8948-2 quelli più vecchi, che ricevono aggiornamenti di sicurezza solo tramite Ubuntu Pro. Per 16.04 e 14.04 Ubuntu indica inoltre l'offerta Legacy Support.
| Rilascio Ubuntu | Pacchetto sorgente | Stato corretto |
|---|---|---|
| 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |
| 20.04 LTS (Ubuntu Pro) | php7.4 | 7.4.3-4ubuntu2.29+esm5 |
| 18.04 LTS (Ubuntu Pro) | php7.2 | 7.2.24-0ubuntu0.18.04.17+esm14 |
Colpisce che tutti gli stati mantengono la versione originale di PHP. Ubuntu 24.04 resta alla 8.3.6, benché la correzione sia stata ripresa dalla 8.3.36. Perché sia così e come gestirlo lo spiega l'articolo Perché php -v mostra lo stesso numero. Sono interessati, tra gli altri, i pacchetti binari per FPM, CLI, CGI e il modulo Apache, ad esempio php8.3-fpm e libapache2-mod-php8.3.
Stati dei pacchetti corretti su Debian
Debian qui segue un'altra strada e distribuisce le nuove versioni upstream. Secondo il Security Tracker lo stato è il seguente:
| Rilascio Debian | Pacchetto sorgente | Stato precedente | Stato corretto | Segnalazione |
|---|---|---|---|---|
| 12 bookworm | php8.2 | 8.2.32-1~deb12u1 | 8.2.35-1~deb12u1 | DLA-4848-1 |
| 13 trixie | php8.4 | 8.4.24-1~deb13u1 | 8.4.27-1~deb13u1 | DSA-6574-1 |
| forky, sid | php8.4 | 8.4.27-1 |
La segnalazione per bookworm è uscita come DLA, cioè tramite Debian LTS. Per php8.2 in unstable il tracker, al momento della consultazione, non riporta ancora uno stato corretto. Chi gestisce sistemi di test su unstable dovrebbe tenerlo d'occhio.
I rilasci Debian più vecchi nelle due voci CVE, al momento della consultazione, non compaiono. Se un server gira ancora su uno di tali rilasci, ad esempio Debian 11 con PHP 7.4, non può contare su un aggiornamento di sicurezza dall'archivio ufficiale. Restano allora tre strade: portare il sistema operativo a un rilascio supportato, usare un'offerta commerciale di supporto a lungo termine, la cui copertura per PHP2Shell si faccia confermare per iscritto, oppure mettere in sicurezza il server fino alla migrazione con misure transitorie e limitarne la raggiungibilità. A lungo termine regge solo la prima strada.
Come confrontare con precisione lo stato installato
Uno sguardo al numero di versione non basta, perché le versioni di Debian sono ordinate secondo regole proprie. dpkg --compare-versions confronta correttamente. I comandi seguenti sono di sola lettura; adatti nomi dei pacchetti e stato di destinazione al Suo rilascio.
# Stato installato e origine del pacchetto
apt policy php8.3-fpm
# Tutti i pacchetti PHP installati con versione
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
# Confronto esatto con lo stato corretto (esempio Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"
Nell'output di apt policy faccia attenzione alla riga con l'origine del pacchetto. Se non vi compare l'archivio di sicurezza della Sua distribuzione, ma ad esempio packages.sury.org o un PPA, le tabelle sopra non valgono. Conta allora lo stato di quella fonte di terze parti, che trattiamo nell'articolo Il repository sury.org.
In aggiunta vale la pena guardare il changelog fornito. Come vi si trovano i numeri CVE e come conservarli come prova lo descrive l'articolo Documentare i numeri CVE nel changelog del pacchetto.
Tipiche insidie nella verifica
Verificato un solo pacchetto: PHP è composto da molti pacchetti binari. Se php8.3-cli è aggiornato ma php8.3-fpm no, il sito resta aperto. Verifichi tutti i pacchetti di un ramo, in particolare FPM, CGI e il modulo Apache.
Pacchetto bloccato: i pacchetti fissati con apt-mark hold restano fermi durante l'aggiornamento. apt-mark showhold li mostra.
Ubuntu Pro non attivo: su 20.04 e precedenti le correzioni arrivano solo se Ubuntu Pro è configurato. Senza Pro il sistema resta vulnerabile nonostante l'esecuzione degli aggiornamenti.
Mirror obsoleto: se il server ottiene i pacchetti tramite un mirror o proxy interno, vede i nuovi aggiornamenti di sicurezza solo quando questo è aggiornato. Nel dubbio verifichi se apt update raggiunge davvero la fonte di sicurezza.
Riavvio dimenticato: i nuovi pacchetti hanno effetto solo dopo il riavvio di tutti i servizi che hanno caricato PHP. needrestart, se installato, mostra i servizi con codice obsoleto.
Uno stato corretto del pacchetto dimostra solo che la vulnerabilità è chiusa da ora. Non risponde alla domanda se il server sia stato attaccato in precedenza. Conservi i log dal 20 ottobre.
Come aiuta concretamente PHP SOS?
- Accertiamo per ogni server l'origine di tutti i pacchetti PHP e confrontiamo lo stato con le segnalazioni ufficiali.
- Installiamo gli aggiornamenti, anche tramite Ubuntu Pro, e riavviamo tutti i servizi interessati.
- Con il servizio patch PHP riceve per ogni server una prova con stato dei pacchetti, riscontro nel changelog e ora del riavvio.
- Sui sistemi con fonti di terze parti o versioni vecchie chiariamo quale strada porti a uno stato corretto documentabile.
Domande frequenti
Quale versione di Ubuntu contiene la correzione di PHP2Shell?
Secondo USN-8948-1, Ubuntu 22.04, 24.04, 26.04 e 26.10 sono servite con aggiornamenti regolari. Per 14.04, 16.04, 18.04 e 20.04 Ubuntu distribuisce le correzioni, secondo USN-8948-2, tramite Ubuntu Pro.
Perché Ubuntu 24.04 continua a mostrare PHP 8.3.6?
Ubuntu recepisce le correzioni di sicurezza come backport nella versione esistente. Il numero upstream resta 8.3.6, cambia solo lo stato del pacchetto. Secondo USN-8948-1 lo stato corretto è 8.3.6-0ubuntu0.24.04.13.
Debian 12 bookworm è ancora servita?
Sì. Secondo il Debian Security Tracker, per php8.2 in bookworm esiste lo stato corretto 8.2.35-1~deb12u1, annunciato come DLA-4848-1 nell'ambito di Debian LTS.
Vale anche per PHP dal repository sury?
No. I pacchetti da fonti di terze parti come sury.org hanno stati di versione e changelog propri. Le indicazioni di Debian e Ubuntu valgono solo per i loro pacchetti ufficiali.
Basta un apt upgrade?
Installa i nuovi pacchetti, ma i processi PHP-FPM o Apache in esecuzione mantengono in memoria il vecchio codice. Solo un riavvio di tutti i servizi che caricano PHP rende efficace la patch.