← Tutti gli articoli

Notizie sull’AI

PHP corregge due falle critiche: i server vanno aggiornati

I difetti possono consentire l’esecuzione di codice senza autenticazione. PHP ha rilasciato le correzioni e le autorità europee chiedono di controllare anche i servizi ospitati da terzi.

File di rack server in una sala di calcolo
Immagine di contesto: server in un centro di calcolo; la fotografia non mostra un sistema colpito dalle vulnerabilità PHP.Foto: Derrick Coetzee / Wikimedia Commons — CC0

Due falle critiche in PHP possono consentire attacchi remoti senza login. Le correzioni sono disponibili: ecco quali server controllare e come verificare l’aggiornamento.

Il gruppo che sviluppa PHP ha rilasciato il 21 ottobre aggiornamenti per due vulnerabilità critiche che, in determinate condizioni, possono permettere a un aggressore di eseguire codice su un server senza autenticarsi. La raccomandazione è rivolta a chi gestisce siti e applicazioni, ma riguarda anche i cittadini: dietro negozi online, servizi aziendali e portali pubblici può esserci PHP, anche quando chi visita il sito non lo sa.

La Commissione europea, ENISA, CERT-EU, Europol e la rete dei CSIRT nazionali hanno chiesto alle organizzazioni di individuare i sistemi esposti e applicare le correzioni. Alcuni portali europei sono stati temporaneamente disattivati a scopo preventivo. Non significa che quei siti fossero stati violati: gli enti hanno ridotto l’esposizione mentre verificavano i sistemi e installavano le patch.

Due difetti nella gestione delle richieste

Le vulnerabilità sono registrate come CVE-2026-109618 e CVE-2026-109619. La prima riguarda la gestione di un errore di memoria; la seconda uno stato interno che può restare disponibile in modo scorretto tra richieste successive. Gli sviluppatori spiegano che entrambe possono condurre all’esecuzione remota di codice. Il rischio più alto documentato riguarda mod_php, ma l’avviso comprende tutte le installazioni PHP che servono richieste web.

Le versioni corrette rilasciate dal progetto sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Anche i sistemi basati su PHP più vecchio vanno controllati: alcune distribuzioni Linux e fornitori con supporto esteso possono distribuire correzioni retroportate. Per le versioni fuori supporto non basta verificare il numero principale; occorre chiedere al fornitore se il pacchetto è stato aggiornato oppure programmare una migrazione.

La risposta europea mostra l’impatto sui servizi

ENISA consiglia di partire dai sistemi raggiungibili da Internet e di contattare chi fornisce hosting o software gestito. La vulnerabilità può arrivare anche attraverso prodotti che incorporano PHP senza esporlo direttamente all’amministratore, quindi l’inventario deve includere applicazioni, appliance e servizi acquistati da terzi. Il consiglio non si limita ai grandi data center: anche una piccola impresa può avere un sito o un portale installato anni fa e lasciato in gestione esterna.

L’Ufficio europeo dei brevetti ha confermato di aver messo offline alcuni portali il 21 ottobre, in via precauzionale, e di averli riportati online dopo l’installazione delle patch. L’episodio rende visibile il compromesso: un servizio può interrompersi per qualche ora mentre viene protetto, oppure restare esposto durante la verifica. Non è una prova di attacco riuscito e non va letto come un blocco generalizzato dei siti PHP.

La priorità è verificare il componente che serve il sito

Per chi gestisce infrastrutture, il primo passo è ottenere dal team tecnico o dal provider l’elenco dei sistemi che eseguono PHP, dando priorità a quelli pubblici. Poi bisogna applicare il pacchetto corretto per il sistema in uso e riavviare i processi necessari: aggiornare un pannello amministrativo non garantisce, da solo, che il servizio stia eseguendo la versione riparata. Va controllato il runtime effettivamente caricato, compresi i diversi pool e i server che possono usare installazioni separate.

Se la correzione non è disponibile subito, le mitigazioni temporanee indicate dal progetto riducono alcuni percorsi di attacco ma non rendono il sistema sicuro come una patch. ENISA raccomanda di isolare dalla rete pubblica le applicazioni che non possono essere riparate in tempi rapidi; anche le autorità britanniche suggeriscono di valutare la sospensione del servizio se non è possibile applicare protezioni. Dopo l’aggiornamento, i responsabili dovrebbero controllare i log e seguire gli avvisi dei fornitori per eventuali indicatori di compromissione o aggiornamenti aggiuntivi.

Per approfondire

Per il contesto ANPAI: Come si gestisce una vulnerabilità informatica legata all’AI

Le fonti

PHP — avviso di sicurezza, 21 ottobre 2026 · ENISA e autorità europee — dichiarazione congiunta, 21 ottobre 2026 · Ufficio europeo dei brevetti — ripristino dei portali, 21 ottobre 2026 · Associated Press — interruzioni preventive dei siti, 21 ottobre 2026


Questa analisi della redazione ANPAI aiuta a leggere fatti e conseguenze operative. Non sostituisce una valutazione tecnica o legale riferita a un caso specifico.

Parliamone

Hai una domanda
o un progetto sull’AI?

Parla con ANPAI

Newsletter

Le notizie AI che contano, direttamente via email.

Ricevi una selezione chiara delle novità più importanti sull’intelligenza artificiale.