PHP2Shell: la decisione sui servizi esposti e le prove da chiedere al fornitore

Il 25 ottobre 2026 il CSIRT Italia ha pubblicato sul sito dell'Agenzia per la Cybersicurezza Nazionale (ACN) l'avviso "PHP2Shell: aggiornare immediatamente i sistemi vulnerabili". Il monitoraggio nazionale ha individuato 741.523 servizi PHP. Per 285.149 la versione rilevata è potenzialmente vulnerabile; sul solo insieme dei servizi con versione identificata, la quota è dell'81,9%. L'ACN precisa che le stime basate sulla versione possono includere sistemi già corretti senza modifica del numero di versione. Il 21 ottobre 2026 il PHP security team ha rilasciato aggiornamenti per CVE-2026-109618 e CVE-2026-109619, due vulnerabilità che possono consentire l'esecuzione di codice da remoto senza autenticazione, conosciute insieme come PHP2Shell. Secondo l'avviso del progetto, le misure temporanee offrono una protezione parziale; la correzione completa richiede l'aggiornamento. Per chi dirige un'azienda o un ente, rinviare la correzione richiede quindi di valutare che cosa resta esposto durante l'attesa. La direzione può chiedere una risposta distinta per ciascun servizio: quale intervento è necessario, chi può eseguirlo e quando sarà verificato. Se queste informazioni mancano, conviene assegnarne l'acquisizione a un responsabile, con un termine preciso.

Ricostruire il perimetro dei servizi

La Cyber Security Agency of Singapore segnala che PHP può essere presente in applicazioni e componenti di terzi anche quando il sito principale non lo utilizza. Una ricognizione limitata al sito istituzionale rischia quindi di lasciare fuori una parte del perimetro.

Per organizzare il lavoro è utile partire dai servizi erogati e risalire a chi ne gestisce i componenti. Al referente interno si può chiedere di descrivere la funzione del servizio e al fornitore o all'amministratore tecnico di accertare la presenza di PHP. Le due informazioni vanno collegate, perché conoscere un componente vulnerabile senza sapere quale attività dipenda da esso non basta per valutare un'interruzione.

Il National Cyber Security Centre britannico raccomanda di censire le installazioni e dare precedenza a quelle esposte su Internet, occupandosi poi di quelle interne. La priorità può essere tradotta in un elenco di interventi che distingua i servizi già verificati da quelli per cui manca ancora una risposta. Per questi ultimi è opportuno indicare chi sta svolgendo l'accertamento. L'assenza di informazioni non dovrebbe essere registrata come esito favorevole.

Chiedere al fornitore un riscontro verificabile

Quando la gestione è affidata all'esterno, la richiesta al fornitore può descrivere il risultato atteso e le prove necessarie per accettarlo. Una risposta che si limiti a dichiarare il sistema aggiornato non consente di ricostruire quali servizi siano stati controllati o che cosa sia stato effettivamente applicato.

L'ACN raccomanda l'aggiornamento immediato delle installazioni vulnerabili e la verifica della sua effettiva applicazione, anche per i pacchetti gestiti dai fornitori delle distribuzioni.

Il National Institute of Standards and Technology, nella guida SP 800-40 Rev. 4, include la verifica dell'installazione nel processo di gestione delle patch. Per tradurre questo criterio in una richiesta, si può chiedere al fornitore un riscontro che riporti:

• I servizi e gli ambienti compresi nell'intervento, insieme alle eventuali esclusioni.
• La versione o il pacchetto installato e il riferimento alla correzione delle vulnerabilità.
• La data dell'intervento e la conferma che la correzione sia attiva sui sistemi interessati.
• I controlli eseguiti dopo l'intervento, con gli esiti e le attività ancora aperte.

Il confronto sul solo numero di versione richiede cautela. Il progetto PHP indica che i distributori possono fornire correzioni riportate su versioni precedenti, ossia backport. In tali casi, è preferibile chiedere al fornitore il riferimento al pacchetto corretto e al relativo avviso di sicurezza, anziché dedurre l'esito dalla sola numerazione.

Per la direzione, il riscontro ha valore se permette di distinguere il completato dal pianificato. Una data prevista non attesta l'esecuzione; una correzione disponibile non attesta che sia già operativa. Conviene affidare a un referente interno la verifica della risposta e il sollecito delle parti mancanti, così da evitare che una richiesta inoltrata venga considerata un'attività conclusa.

Questo criterio può essere applicato anche ai fornitori che gestiscono soltanto una parte del servizio. La richiesta riguarda il componente sotto la loro responsabilità e il soggetto che dovrà intervenire sulle parti escluse.

Attribuire la decisione sulla sospensione

L'avviso dell'ACN raccomanda di valutare se porre offline i servizi vulnerabili quando non sia possibile aggiornarli tempestivamente o adottare mitigazioni efficaci. Dove sono disponibili regole specifiche, raccomanda di configurare i Web Application Firewall (WAF) in modalità blocco e verificarne l'attivazione e l'efficacia. Queste misure non sostituiscono gli aggiornamenti di sicurezza.

