PHP, due falle critiche aprono alla RCE senza autenticazione: aggiornare il motore php, non solo il sito

Un sito può avere il CMS aggiornato e controlli di accesso ben progettati, ma restare esposto a un problema nel motore che esegue il codice. È questo il punto delle due vulnerabilità critiche di PHP, CVE-2026-109618 e CVE-2026-109619: possono consentire l’esecuzione remota di codice senza autenticazione, indicata con la sigla RCE. In altre parole, un attaccante potrebbe far eseguire codice al server senza disporre di un account dell’applicazione.

Il progetto PHP ha pubblicato le correzioni il 21 ottobre 2026. Le versioni da adottare nei rispettivi rami sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Non si tratta quindi di aggiornare un plugin o una libreria del sito: l’intervento riguarda PHP stesso, oppure il pacchetto corretto fornito dal proprio distributore.

Perché mod_php richiede la massima priorità

Il perimetro dell’allerta comprende tutte le installazioni PHP che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Usare una modalità diversa da mod_php non equivale dunque a essere al sicuro.

Per mod_php, che integra PHP come modulo di Apache, il team di sicurezza considera il rischio più alto: è stato dimostrato un attacco in cui una richiesta non autenticata può innescare il problema prima dell’esecuzione del codice applicativo. È una distinzione importante: un controllo di login scritto nell’applicazione non può proteggere una fase che lo precede.

Per chi gestisce più siti, la priorità è quindi individuare quali servizi web usano PHP e con quale integrazione, dando precedenza agli ambienti mod_php senza rinviare gli altri. Per chi usa un hosting gestito, la domanda da rivolgere al fornitore è concreta: il runtime PHP che serve il sito ha già ricevuto entrambe le correzioni?

Due errori nella gestione della memoria e delle richieste

La CVE-2026-109618 riguarda la gestione delle condizioni di memoria esaurita, o out of memory. Un’interruzione può lasciare alcune strutture interne della richiesta inizializzate solo in parte. Durante la successiva pulizia, PHP può trattare quei dati incompleti come se fossero validi. Il rischio non è quindi soltanto che una richiesta fallisca: è che la gestione dell’errore apra una possibilità di esecuzione di codice.

La CVE-2026-109619 coinvolge invece uno stato interno che sopravvive oltre la memoria su cui si appoggiava. Una richiesta successiva, gestita dallo stesso processo di lavoro, può usare quello stato ormai non valido prima che la normale inizializzazione lo azzeri. Il confine tra una richiesta e la successiva diventa così parte del problema.

Questi meccanismi spiegano perché intervenire soltanto sul codice del sito non risolva le vulnerabilità: i difetti si trovano nel ciclo interno con cui PHP prepara e conclude le richieste.

Le mitigazioni possono ridurre l’esposizione, non sostituire la patch

Non esiste una mitigazione completa alternativa all’aggiornamento. Alcune impostazioni bloccano percorsi d’attacco specifici, ma non rendono sicura un’installazione vulnerabile.

Per esempio, disabilitare session.upload_progress.enabled e riavviare tutti i processi di lavoro blocca i percorsi confermati legati alle sessioni per la CVE-2026-109619, non tutte le possibili varianti. L’impostazione deve applicarsi prima dell’analisi della richiesta: inserirla nel codice con ini_set() o affidarsi a .user.ini sotto FPM non è sufficiente. Anche nascondere messaggi di errore e avvisi non elimina il difetto.

Sui sistemi Linux, i pacchetti del distributore possono includere correzioni riportate su versioni precedenti, i cosiddetti backport: occorre verificare l’avviso del fornitore, non soltanto confrontare il numero di versione con quello delle release PHP. Per PHP 8.1 e precedenti, non più aggiornati ordinariamente dal progetto, è necessario accertare la disponibilità di una correzione dal proprio fornitore oppure passare a un ramo supportato.

La decisione essenziale resta questa: portare ogni servizio web su un runtime corretto. Le misure temporanee servono a ridurre l’esposizione durante l’intervento, non a giustificarne il rinvio.