Quando si parla di aggiornamenti PHP, spesso si tende a rimandare.
Si pensa che, se il sito continua a funzionare, allora non ci sia vera urgenza.
Questa volta però la situazione è diversa.
Il team di PHP ha pubblicato un avviso di sicurezza relativo a due vulnerabilità critiche, identificate come CVE-2026-109618 e CVE-2026-109619, che possono permettere esecuzione di codice remoto senza autenticazione su server vulnerabili.
Tradotto in parole semplici: un attaccante, in certe condizioni, potrebbe riuscire a colpire il server prima ancora che entri in gioco il codice dell’applicazione, quindi prima ancora di WordPress, del sito custom o del gestionale che gira sopra PHP.
È uno di quei casi in cui l’intervento non va pianificato “quando c’è tempo”, ma va fatto subito.
Cosa è successo
Secondo l’avviso ufficiale del progetto PHP, le correzioni sono state pubblicate il 21 ottobre 2026 e riguardano le versioni:
Sono gli aggiornamenti che risolvono il problema.
Il punto importante è che il rischio non riguarda solo configurazioni strane o casi limite da laboratorio.
Il progetto PHP indica come esposti tutti gli ambienti che servono richieste web, compresi:
La stessa advisory specifica che il rischio è considerato particolarmente alto per mod_php.
Perché queste vulnerabilità sono così serie
Le due falle sono diverse, ma il risultato finale può essere simile: permettere a un attaccante di interferire con il funzionamento interno di PHP fino ad arrivare a corruzione della memoria e, nei casi peggiori, a remote code execution.
CVE-2026-109618
Questa vulnerabilità è descritta dal team PHP come una forma di OOM corruption, cioè un problema che può emergere quando PHP entra in una situazione di memoria esaurita mentre sta ancora inizializzando dati interni della richiesta.
In pratica, alcuni dati possono rimanere in uno stato incompleto ma venire trattati come se fossero validi durante la fase di pulizia.
È una spiegazione molto tecnica, ma l’idea pratica è semplice: in certe condizioni il motore PHP può trovarsi a gestire male la memoria e aprire la strada a comportamenti pericolosi.
CVE-2026-109619
La seconda vulnerabilità riguarda invece uno stato globale obsoleto che può sopravvivere dopo che la memoria che lo supportava è stata liberata.
Detto in modo meno formale, una richiesta può lasciare dietro di sé “tracce” interne che non dovrebbero più esistere, e una richiesta successiva potrebbe riutilizzarle prima che tutto venga reimpostato correttamente.
Anche qui il rischio non è il semplice malfunzionamento dell’applicazione, ma la possibilità di arrivare a scenari di compromissione molto più seri.
Chi dovrebbe preoccuparsi davvero
La risposta breve è: chiunque abbia un sito o un’applicazione PHP esposta sul web.
Questo include:
Molto importante: il fatto che il vostro sito sia sviluppato bene non basta a proteggervi, se la vulnerabilità è nel motore PHP sottostante.
Se usate WordPress, per esempio, il problema non riguarda direttamente il tema o i plugin: riguarda lo strato su cui tutto il resto gira.
Cosa fare subito
La cosa giusta da fare è una sola: aggiornare PHP immediatamente alla prima versione corretta disponibile per il proprio ramo.
Se gestite direttamente il server, il percorso logico è questo:
Se invece siete su hosting gestito e non controllate direttamente il server, il consiglio è di aprire immediatamente un ticket al provider o verificare la loro documentazione ufficiale.
In questi casi è fondamentale sapere se la patch è già stata applicata lato infrastruttura oppure no.
Se non potete aggiornare immediatamente
L’advisory ufficiale di PHP riporta alcune misure temporanee per ridurre l’esposizione.
Va detto però in modo molto chiaro: non sono una soluzione vera.
Servono solo a guadagnare tempo, non a considerare il problema risolto.
Per la CVE-2026-109618 vengono suggerite, tra le altre cose, queste precauzioni:
Per la CVE-2026-109619, una delle misure indicate è:
Ribadisco però il punto essenziale: la sola scelta corretta resta l’aggiornamento.
Attenzione alle versioni vecchie di PHP
C’è un altro dettaglio da non sottovalutare.
Il progetto PHP ricorda che PHP 8.1 e tutte le versioni precedenti non ricevono più aggiornamenti ufficiali dal team principale.
Questo significa che, se il vostro server è ancora fermo a versioni vecchie, non basta aspettare il classico update automatico del ramo.
In alcuni casi i vendor Linux o gli operatori LTS possono distribuire backport di sicurezza, ma non bisogna darlo per scontato.
Conviene quindi:
Per chi gestisce WordPress il messaggio è semplice
Chi amministra siti WordPress tende spesso a concentrarsi su aggiornamenti di core, plugin, tema e backup.
Sono tutte cose giuste, ovviamente.
Però casi come questo ricordano una verità importante: la sicurezza del sito non dipende solo da WordPress, ma anche dal livello server.
Un WordPress perfettamente aggiornato, se poggia sopra una versione PHP vulnerabile, resta comunque esposto.
Quindi questa è una buona occasione per rivedere anche il proprio metodo di manutenzione:
Conclusione
Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 non sono il classico aggiornamento minore da mettere in coda.
Parliamo di due falle critiche che possono colpire il motore PHP stesso e che, secondo l’avviso ufficiale, possono portare a esecuzione di codice remoto senza autenticazione.
Se gestite un server, un VPS, un hosting con accesso tecnico o anche solo alcuni siti WordPress per clienti, questo è il momento giusto per fare una verifica immediata.
Meglio perdere mezz’ora oggi per controllare versione, patch e servizi, piuttosto che ritrovarsi domani a gestire una compromissione vera.
© COSTNET – Condividi liberamente il link, ma non copiare il contenuto senza autorizzazione.
