In breve: con unattended-upgrades su Debian e Ubuntu e dnf-automatic nella famiglia RHEL, i server Linux applicano da soli gli aggiornamenti di sicurezza. Perché un aggiornamento abbia effetto, i servizi interessati come PHP-FPM devono poi riavviarsi; lo verifichi con needrestart o con gli orari di avvio dei processi. Le fonti terze come sury.org vanno abilitate espressamente, container e cambi di versione principale l'automatismo non li copre.
Dalla patch al server: l'automatismo fa risparmiare tempo
Quando il 21 ottobre 2026 alle 16:00 ora tedesca php.net ha pubblicato le patch contro PHP2Shell, per gli amministratori è iniziata una corsa. Secondo i rapporti, le distribuzioni hanno consegnato i loro backport in parte lo stesso giorno. I server con aggiornamenti di sicurezza automatici hanno potuto installare i nuovi pacchetti alla successiva esecuzione pianificata, senza che nessuno dovesse intervenire.
Questa è la buona notizia. Quella meno buona: installato non significa efficace. Un servizio PHP-FPM che gira da settimane continua a lavorare con il vecchio codice in memoria finché non viene riavviato. E i pacchetti da fonti terze, i container o i pannelli di hosting con gestione PHP propria restano spesso intoccati dall'automatismo.
Questo articolo mostra come configurare gli aggiornamenti di sicurezza automatici e completarli in modo che nel momento critico proteggano davvero.
unattended-upgrades su Debian e Ubuntu
Su Ubuntu il pacchetto unattended-upgrades è installato per impostazione predefinita e applica gli aggiornamenti di sicurezza. Su Debian lo installa se serve. Viene controllato tramite due file in /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Il file 20auto-upgrades stabilisce se e con quale frequenza si aggiornano gli elenchi dei pacchetti e si applicano gli aggiornamenti. Il valore è il numero di giorni, "1" significa ogni giorno:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
In 50unattended-upgrades è indicato da quali fonti possano provenire gli aggiornamenti, se si riavvii dopo e chi riceva una notifica. Per impostazione predefinita sono abilitate solo le fonti di sicurezza ufficiali della distribuzione. Secondo la documentazione di Ubuntu non basta includere un ulteriore repository: deve comparire anche in questo elenco, altrimenti l'automatismo lo ignora. Riguarda ad esempio il repository di terze parti sury.org, che secondo i rapporti ha fornito build di PHP per tutti i rami dalla 5.6 alla 8.5. Lo sfondo è nell'articolo Il repository sury.org.
Se tutto è corretto lo mostra una prova che non modifica nulla:
sudo unattended-upgrade -v --dry-run
# Registri delle esecuzioni reali
ls -l /var/log/unattended-upgrades/
dnf-automatic su RHEL, AlmaLinux e Rocky Linux
Nella famiglia RHEL dnf-automatic svolge lo stesso compito. La configurazione si trova in /etc/dnf/automatic.conf. Secondo la documentazione, upgrade_type = security controlla solo gli aggiornamenti con avviso di sicurezza, e apply_updates per impostazione predefinita è disattivato.
# /etc/dnf/automatic.conf (estratto)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Oltre a dnf-automatic.timer, che segue il file di configurazione, esistono timer che si limitano a segnalare, a scaricare o a installare sempre. All'inizio il timer con file di configurazione è il più comprensibile.
La parte sottovalutata: riavviare i servizi
La gestione dei pacchetti sostituisce i file sul disco. I processi in esecuzione mantengono il vecchio codice in memoria. Con PHP significa: finché PHP-FPM o Apache con mod_php non sono riavviati, la falla resta aperta.
| Strumento | Sistema | Che cosa fa |
|---|---|---|
| needrestart | Debian, Ubuntu | riconosce i servizi con file obsoleti; su Ubuntu dalla 24.04 li riavvia per impostazione predefinita in automatico |
dnf needs-restarting -s |
famiglia RHEL | elenca i servizi che dovrebbero essere riavviati |
Automatic-Reboot |
unattended-upgrades | riavvia il server quando un aggiornamento lo richiede; per impostazione predefinita disattivato |
reboot |
dnf-automatic | never, when-changed o when-needed |
Secondo la documentazione di Ubuntu, i servizi esclusi da needrestart continuano a girare con i vecchi file fino al riavvio manuale. Dopo ogni aggiornamento di PHP verifichi quindi l'ora di avvio dei processi, come descritto in Riavviare PHP-FPM e tutti i worker.
Con i backport il numero di versione di PHP mostrato resta spesso lo stesso. La patch la dimostra tramite il changelog del pacchetto con i numeri CVE, ad esempio con apt-get changelog o rpm -q --changelog. Come si fa nel dettaglio lo mostra Debian e Ubuntu: il mio pacchetto PHP ha la patch?.
Che cosa l'automatismo non copre
Gli aggiornamenti automatici sono un tassello, non una gestione completa delle patch. Alcune aree richiedono procedure proprie:
- Container: il PHP nelle immagini Docker non viene aggiornato dagli aggiornamenti dell'host. Ricostruire le immagini, ricreare i container.
- Pannelli di hosting: Plesk, cPanel e pannelli simili gestiscono PHP in parte con pacchetti e meccanismi propri.
- Versioni principali: il passaggio, ad esempio, da PHP 8.2, che il 31/12/2026 raggiunge la fine del supporto, a una versione più recente non avviene in automatico.
- Applicazioni: CMS, plugin e dipendenze Composer hanno vie di aggiornamento proprie.
- Controllo: qualcuno deve leggere registri e messaggi di errore dell'automatismo. Un'esecuzione che fallisce in silenzio è peggio di nessuna, perché finge sicurezza.
Come queste parti si fondono in un processo lo descrive Gestione delle patch come processo invece che emergenza.
Conclusione: automatismo sì, fiducia cieca no
Gli aggiornamenti di sicurezza automatici appartengono a ogni server Linux raggiungibile da Internet. PHP2Shell ha mostrato quanto il tempo possa diventare scarso: secondo i media, un primo tentativo di attacco è stato osservato già il 17 ottobre, quattro giorni prima delle patch. Chi dopo aspetta ancora una finestra di manutenzione manuale perde tempo prezioso.
L'automatismo Le toglie però solo l'applicazione. Riavvio dei servizi, dimostrazione del livello di patch, container, pannelli e il tempestivo passaggio a versioni supportate restano compiti di cui qualcuno deve essere responsabile. Stabilisca per iscritto questa responsabilità e verifichi a campione se i registri dell'automatismo vengono davvero letti. Solo la combinazione di automatismo e controllo rende affidabili gli aggiornamenti.
Come aiuta PHP SOS in concreto?
- Configurare: configuriamo unattended-upgrades o dnf-automatic in modo adatto ai Suoi server, comprese le fonti terze abilitate.
- Mettere al sicuro i riavvii: configuriamo needrestart o verifiche equivalenti e dopo gli aggiornamenti di PHP controlliamo gli orari di avvio dei processi.
- Chiudere le lacune: inseriamo container, pannelli e cambi di versione principale in una procedura di manutenzione fissa.
- Controllare: nel contratto di manutenzione della sicurezza verifichiamo i registri dell'automatismo e segnaliamo le anomalie.
Domande frequenti
Gli aggiornamenti automatici sui server di produzione non sono troppo rischiosi?
Limitati agli aggiornamenti di sicurezza della distribuzione, il rischio è di solito minore di quello di una vulnerabilità aperta. Questi aggiornamenti non devono portare nuove funzioni, ma correggere errori. Per i sistemi critici servono anche backup, monitoraggio e un sistema di test.
unattended-upgrades riavvia PHP-FPM dopo un aggiornamento?
Non necessariamente da solo. Su Ubuntu, dalla versione 24.04, lo strumento needrestart riavvia in automatico per impostazione predefinita i servizi interessati, ma i servizi esclusi continuano a girare con i vecchi file. Dopo ogni aggiornamento di PHP verifichi l'ora di avvio di tutti i processi PHP.
I pacchetti di sury.org o di altre fonti terze vengono aggiornati automaticamente?
Solo se abilita espressamente la fonte. Secondo la documentazione di Ubuntu non basta aggiungere un repository; deve comparire anche nell'elenco delle origini consentite di unattended-upgrades.
L'automatismo porta anche PHP 8.2 a 8.3?
No. Gli aggiornamenti di sicurezza automatici restano all'interno delle versioni di pacchetto installate. Un cambio della versione principale di PHP, ad esempio prima della fine del supporto di PHP 8.2 il 31/12/2026, resta un progetto pianificato con test.
E i container Docker?
Gli aggiornamenti sull'host non aggiornano la versione di PHP nei container. Le immagini dei container vanno ricostruite o scaricate di nuovo e i container ricreati.