Due vulnerabilità di gravità critica nel runtime PHP hanno portato ENISA, Commissione europea, CERT-EU, Europol EC3 e la rete dei CSIRT nazionali a chiedere alle organizzazioni di intervenire subito. Gli avvisi riguardano CVE-2026-109618 e CVE-2026-109619: in determinate condizioni possono consentire esecuzione di codice da remoto senza autenticazione. PHP ha pubblicato gli aggiornamenti correttivi il 21 ottobre 2026. La prima domanda per chi gestisce un sito non è “come provo l’exploit?”, ma “quale PHP gira davvero dietro il mio dominio e chi ha applicato la patch?”. Il problema è che molti proprietari non amministrano direttamente il server. Un sito WordPress o un’applicazione PHP può essere ospitata su un piano condiviso, un VPS gestito, una piattaforma cloud o un server seguito da un fornitore. Il CMS, il tema e i plugin non mostrano necessariamente la versione del runtime che elabora le richieste. Un aggiornamento dell’applicazione non equivale a un aggiornamento di PHP, e viceversa: vanno verificati entrambi. Fai un inventario dei domini, sottodomini, ambienti di test e applicazioni pubbliche. Includi pannelli di amministrazione, API, vecchi siti non più aggiornati e software acquistati da terzi. La vulnerabilità può interessare componenti basati su PHP anche quando l’utente non sa che PHP è presente: per questo ENISA invita a controllare anche i prodotti commerciali e le dipendenze. Se non sai quali servizi siano ospitati, chiedi al referente IT o al provider di elencare gli ambienti associati al tuo account.
Perché è importante
- Una notizia selezionata per il suo impatto concreto.
- Le conseguenze riguardano professionisti e imprese.
- Le fonti sono disponibili per la verifica.
Il punto della notizia
Non pubblicare un file phpinfo() per “scoprire la versione”. Una pagina di diagnostica esposta può rivelare informazioni tecniche utili a un aggressore e spesso rimane online per errore. Le modalità più sicure sono il pannello del provider, una console amministrativa autenticata o una conferma scritta del gestore. Se hai accesso amministrativo alla macchina, chiedi a chi la gestisce di usare la console o la shell nel contesto corretto: la versione del PHP da riga di comando può essere diversa da quella usata dal web server.
Chiedi una verifica precisa, non un “tutto aggiornato”
Invia al provider il nome del dominio e chiedi quattro risposte: versione PHP attiva per il sito; ramo di versione e pacchetto installato; data dell’ultimo aggiornamento; conferma che le correzioni per CVE-2026-109618 e CVE-2026-109619 siano incluse. Chiedi inoltre se il server usa PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o un’altra modalità, perché il team PHP segnala un rischio maggiore per mod_php. Non serve discutere dettagli dell’exploit: l’obiettivo è avere una verifica attendibile e una finestra di manutenzione. Il progetto PHP indica come versioni correttive 8.5.12, 8.4.27, 8.3.36 e 8.2.35, pubblicate il 21 ottobre. Non dedurre però che ogni versione numericamente successiva sia automaticamente corretta: le distribuzioni Linux e i fornitori di supporto prolungato possono applicare la patch mantenendo un numero di versione diverso, cioè con un backport. In quel caso chiedi il riferimento del pacchetto e l’avviso del fornitore che attesta l’inclusione della correzione. PHP 8.1 e versioni precedenti non ricevono aggiornamenti dal progetto upstream; alcune distribuzioni possono fornire correzioni proprie, quindi va verificato il supporto effettivo, non solo il numero.
Programmare l’aggiornamento non basta. Chiedi quando il pacchetto sarà installato e se occorre riavviare PHP-FPM o il server web affinché i processi usino i file aggiornati. Dopo l’intervento verifica che sito, login, pagamenti, moduli e integrazioni principali rispondano correttamente. Conserva ticket, versione prima e dopo, data, ambienti coinvolti e nome del fornitore: sono prove utili per un controllo successivo e per evitare che un ambiente dimenticato resti indietro. L’avviso ufficiale del team PHP del 23 ottobre aggiunge un caso di configurazione insolito relativo a session.upload_progress e alla modifica dinamica del serializzatore delle sessioni. Per la protezione completa indica di disabilitare session.upload_progress.enabled fino alla prossima versione correttiva quando ricorrono le condizioni descritte; chi ha già applicato questa misura deve mantenerla. Non cambiare parametri di produzione alla cieca: passa l’indicazione al gestore PHP, che può verificare se quella combinazione esiste e applicare la mitigazione in modo controllato.
Il punto, oltre l’annuncio
Tratta il caso come una richiesta urgente: apri un ticket con priorità, chiedi una data di risoluzione e individua se l’applicazione è raggiungibile pubblicamente. ENISA raccomanda di dare priorità ai sistemi esposti a Internet e, quando la correzione immediata non è possibile, valutare l’isolamento temporaneo dell’applicazione dalla rete pubblica. Questa scelta deve essere presa dal responsabile tecnico perché può interrompere il servizio. Aggiorna anche plugin, CMS e prodotti di terze parti seguendo gli avvisi dei rispettivi produttori, senza presumere che la patch del runtime aggiorni automaticamente ogni componente. La verifica utile è semplice da documentare: inventario dei siti, versione effettiva del runtime, prova del pacchetto corretto o del backport, riavvio se necessario e test funzionale. Se gestisci un sito tramite hosting, puoi chiedere tutto questo senza accedere al server e senza eseguire test offensivi. Il punto è chiudere il dubbio con una conferma verificabile, non esporre il sito con esperimenti improvvisati.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
