Il rischio delle vulnerabilità: il caso PHP2Shell
Il 21 ottobre 2026 il team di PHP ha corretto due vulnerabilità critiche, soprannominate PHP2Shell, che permettono di eseguire codice da remoto sui sistemi che usano versioni non aggiornate. L'ACN ha pubblicato un avviso lo stesso pomeriggio. La notizia passerà in pochi giorni, ma non ciò che ci insegna: un componente diffuso, un avviso improvviso, poche ore per rispondere a tre domande.
In sintesi
PHP non sta solo nei siti web: sta nei pannelli di amministrazione di dispositivi, gateway e macchine, e nei software che le aziende vendono. Quando esce una vulnerabilità critica in un componente così diffuso, la domanda per un fabbricante non è «PHP è sicuro?», ma «in quali dei miei prodotti c'è, in quale versione, ed è esposto?». Chi ha una distinta base del software (SBOM, Software Bill of Materials) aggiornata risponde in minuti; chi non ce l'ha risponde in giorni. Il Cyber Resilience Act (CRA) rende queste risposte un obbligo: conoscere i componenti, valutare, correggere senza ritardo e, se la vulnerabilità è sfruttata nel proprio prodotto, segnalarla entro 24 ore.
La notizia, in breve
Le due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, hanno gravità 9,2 su 10 e riguardano la gestione della memoria quando una richiesta termina in modo anomalo. Un attaccante può sfruttarle da remoto, senza credenziali. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti, non più supportati, il progetto non pubblica correzioni ufficiali: chi le usa dipende dal proprio fornitore o da una migrazione.
Tre dettagli rendono il caso istruttivo. I dettagli tecnici sono trapelati il 20 ottobre, un giorno prima della divulgazione coordinata. Il team PHP indica come configurazione più esposta quella con PHP caricato dentro il server web Apache, e avverte che le mitigazioni temporanee non bastano. L'avviso dell'ACN non segnala sfruttamento attivo, mentre Cloudflare e alcune società di sicurezza riferiscono tentativi già in corso: stessa vulnerabilità, stesso giorno, informazioni diverse a seconda della fonte.
L'avviso completo è sul sito dell'ACN: PHP2Shell: sanate vulnerabilità critiche in PHP.
Perché è un buon esempio
Ogni anno escono decine di migliaia di vulnerabilità. Poche, come questa, possono toccare molti prodotti insieme. PHP2Shell mette in fila, in un solo caso, le caratteristiche del rischio che il regolamento chiede di governare.
| Caratteristica | Nel caso PHP2Shell | Che cosa comporta per un fabbricante |
|---|---|---|
| Il componente è di terzi | PHP è un progetto open source | Il fabbricante non scrive la correzione, ma risponde del prodotto |
| Il componente è nascosto | Il pannello web di un gateway è «il gateway», non «PHP» | Senza SBOM nessuno sa che c'è, né in quale versione |
| I tempi sono stretti | Dettagli pubblici il 20, correzione il 21, attacchi lo stesso giorno | Valutazione in ore, non in settimane |
| Il rischio dipende dal contesto | Massimo con PHP dentro Apache esposto su internet; minore in rete isolata | Stesso componente, decisioni diverse per prodotti diversi |
| La fine del supporto conta | Nessuna correzione ufficiale per PHP 8.1 e precedenti | Un componente a fine vita non ha una via d'uscita semplice |
| Le informazioni sono discordanti | Sfruttamento non confermato dall'ACN, riferito da altre fonti | Serve chi legga più fonti e decida |
Le tre domande di un fabbricante
Il pomeriggio dell'avviso, un fabbricante deve rispondere a tre domande, in quest'ordine. Il regolamento le prevede tutte.
| Domanda | Che cosa serve per rispondere | Riferimento nel CRA |
|---|---|---|
| 1. Ce l'ho? In quali prodotti, in quali versioni, con quale versione di PHP | Una SBOM per ogni prodotto e versione, con i componenti identificati in modo riconoscibile | Allegato I, Parte II, punto 1 |
| 2. Mi tocca davvero? L'interfaccia è esposta? Con quale configurazione? | Una valutazione dell'esposizione reale, prodotto per prodotto, documentata anche quando la risposta è «no» (per esempio con un VEX) | Allegato I, Parte II, punti 1 e 2 |
| 3. Che cosa devo fare, ed entro quando? | Un aggiornamento di sicurezza senza ritardo e gratuito; un avviso ai clienti; se la vulnerabilità è sfruttata nel proprio prodotto, il preallarme entro 24 ore | Allegato I, Parte II, punti 2, 7 e 8; articolo 14 |
Sulla terza domanda, una precisazione. L'articolo 14 riguarda «qualsiasi vulnerabilità attivamente sfruttata contenuta nel prodotto» di cui il fabbricante viene a conoscenza: che PHP2Shell sia sfruttata da qualche parte nel mondo non obbliga, da solo, a segnalare. Obbliga a verificare se il proprio prodotto la contiene e se qualcuno la sfrutta lì. La verifica non si può rimandare: l'obbligo è in vigore dall'11 settembre 2026, anche per i prodotti già sul mercato.
Un caso concreto
I dati sono di fantasia. Un fabbricante di gateway industriali ha tre prodotti con interfaccia web: il gateway GW-200, con PHP 8.1 nel firmware; il GW-300, con PHP 8.3; un software di supervisione installato sui server dei clienti, con PHP 8.2 dentro Apache.
Alle 16:30 del 21 ottobre arriva l'avviso. Con le SBOM aggiornate, in venti minuti l'ufficio tecnico ha l'elenco: tutti e tre contengono PHP in versioni vulnerabili. Le decisioni sono diverse.
- Software di supervisione. Il caso più esposto: PHP dentro Apache, raggiungibile dalla rete del cliente. Aggiornamento alla 8.2.35 e avviso ai clienti con le mitigazioni temporanee. Caso aperto, responsabile, scadenza: tre giorni.
- GW-300. L'interfaccia web è attiva solo sulla rete locale. La vulnerabilità c'è, ma lo sfruttamento richiede l'accesso alla rete interna: aggiornamento alla 8.3.36 nel prossimo firmware, entro un mese, e valutazione documentata.
- GW-200. PHP 8.1 non riceve correzioni ufficiali. L'interfaccia è solo locale, ma il prodotto è ancora assistito e ha centinaia di installazioni. Si decide: avviso ai clienti, verifica di una correzione retroportata dal fornitore del sistema operativo embedded, e un piano per portare la famiglia su una versione supportata. È la decisione più costosa, quella che la fine del supporto di un componente impone sempre.
Nessun cliente segnala attacchi: non scatta la segnalazione in 24 ore. Se un cliente avesse trovato tracce di sfruttamento, il preallarme all'autorità sarebbe dovuto partire entro 24 ore da quel momento. In entrambi i casi il fabbricante ha ciò che serve: l'elenco, le valutazioni, le decisioni con data e responsabile.
Senza SBOM, la scena è un'altra: un'e-mail ai responsabili delle tre linee, risposte nell'arco di una settimana, un firmware di cui nessuno ricorda la versione di PHP, e i clienti che chiedono «siete vulnerabili?» senza ricevere risposta.
Il costo di non saperlo
Il rischio delle vulnerabilità non è l'evento singolo: è il flusso. PHP2Shell ha un nome e fa notizia; la prossima vulnerabilità nel sistema operativo embedded, nella libreria di cifratura o nello stack del protocollo industriale non lo avrà, e arriverà comunque. Chi risponde alle tre domande solo quando una notizia lo costringe paga ogni volta lo stesso prezzo: giorni di lavoro non pianificato, clienti senza risposta, decisioni prese sotto pressione e non documentate. Dall'11 dicembre 2027 si aggiunge l'autorità di vigilanza, che può chiedere SBOM, valutazioni ed evidenze.
Il metodo che il CRA chiede è il contrario: sapere prima che cosa c'è nei prodotti, confrontarlo ogni giorno con ciò che esce, valutare i pochi casi che contano, documentare. Così il 21 ottobre diventa ordinaria amministrazione.
Che cosa succede in Assiduo in una giornata così
Il Presidio Continuo di Assiduo confronta ogni giorno le SBOM dei prodotti con le banche dati delle vulnerabilità e gli avvisi dei fornitori. Il 21 ottobre, per ogni cliente con PHP tra i componenti, segnala prodotti e versioni toccate; il team Algor valuta l'esposizione con le persone del cliente e apre un caso per prodotto, con responsabile, stato e scadenza. Le decisioni, compresa quella di non intervenire, restano documentate con le evidenze e, se serve, con la bozza della segnalazione nei tempi dell'articolo 14. Assiduo prepara, le persone decidono.
Domande frequenti
Ho un sito web in PHP ma non vendo prodotti con software: il CRA mi riguarda?
No: il CRA riguarda i prodotti messi sul mercato, non i sistemi che un'azienda usa per sé. Il sito va comunque aggiornato, come raccomanda l'ACN; se l'azienda è un soggetto NIS2, la gestione delle vulnerabilità dei propri sistemi rientra tra le misure di quella norma.
Devo segnalare PHP2Shell all'ACN?
Solo se è contenuta in un tuo prodotto e vieni a conoscenza che viene sfruttata lì: allora il preallarme va inviato entro 24 ore. Una versione vulnerabile nel prodotto richiede valutazione e correzione, non la segnalazione.
Che cosa cambia se il componente è a fine supporto?
Che la correzione non arriva da chi lo sviluppa. Le opzioni sono tre: una correzione retroportata da un fornitore che ancora lo mantiene, una mitigazione documentata, la migrazione a una versione supportata. Il regolamento chiede di gestire le vulnerabilità per tutto il periodo di assistenza: un componente a fine vita dentro un prodotto ancora assistito va affrontato prima che una notizia lo renda urgente.
Da dove cominciare
Dalla prima domanda. Se oggi non sai in quali dei tuoi prodotti c'è PHP e in quale versione, il lavoro da fare è la SBOM, prodotto per prodotto. Il configuratore ti dice in pochi minuti quanto costa un presidio continuo sul tuo perimetro.
Fonti: ACN, CSIRT Italia, avviso AL07/261021/CSIRT-ITA «PHP2Shell: sanate vulnerabilità critiche in PHP», 21 ottobre 2026; avvisi di sicurezza del progetto PHP GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp; record CVE-2026-109618 e CVE-2026-109619; regolamento (UE) 2024/2847, articolo 13 paragrafi 5 e 8, articolo 14, Allegato I Parte II. Consultate il 22 ottobre 2026. Leggi anche: vulnerabilità attivamente sfruttata, come verificare la SBOM di un fornitore.