Due vulnerabilità critiche corrette
Il progetto PHP ha pubblicato il 21 ottobre 2026 gli aggiornamenti di sicurezza PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le release correggono CVE-2026-109618 e CVE-2026-109619, vulnerabilità che il team PHP descrive come potenzialmente in grado di consentire esecuzione di codice da remoto senza autenticazione. In parole semplici, un aggressore potrebbe indurre un server a eseguire codice tramite una richiesta di rete senza prima accedere a un account. Il progetto invita gli utenti ad aggiornare.
L’avviso descrive due condizioni interne differenti. Non riportiamo dettagli di sfruttamento. Il punto operativo è che il runtime PHP elabora le richieste prima che le protezioni dell’applicazione possano necessariamente intervenire: un firewall per plugin o nascondere gli errori non sostituisce il runtime corretto. PHP indica che non esistono mitigazioni complete e che l’aggiornamento è la scelta sicura.
Controlla il runtime che serve il sito
Un sito WordPress, WooCommerce o personalizzato non è automaticamente vulnerabile solo perché utilizza PHP. L’esposizione dipende dalla build PHP, dall’interfaccia del server, dalla configurazione, dalle patch del fornitore e dall’eventuale aggiornamento dell’hosting. Il progetto PHP include installazioni web con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed e considera mod_php la configurazione a rischio maggiore. Le distribuzioni Linux e i fornitori LTS possono distribuire correzioni retroportate con versioni proprie.
Individua la versione PHP realmente usata dal sito in produzione, non soltanto quella della riga di comando sul computer dello sviluppatore. I provider WordPress gestiti spesso espongono la versione nel pannello o tramite assistenza. Chi usa hosting condiviso può chiedere quale pacchetto sia attivo e se il processo sia stato riavviato. Se gestisci il server, confronta il pacchetto con l’avviso PHP e con quello del sistema operativo: una patch retroportata potrebbe non cambiare il numero di versione upstream.
Aggiorna con test mirati
In un ambiente gestito internamente, crea un backup recente e verifica che sia ripristinabile. Applica il pacchetto corretto in staging quando possibile e prova i percorsi essenziali: accesso, moduli, attività pianificate, caricamento media, checkout, integrazioni e funzioni amministrative. Controlla i log e i processi in background. Se il sito contiene estensioni personalizzate o dipendenze datate, verifica la compatibilità prima di cambiare il runtime in produzione.
Un provider può installare centralmente l’aggiornamento, ma il cliente dovrebbe confermare che il runtime di produzione sia coperto e che il sito funzioni dopo l’intervento. Non rimandare a lungo una patch di sicurezza per una migrazione o un redesign. Se un problema di compatibilità impedisce l’aggiornamento, chiedi un piano specifico e con una scadenza al provider o allo sviluppatore; non presumere che una modifica al livello dell’app neutralizzi una vulnerabilità del runtime.
Pianifica anche dopo la patch
Secondo il progetto PHP, il supporto a PHP 8.2 termina il 31 dicembre 2026. La versione 8.2.35 corregge questo avviso, ma non prolunga il periodo di supporto del ramo. Chi usa 8.2 dovrebbe pianificare una verifica di compatibilità e passare a un ramo supportato prima della fine degli aggiornamenti di sicurezza. PHP 8.1 e versioni precedenti non ricevono più correzioni dal progetto; alcuni provider LTS potrebbero fornire backport, da verificare con il fornitore.
Mantieni un inventario semplice di siti, versioni PHP, responsabili e canali di aggiornamento. Così il prossimo avviso sarà più facile da gestire. L’azione immediata è verificare runtime e stato delle patch con chi lo gestisce e quindi testare il sito. L’avviso non dimostra che un sistema sia stato compromesso e l’uso di WordPress non dimostra, da solo, che sia al sicuro o esposto.
Fonti e approfondimenti
Vuoi segnalare un errore o suggerire una fonte? Contatta la redazione.
