PHP, disponibili le patch per due falle critiche: va aggiornato il servizio, non solo il pacchetto

Gli aggiornamenti PHP contro le due vulnerabilità critiche annunciate il 20 ottobre sono ora disponibili. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per gli amministratori, il lavoro non è più soltanto preparare il rilascio: occorre identificare il pacchetto appropriato e verificare che il servizio web lo stia effettivamente eseguendo.

L'avviso aggiornato del progetto PHP conferma la pubblicazione il 21 ottobre. Il preavviso fissava le 14:00 UTC; CERT-EU riferisce che le correzioni sono arrivate alle 13:30 UTC, le 15:30 italiane. È quindi superata la situazione descritta dal precedente annuncio, quando non erano ancora note le versioni corrette.

Che cosa è confermato dopo il rilascio

Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 possono consentire l'esecuzione remota di codice senza autenticazione. La prima coinvolge la gestione dell'esaurimento della memoria; la seconda uno stato interno che può sopravvivere alla memoria cui si riferiva. Non basta dunque che l'applicazione richieda un accesso per presumere che il livello sottostante sia protetto.

Il progetto include nel perimetro di rischio le installazioni che servono richieste web, fra cui PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Indica mod_php come configurazione a rischio maggiore, con una dimostrazione che raggiunge il problema prima dell'esecuzione del codice applicativo. Questa è una valutazione del progetto, non una prova che ogni server sia già stato compromesso.

Individuare il runtime che serve davvero l'applicazione

Il primo lavoro resta operativo: identificare i servizi che usano PHP, chi fornisce il runtime e chi può distribuire l'aggiornamento. Un sito su hosting gestito ha responsabilità diverse da un'applicazione il cui gruppo mantiene direttamente le immagini dei container. Chiedere al provider conferma della patch installata serve più che scaricare un binario che il sito non eseguirà mai.

L'inventario deve descrivere il servizio attivo, non soltanto il computer dello sviluppatore. PHP da riga di comando e runtime del server web possono essere installazioni separate. Anche un'immagine aggiornata non cambia un servizio rimasto sulla distribuzione precedente. Origine del pacchetto, ambiente di destinazione e verifica finale vanno documentati insieme, evitando che la risposta si concluda con «il download è terminato».

La distinzione conta anche fra livelli software. Il nostro articolo sull'aggiornamento di sicurezza Field UI di Drupal riguarda la configurazione applicativa. Queste vulnerabilità interessano il runtime del linguaggio sottostante. Completare una manutenzione non dimostra che ogni altro componente sia aggiornato.

Il supporto cambia il percorso di aggiornamento

Il calendario di supporto PHP distingue i rami mantenuti e le relative scadenze. Il supporto di sicurezza di PHP 8.2 termina il 31 dicembre 2026: correggere l'emergenza non elimina quindi la necessità di pianificare la migrazione di quel ramo.

Per PHP 8.1 e precedenti, che non ricevono più normali aggiornamenti dal progetto, CERT-EU rimanda a eventuali correzioni retroportate dal fornitore o al passaggio a una versione supportata. Segnala anche backport minimi del codice sorgente per 7.4, 8.0 e 8.1 messi a disposizione per questa emergenza. Non equivalgono al ripristino del supporto ordinario, né a un pacchetto pronto per ogni sistema operativo.

Su un'installazione obsoleta possono servire verifiche di compatibilità dell'applicazione prima del passaggio a un ramo mantenuto. È un vincolo da affrontare subito con chi gestisce il servizio. Una release candidate di una versione più alta non va scelta soltanto per il numero: una build sperimentale e una correzione destinata alla produzione hanno scopi diversi.

CERT-EU raccomanda di correggere prontamente e, quando ciò non sia possibile, valutare l'isolamento delle applicazioni esposte a Internet fino all'applicazione e alla verifica della patch. Le mitigazioni parziali non sostituiscono la correzione completa. Si tratta di decisioni del responsabile del servizio, con effetti sulla disponibilità, non di un invito indistinto a spegnere qualsiasi sito PHP.

Il risultato utile è un servizio verificato sulla versione corretta, con un responsabile identificato. È quel passaggio, non la presenza di un nuovo archivio nella cartella dei download, a trasformare un avviso urgente in una vulnerabilità rimediata.