In breve: chi gestisce da sé un root server o un vServer deve anche metterlo in sicurezza da sé dopo PHP2Shell: portare i pacchetti PHP a uno stato corretto, riavviare tutti i processi PHP e verificare il risultato. Il gestore del data center di norma si occupa solo di hardware, virtualizzazione e rete. Poi vale la pena rafforzare il server in modo duraturo.
La Sua responsabilità con un server proprio
Con un root server o un vServer non gestito affitta potenza di calcolo, non assistenza. Sistema operativo, web server, PHP, database, firewall, backup e monitoraggio sono nelle Sue mani. Per direzione e titolari significa: se nessuno in azienda o presso un fornitore di servizi si è assunto espressamente questi compiti, non li svolge nessuno.
PHP2Shell lo rende visibile. Le due vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano in PHP stesso e consentono l'esecuzione di codice senza autenticazione. Il 21/10/2026 il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda l'aggiornamento immediato e, se non è possibile, di scollegare temporaneamente dalla rete il web server.
Mettere in sicurezza un vServer: verificare inventario e stato dei pacchetti
Per prima cosa si faccia un quadro di quali versioni di PHP sono installate e da quale fonte provengono. Molti server usano, oltre ai pacchetti della distribuzione, fonti di pacchetti aggiuntive. I comandi seguenti leggono soltanto. I nomi dei pacchetti sono esempi.
# Debian/Ubuntu: pacchetti PHP installati e relativa provenienza
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Quali binari PHP esistono in tutto?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Il solo numero di versione non basta. Le distribuzioni spesso forniscono le correzioni di sicurezza come backport e il numero mostrato resta più vecchio. A decidere è il changelog del pacchetto.
# Debian/Ubuntu (nome del pacchetto a titolo di esempio)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# Famiglia RHEL (nome del pacchetto a titolo di esempio)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Un'istruzione dettagliata si trova alla pagina Verificare versione e stato della patch di PHP.
Installare l'aggiornamento e rinnovare tutti i processi
Installi gli aggiornamenti tramite la gestione dei pacchetti e poi riavvii ogni servizio che carica PHP. A seconda della struttura sono PHP-FPM, Apache con mod_php, LiteSpeed o un application server. I nuovi file sul disco non bastano finché in memoria girano vecchi processi.
# Trovare i servizi con PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Mostrare i processi con l'orario di avvio
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: riconoscere programmi con librerie obsolete (se installato)
needrestart -r l
Ogni processo rilevante dovrebbe essere stato avviato dopo l'aggiornamento. Utile sui sistemi Debian è lo strumento needrestart, che mostra i servizi con librerie obsolete. I dettagli sul riavvio sono descritti alla pagina Riavviare PHP-FPM e tutti i worker.
Una patch non rimuove il malware introdotto prima dell'aggiornamento. Conservi i log del web server a partire dal 20/10/2026 e verifichi la presenza di tracce sul server prima di classificarlo come pulito.
Per una prima ricerca di tracce si prestano alcuni controlli che non modificano nulla. Cerchi file PHP creati o modificati dal 17/10/2026 nelle directory web, voci sconosciute nei crontab di tutti gli utenti, nuovi utenti di sistema e chiavi SSH, nonché processi dell'utente del web server che mantengono connessioni in uscita.
# File PHP modificati dal 17/10/2026 (percorso a titolo di esempio)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Connessioni di rete con il processo corrispondente
ss -tupn
Nessuno di questi controlli prova da solo un'intrusione, e un risultato vuoto non prova il contrario. Mostrano però se serve un'indagine più approfondita. Lavori su copie dei log e non modifichi i file sospetti finché lo stato non è stato salvato. In caso di riscontri, la via sicura è un'indagine ordinata. In questo caso non spenga semplicemente il server e non lo reinstalli subito, perché si perdono tracce importanti per la valutazione degli obblighi di notifica e per un'eventuale denuncia.
Rafforzare il server in modo duraturo
Dopo la patch d'emergenza segue la messa in sicurezza di base. Non impedisce ogni vulnerabilità, ma limita il danno e accorcia i tempi di reazione la prossima volta. Si sono dimostrati validi questi punti:
- Accessi: SSH solo con chiave, nessun accesso diretto come root, interfacce di amministrazione raggiungibili solo da reti note.
- Firewall: aprire solo le porte realmente necessarie, limitare le connessioni in uscita del web server.
- Configurazione di PHP: disattivare le funzioni pericolose,
open_basedirper ogni sito, pool e utenti separati per ogni applicazione. - Permessi dei file: il web server non deve poter scrivere sul codice del programma, le directory di upload non eseguono PHP.
- Aggiornamenti: installare automaticamente gli aggiornamenti di sicurezza, pianificare in modo fisso riavvio e controllo.
- Backup: copie secondo la regola 3-2-1, almeno una copia al di fuori del server e protetta da modifiche.
- Registri: raccogliere i log in modo centralizzato e conservarli abbastanza a lungo.
Com'è fatto un backup affidabile è descritto alla pagina Backup secondo la regola 3-2-1. Come cornice per le aziende è adatto l'IT-Grundschutz del BSI.
Quando un managed server è la scelta migliore
Un server proprio conviene se qualcuno ne assicura la cura in modo affidabile: seguire gli aggiornamenti, valutare situazioni come PHP2Shell, poter reagire di notte. Se manca questa capacità, ha senso o un managed server o un contratto di manutenzione fisso. In entrambi i casi è importante mettere per iscritto le competenze. Maggiori informazioni alla pagina Managed server: chiarire le responsabilità.
Come aiuta concretamente PHP SOS?
- Rileviamo tutte le installazioni di PHP, le fonti dei pacchetti e i servizi del Suo server e valutiamo lo stato effettivo della patch.
- Installiamo gli aggiornamenti, riavviamo tutti i processi e documentiamo il risultato.
- Verifichiamo il server alla ricerca di tracce di compromissione e salviamo i log per una successiva analisi.
- Nell'ambito del nostro hardening dei server configuriamo correttamente accessi, firewall, pool PHP e permessi.
- Su richiesta ci occupiamo della manutenzione continuativa tramite un contratto di manutenzione della sicurezza.
Domande frequenti
Il mio data center aggiorna automaticamente il vServer?
Di norma no, nel caso di root server e vServer non gestiti. Il fornitore mette a disposizione hardware o virtualizzazione e rete, mentre il sistema operativo e tutti i servizi che vi girano li gestisce Lei. In caso di dubbio verifichi il Suo contratto.
Bastano gli aggiornamenti di sicurezza automatici?
Aiutano, ma non sostituiscono il controllo. Gli aggiornamenti automatici non sempre riavviano i processi PHP in esecuzione e spesso non coprono i pacchetti provenienti da fonti esterne. Dopo ogni aggiornamento di sicurezza verifichi lo stato dei pacchetti e gli orari di avvio dei processi.
Come scopro se il mio pacchetto contiene un backport?
Nel changelog del pacchetto e nei bollettini di sicurezza della Sua distribuzione. Se vi compare il numero CVE, la correzione è inclusa, anche se il numero di versione sembra più vecchio. Se manca la voce, chiarisca lo stato prima di classificare il server come aggiornato.
Che cosa faccio se per la mia versione di PHP non arriva alcuna patch?
Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali. Applichi le misure transitorie secondo php.net, pianifichi rapidamente il passaggio a una versione supportata e, se necessario, secondo la raccomandazione del BSI scolleghi temporaneamente il server dalla rete.