Dopo PHP2Shell: restare aggiornati è un’abitudine, non un’emergenza

23 Ott , 2026 - Notizie

Dopo PHP2Shell: restare aggiornati è un’abitudine, non un’emergenza

Il 21 ottobre 2026 il team di PHP ha rilasciato aggiornamenti d’emergenza per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, ribattezzate PHP2Shell: consentono di eseguire codice da remoto su un server vulnerabile senza autenticarsi (CVSS 9,2). Siti di istituzioni e aziende in diversi Paesi sono stati messi offline in attesa dell’aggiornamento. Il CSIRT Italia dell’ACN ha pubblicato l’avviso AL07/261021/CSIRT-ITA e lo ha aggiornato il 23 ottobre con una terza vulnerabilità, CVE-2026-115560, per la quale le correzioni sono ancora in arrivo. Qui non spieghiamo come installare la patch: gli avvisi ufficiali lo fanno meglio di noi. Vogliamo ragionare su cosa ci insegna questo episodio, perché la vera difesa è restare sempre aggiornati e sapere dove trovare le informazioni giuste prima che servano. Il sito di FinGreenTech è già aggiornato.

1. Cosa ci ha insegnato l’emergenza

  • Gli aggiornamenti non finiscono mai. Ogni versione ha un ciclo di vita: PHP 8.1 e le precedenti, per esempio, non ricevono più aggiornamenti ufficiali. Chi è rimasto su versioni non supportate si ritrova a dover chiedere interventi straordinari al fornitore o a cambiare versione in emergenza.
  • Chi è informato per primo agisce per primo. Il CERT-EU segnala che le prime dimostrazioni d’attacco circolavano a ridosso del rilascio: la finestra tra la correzione e lo sfruttamento può essere molto breve. Anche il CSIRT Italia segnala la disponibilità in rete di proof of concept per entrambe le vulnerabilità.
  • L’emergenza arriva senza preavviso. Secondo le società che li hanno scoperti, Calif e Wiz con il supporto dell’intelligenza artificiale, i difetti erano presenti da oltre dieci anni. Non si possono prevedere: si può solo essere pronti.

Un esempio concreto di quanto il quadro cambi in fretta: l’avviso del CSIRT Italia è stato aggiornato il 23 ottobre, due giorni dopo la prima pubblicazione, con una terza vulnerabilità (CVE-2026-115560) e con indicazioni di mitigazione in attesa delle correzioni. Chi aveva considerato chiusa la questione dopo la prima notizia poteva non saperlo.

L’ACN ricorda inoltre che aggiornare non basta: indipendentemente dall’aggiornamento raccomanda un’analisi retrospettiva dei log per individuare eventuali segnali di sfruttamento già avvenuto.

Cosa ci ha insegnato PHP2Shell: aggiornamenti continui, informarsi per primi, emergenze senza preavviso

2. Sapere dove guardare: i canali ufficiali

Aspettare che la notizia arrivi sui giornali, o che qualcuno ci avvisi, significa partire in ritardo. Conviene scegliere poche fonti ufficiali e consultarle periodicamente, non solo quando c’è un’emergenza:

  • ACN e CSIRT Italia: avvisi e bollettini in italiano sulle vulnerabilità, il primo riferimento per le imprese italiane. Per PHP2Shell ha pubblicato l’avviso AL07/261021/CSIRT-ITA.
  • CERT-AGID: bollettini e strumenti di verifica, pensati per le pubbliche amministrazioni ma utili a tutti.
  • ENISA: l’agenzia europea per la cybersicurezza. Il suo European Vulnerability Database (euvd.enisa.europa.eu) raccoglie vulnerabilità, misure di mitigazione e stato di sfruttamento.
  • CERT-EU: pubblica advisory molto tecnici; nasce per le istituzioni dell’Unione ed è un buon approfondimento, più che una fonte pensata per le PMI.

A questi si aggiungono gli annunci ufficiali dei produttori del software che usi, come php.net per PHP.

I canali ufficiali da consultare: ACN e CSIRT Italia, CERT-AGID, ENISA con EUVD, CERT-EU

3. Trasformarlo in una routine

Un’informazione utile serve solo se qualcuno la legge e ne trae conseguenze. Per questo in azienda funziona meglio una piccola organizzazione stabile:

  • una persona responsabile, che sa chi controlla i canali e a chi segnalare le novità;
  • una cadenza fissa, per esempio settimanale, e non solo quando la notizia fa rumore;
  • un inventario aggiornato di sistemi, versioni e fornitori: molti prodotti incorporano PHP senza dirlo, e l’agenzia olandese NCSC-NL mantiene un elenco di prodotti di terzi potenzialmente coinvolti;
  • un registro delle verifiche, per dimostrare cosa è stato controllato e quando.
Una routine, non un’emergenza: responsabile, cadenza fissa, inventario e registro delle verifiche

E la NIS2?

Per chi rientra nella NIS2, e anche FinGreenTech è soggetta alla direttiva, tra le misure di gestione del rischio rientrano la gestione delle vulnerabilità e la sicurezza della catena di fornitura. Una routine di aggiornamento documentata è proprio ciò che serve per dimostrare di aver fatto la propria parte. Vale anche per chi non è direttamente soggetto ma lavora per soggetti NIS2.

Vuoi confrontarti su come organizzare aggiornamenti e verifiche nella tua azienda? Prenota una call conoscitiva gratuita con FinGreenTech oppure scrivici a info@fingreentech.com.

Fonti: ACN – CSIRT Italia, avviso AL07/261021/CSIRT-ITA (aggiornato il 23/10/2026); ENISA, dichiarazione congiunta sulle vulnerabilità critiche in PHP (21/10/2026); CERT-EU, Security Advisory 2026-018; CERT-AGID, «PHP2Shell: strumenti per verificare l’esposizione alle vulnerabilità critiche» (22/10/2026); Il Post (21/10/2026).


Nota sulla trasparenza. Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale e revisionato dal Team di FinGreenTech, che ne è responsabile editoriale.


, , , ,

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *