Chi gestisce un sito, un e-commerce o un gestionale scritto in PHP ha una sola priorità in queste ore: aggiornare. Il 21 ottobre alle 16 ora italiana il progetto PHP ha corretto due vulnerabilità critiche nel linguaggio stesso, CVE-2026-109618 e CVE-2026-109619, note come "PHP2Shell". Entrambe hanno un punteggio CVSS di 9,2 su 10 e, nel caso peggiore, consentono a un attaccante di far girare codice proprio sul server senza bisogno di credenziali.
Poco dopo il rilascio, il CSIRT Italia dell'Agenzia per la cybersicurezza nazionale (ACN) ha diffuso l'avviso AL07/261021/CSIRT-ITA, classificando l'impatto come "alto" (65,64). Lo stesso giorno il CERT della rete della ricerca GARR ha inviato alla propria comunità l'alert GCSA-26279. Ecco cosa sappiamo e cosa conviene fare.
Che cosa sono le falle PHP2Shell?
Il problema non riguarda un singolo CMS o un plugin, ma l'ambiente di esecuzione di PHP. Secondo la scheda dell'ACN, entrambe le falle appartengono alla categoria "use after free": il programma continua a usare aree di memoria che erano già state liberate.
- CVE-2026-109618 nasce dalla gestione delle situazioni in cui PHP esaurisce la memoria disponibile: l'elaborazione della richiesta viene interrotta bruscamente e alcuni dati interni restano a metà.
- CVE-2026-109619 riguarda lo stato globale interno di PHP, che dopo un errore critico può conservare riferimenti a memoria non più valida.
Il risultato, in entrambi i casi, è la possibilità di esecuzione di codice da remoto (RCE), la categoria più grave. Per scelta non riportiamo dettagli utili a sfruttare le vulnerabilità.
Quali versioni sono sicure?
L'ACN elenca come vulnerabili tutti i rami supportati fino alla versione precedente alla correzione. La tabella riassume la situazione:
| Ramo PHP | Vulnerabile | Versione corretta |
|---|---|---|
| 8.5 | fino a 8.5.11 | 8.5.12 |
| 8.4 | fino a 8.4.26 | 8.4.27 |
| 8.3 | fino a 8.3.35 | 8.3.36 |
| 8.2 | fino a 8.2.34 | 8.2.35 |
| 8.1 e precedenti | sì, fuori supporto | nessuna release ufficiale |
Il punto delicato è l'ultima riga. Come ricordano sia l'ACN sia il GARR, PHP supporta ormai solo le versioni dalla 8.2 in poi: per PHP 8.1 e precedenti non ci saranno nuove release. Chi usa una distribuzione Linux deve controllare i bollettini di Debian, Ubuntu, Red Hat e simili, che spesso portano la correzione nei propri pacchetti senza cambiare il numero di versione. Le immagini Docker vanno ricostruite.
Cosa raccomandano ACN e GARR
Le indicazioni dell'Agenzia sono nette e si possono riassumere in tre passaggi:
- Aggiornare subito i prodotti vulnerabili seguendo il bollettino di PHP.
- Se non è possibile farlo in tempi brevi, valutare lo spegnimento temporaneo di ogni sito o servizio web ancora basato su una versione vulnerabile.
- Controllare a ritroso i log, cercando richieste HTTP anomale, errori di esaurimento della memoria, terminazioni inattese dei processi PHP ed eventuali attività sospette successive.
L'alert del GARR, rivolto agli enti collegati alla rete nazionale di università e ricerca, va nella stessa direzione. Riprende la raccomandazione del CERT-EU di isolare dalla rete pubblica le applicazioni esposte su Internet finché non è possibile installare la correzione, e avverte che le mitigazioni non ufficiali che circolano online non garantiscono una protezione completa. Va precisato che si tratta di un consiglio agli enti: l'alert non dice nulla su eventuali interventi sui servizi del GARR stesso.
Due chiarimenti pratici. Primo: aggiornare WordPress, Joomla, Drupal o Magento non basta, perché la falla sta in PHP sul server. Secondo: dopo l'aggiornamento bisogna riavviare PHP-FPM o Apache e verificare la versione effettivamente usata dal sito, non solo quella mostrata da riga di comando. Chi ha un sito in hosting condiviso farebbe bene a chiedere conferma scritta al provider.
E in Italia? La situazione finora
Al momento non risultano casi italiani di intrusioni o di siti pubblici spenti a causa di PHP2Shell: ACN e GARR hanno diffuso avvisi preventivi, senza segnalare attacchi riusciti nel Paese. Nel resto d'Europa il quadro è stato più movimentato. Secondo l'ANSA, in Francia diversi siti delle prefetture, compreso quello di Parigi, sono risultati irraggiungibili. Nei Paesi Bassi, come ha riportato la NOS, i portali pubblici DigiD e MijnOverheid sono stati spenti per precauzione in attesa della patch. In Germania il BSI ha lanciato un'allerta per il potenziale di minaccia elevato, mentre negli Stati Uniti la NSA ha esortato i gestori a installare gli aggiornamenti.
Per enti e aziende soggetti alla direttiva NIS2, recepita in Italia con il decreto legislativo 138/2024, una compromissione tramite questa falla può diventare un incidente da notificare al CSIRT Italia. Se vengono coinvolti dati personali scatta anche la valutazione della notifica al Garante privacy entro 72 ore, come previsto dal GDPR.
Perché la falla preoccupa così tanto
La ragione è la diffusione di PHP. Secondo i dati citati dall'ANSA, la tecnologia è alla base di circa il 70% dei siti web nel mondo: blog, negozi online, intranet, portali di comuni e università, ma anche interfacce di amministrazione di router, NAS e firewall. Chi sfrutta le falle può spesso raggiungere direttamente file e database della macchina, cioè i dati dei clienti.
C'è poi un elemento nuovo: sempre secondo l'ANSA, che cita il Wall Street Journal, le vulnerabilità sono state individuate con l'aiuto di strumenti di intelligenza artificiale. Gli stessi strumenti permettono anche agli attaccanti di analizzare una patch in poche ore, riducendo il tempo a disposizione di chi deve aggiornare. Lo abbiamo visto anche con la falla di WordPress CVE-2026-87902 e con la vulnerabilità di Roundcube, attaccate poco dopo la pubblicazione delle correzioni. Chi gestisce server propri trova un altro esempio recente nelle falle sfruttate di NetScaler.
Domande frequenti
Chi naviga sui siti deve fare qualcosa?
No. L'intervento spetta a chi gestisce i server: amministratori, provider di hosting, sviluppatori. Se un sito comunica un incidente, è prudente cambiare la password usata su quel servizio.
Basta aggiornare il CMS o i plugin?
No. La vulnerabilità è in PHP, non nell'applicazione. Serve una versione di PHP corretta (8.5.12, 8.4.27, 8.3.36 o 8.2.35) oppure il pacchetto aggiornato della propria distribuzione.
Il mio server usa ancora PHP 7.4 o 8.1: cosa posso fare?
Per questi rami non ci sono release ufficiali. Le strade sono le patch della distribuzione o di un fornitore di supporto esteso e, nel frattempo, le misure indicate dall'ACN, compreso lo spegnimento temporaneo dei servizi esposti. Nel medio periodo è necessario passare a PHP 8.2 o successivo.
Le falle sono già sfruttate?
L'avviso dell'ACN non segnala sfruttamento attivo né codice dimostrativo pubblico. Data la gravità e la diffusione di PHP, però, le autorità raccomandano di non aspettare.