Il National Cyber Security Centre britannico invita a considerare la disconnessione dei servizi quando non sia possibile aggiornare e le mitigazioni temporanee non siano applicabili o richiedano troppo tempo. È una raccomandazione condizionata alla situazione tecnica, non una disposizione di spegnimento generalizzato.

Per applicarla, una direzione può stabilire chi sia autorizzato a decidere la sospensione e quali informazioni debbano essere disponibili prima della scelta. Il responsabile tecnico descrive l'esposizione e le possibilità di intervento; il responsabile del servizio valuta le conseguenze dell'indisponibilità sulle attività. Se le competenze decisionali sono già definite, il lavoro consiste nell'attivarle e nel rendere disponibili questi elementi.

La proposta operativa è documentare, per ciascun servizio che rimane esposto, il motivo del rinvio e il termine entro cui riesaminare la decisione. Il termine dovrebbe comprendere giorno e ora, insieme al nominativo di chi presenterà il nuovo riscontro. Un rinvio privo di una verifica successiva lascia aperta l'esposizione senza un momento prestabilito per rivalutarla.

La valutazione dell'interruzione può comprendere le attività che si fermerebbero, le dipendenze da altri servizi e le modalità alternative effettivamente disponibili. Non basta nominare un'alternativa: chi gestisce l'attività dovrebbe accertare che sia utilizzabile nelle condizioni previste.

È utile definire anche le condizioni per la riapertura. Chi autorizza una sospensione dovrebbe poter sapere quali riscontri tecnici saranno richiesti e chi controllerà il funzionamento del servizio prima di proporne il ripristino. Stabilire questi criteri insieme alla decisione di sospendere permette di preparare il lavoro necessario alla riapertura.

Distinguere la correzione dalla ricerca di compromissioni

L'applicazione della correzione riguarda la vulnerabilità del software. Non ricostruisce ciò che è accaduto prima dell'intervento.

L'ACN raccomanda un esame retrospettivo dei log e degli eventi di sicurezza per cercare tracce di sfruttamento o compromissione. I controlli dovrebbero includere le anomalie nelle richieste HTTP, gli errori dovuti all'esaurimento della memoria e gli arresti imprevisti dei processi PHP.

Il National Cyber Security Centre britannico raccomanda, per i sistemi che non possono essere aggiornati o disattivati immediatamente, di cercare segnali di compromissione e backdoor prima dell'aggiornamento o della mitigazione. Questa indicazione distingue due attività che possono avere esiti diversi: correggere il software e verificare se qualcuno abbia già sfruttato la vulnerabilità.

Nel rapporto destinato alla direzione è quindi utile tenere separati i relativi risultati. Il tecnico può confermare l'applicazione della correzione e precisare, nello stesso rapporto, che la verifica di eventuali compromissioni è ancora in corso. La seconda attività non dovrebbe scomparire dal programma di lavoro quando termina la prima.

Per rendere leggibile il risultato dell'accertamento, si può chiedere che il rapporto indichi i sistemi esaminati, il periodo considerato e le evidenze utilizzate. Se i dati disponibili non permettono di coprire tutto il periodo, il limite dovrebbe essere riportato. La formula "nessun segnale rilevato" va letta insieme all'estensione dei controlli eseguiti: non equivale a dimostrare che il sistema non sia mai stato compromesso.

La decisione successiva dipenderà dagli esiti. È preferibile individuare prima chi riceverà eventuali segnalazioni e chi potrà autorizzare gli ulteriori accertamenti, senza presumere che ogni servizio vulnerabile abbia subito un attacco.

Chiudere l'intervento con esiti distinti

Il 23 ottobre 2026 il progetto PHP ha pubblicato un ulteriore avviso relativo a CVE-2026-115560, descritta come un vettore di attacco improbabile e legato a specifiche condizioni. L'ACN segnala che, alla data dell'avviso del 25 ottobre, questa vulnerabilità è ancora priva di patch. La misura indicata è impostare session.upload_progress.enabled=0 nella configurazione del server; l'avviso del 21 ottobre richiede il riavvio di tutti i processi PHP che eseguono le richieste, detti worker, per applicare la configurazione. L'ACN raccomanda: "Verificare che la configurazione sia effettivamente applicata ai processi PHP interessati". Questo controllo va distinto dall'aggiornamento che corregge le prime due vulnerabilità.

Nella chiusura dell'intervento conviene quindi chiedere riscontri separati per le correzioni applicate e per le configurazioni richieste dagli avvisi pertinenti. Il referente tecnico potrà indicare quali misure riguardano l'installazione esaminata e documentarne l'esito.

Per la direzione è utile un riepilogo per servizio che riporti lo stato attuale, i controlli conclusi e le attività ancora da completare, ciascuna con un responsabile e una data. Un servizio può essere nuovamente disponibile mentre proseguono altri accertamenti: questa condizione va descritta, affinché il ripristino operativo non chiuda anche le attività rimaste aperte.

Il referente incaricato può proporre la chiusura dopo avere confrontato i risultati con gli interventi richiesti. Se restano attività aperte, il riepilogo dovrebbe indicare chi le seguirà e quando verranno riesaminate. La conferma del fornitore è una delle evidenze da esaminare; la decisione di chiusura presuppone che l'organizzazione ne abbia verificato il contenuto e il perimetro.