Il 21 ottobre 2026 è uscita la correzione di una falla critica di PHP, già sfruttata negli attacchi. Sui nostri server l’abbiamo chiusa la sera dopo, con i passaggi raccontati nel tutorial su php2shell. Ma l’avviso ci era arrivato per email, quasi per caso: è andata bene, e non basta. Ecco le cinque abitudini con cui abbiamo fatto in modo che la prossima volta non dipenda dalla fortuna. Nessuna richiede strumenti a pagamento.

Cosa gira sul server

Davanti a un avviso di sicurezza la prima domanda è sempre la stessa: questo programma ce l’ho, e in che versione? Non si risponde a memoria.

Conta soprattutto quello che risponde da internet: il server web, PHP, le applicazioni (un sito WordPress, un CRM, una webmail), il pannello di gestione, la posta. Per ognuno annotiamo dove gira e il comando che ne legge la versione sul server.

Programma	Dove gira	Come si legge la versione
Server web (Apache)	tutti i siti	`apache2 -v`
PHP	ogni sito con la sua versione	`php8.3 -v`, e quale versione usa ciascun sito
WordPress	i siti	`wp core version`
Librerie di un’applicazione PHP	il progetto	`composer show vendor/pacchetto`
Pacchetti della distribuzione	il sistema	`apt-cache policy nome-pacchetto`

Scriverlo serve anche a scoprire cose. Verificando l’aggiornamento di PHP ci siamo accorti che non tutti i siti passavano da PHP-FPM: alcuni usavano ancora PHP in CGI, e il riavvio dei pool non li toccava. Ora la tabella lo dice, e la procedura lo controlla.

Gli avvisi, nel posto dove si lavora

Gli avvisi di sicurezza escono ogni giorno da fonti pubbliche e gratuite. Quelle che seguiamo:

il catalogo delle vulnerabilità sfruttate della CISA (Known Exploited Vulnerabilities): solo falle già usate negli attacchi, cioè le più urgenti;
i bollettini di sicurezza della distribuzione: per Debian i DSA e, per le versioni con supporto lungo, i DLA;
le pagine ufficiali dei programmi che usiamo, come PHP e WordPress;
una testata del settore, per avere il quadro.

Il punto non è quali fonti, ma dove arrivano. Un’email si perde tra le altre, un ticket si chiude senza leggerlo. Noi le facciamo arrivare in una pagina del pannello che apriamo ogni giorno per lavorare: le voci nuove restano in evidenza finché qualcuno non le segna come lette. Un filtro tiene solo quelle che nominano i programmi della tabella.

Il filtro sbaglia, e va messo in conto: «apache» prende anche Tomcat o Struts, progetti della stessa fondazione che con il server web non c’entrano; «php» prende qualunque prodotto scritto in PHP. Riconoscerli fa parte del lavoro.

Tre domande prima di agire

Per ogni avviso:

Il programma lo usiamo? Si guarda la tabella. Se no, si segna come letto e si va avanti.
La versione installata è tra quelle colpite? Si legge sul server, non si ricorda.
La correzione c’è già? Qui c’è la trappola.

Le distribuzioni come Debian non passano alla versione nuova di un programma: riportano la correzione sulla versione che distribuiscono, e il numero principale resta lo stesso. Un esempio reale: una webmail installata dalla distribuzione risulta alla versione 1.6.5 anche dopo la correzione di una falla che il progetto originale ha chiuso nella 1.6.11. Guardando solo il numero sembra vulnerabile, e non lo è. La risposta sta nel registro delle modifiche del pacchetto:

zcat /usr/share/doc/<pacchetto>/changelog.Debian.gz | grep -i CVE-AAAA-NNNNN
apt-cache policy <pacchetto> | head -3

Se il primo comando trova la CVE e il secondo mostra la versione installata uguale a quella disponibile, la falla è già chiusa. Per i programmi aggiornati da noi, come WordPress o le librerie di un’applicazione, vale invece il numero di versione: si confronta con quello indicato nell’avviso.

Il primo giorno ne abbiamo esaminati diciassette: nessuno richiedeva un intervento. Saperlo con certezza è diverso dallo sperarlo. L’esito si annota insieme al comando usato per verificarlo: quando lo stesso programma ricompare, si riparte da lì.

Prima si simula, poi si esegue

Quando un aggiornamento serve davvero, il metodo è quello del tutorial:

si aggiornano solo i pacchetti interessati, non tutto il sistema;
prima si fa una simulazione (dry run) e si legge cosa cambierebbe: se compare un pacchetto che non c’entra, o una rimozione, ci si ferma e si capisce perché;
si annotano le versioni installate, così il rollback (il ritorno alla versione precedente) è pronto prima di cominciare;
dopo il riavvio si verifica un sito alla volta, entrando nelle applicazioni: una pagina che risponde non è ancora una pagina giusta.

I controlli che girano di notte

Le fonti pubbliche dicono cosa succede nel mondo. Due controlli automatici dicono cosa manca sul proprio server:

i pacchetti in attesa di aggiornamento, contando a parte quelli che arrivano da repository esterni, che gli aggiornamenti automatici «solo sicurezza» saltano;
composer audit su ogni applicazione PHP, che confronta le librerie installate con gli avvisi pubblicati.

Devono avvisare solo quando qualcosa cambia: un controllo che segnala ogni giorno la stessa cosa smette presto di essere letto.

Poi va controllato il controllo. Un lavoro pianificato che si ferma non avvisa nessuno: si ferma e basta. Rivedendo i nostri abbiamo trovato lo scheduler di un’applicazione che girava ogni cinque minuti invece che ogni minuto, e buttava via i propri messaggi di errore: se si fosse fermato, nessuno lo avrebbe saputo. Ora gira ogni minuto, scrive i suoi messaggi in un registro e lascia un segnale a ogni passaggio; il pannello mostra quando è passato l’ultima volta.

La procedura completa che usiamo, con la simulazione, il rollback e i due controlli notturni pronti da installare, la mandiamo su richiesta. Se invece vi serve una mano a verificare un server, scriveteci.

La procedura è quella che usiamo sui nostri server, scritta come script bash da leggere riga per riga prima di usarli. Contiene la simulazione, che elenca cosa cambierebbe e si ferma se c’è altro oltre a PHP; l’aggiornamento dei soli pacchetti PHP, con le versioni precedenti annotate per il rollback; la verifica dei siti dopo il riavvio, un dominio alla volta; i due controlli notturni, pacchetti in attesa e composer audit, che avvisano solo quando qualcosa cambia; i parametri in un unico file, per usarla su un server diverso dal nostro. La condividiamo con chi gestisce server: raccontateci che sistema usate e ve la mandiamo noi.

Segui Precision Drone su LinkedIn

Il metodo in cinque regole

Si sa cosa gira sul server, con il comando che ne legge la versione: non si va a memoria.
Gli avvisi arrivano dove si lavora, non in una casella email.
Tre domande prima di agire: lo usiamo, la versione è colpita, la correzione c’è già. La risposta si legge sul server.
Prima la simulazione, poi il comando vero, con il rollback pronto.
I controlli automatici avvisano solo quando cambia qualcosa, e si verifica che girino davvero.

La sicurezza di un server non si misura il giorno dell’emergenza: si prepara tutti gli altri giorni.

Aggiornare un server senza dipendere dalla fortuna