PHP: individuate due vulnerabilità critiche con rischio di esecuzione di codice da remoto

Data di pubblicazione: 22 ottobre 2026
Livello di criticità: Critico
Tecnologia interessata: PHP
CVE: CVE-2026-109618, CVE-2026-109619

Il progetto PHP ha pubblicato il 21 ottobre 2026 un bollettino di sicurezza relativo a due vulnerabilità critiche che possono consentire l’esecuzione di codice da remoto (Remote Code Execution – RCE) senza autenticazione preventiva. Entrambe sono state corrette attraverso il rilascio di nuove versioni del linguaggio. Fonte ufficiale PHP.

Le vulnerabilità interessano le installazioni PHP che elaborano richieste web. Il rischio è particolarmente rilevante per i sistemi esposti a Internet, poiché lo sfruttamento può avvenire senza che l’attaccante disponga di un account applicativo valido. Il team PHP segnala un rischio maggiore per le configurazioni Apache con mod_php, per le quali è stato dimostrato un percorso di attacco attivabile prima dell’esecuzione del codice applicativo.

In caso di sfruttamento riuscito, un attaccante potrebbe eseguire codice nel contesto del processo PHP compromesso, con conseguenze dipendenti dai privilegi disponibili e dalle misure di isolamento adottate.

Dettaglio tecnico delle vulnerabilità

CVE-2026-109618 – Corruzione dello stato interno in condizioni di esaurimento della memoria

La vulnerabilità è associata alla gestione degli errori di esaurimento della memoria (Out of Memory – OOM). In determinate condizioni, l’elaborazione di una richiesta può essere interrotta mentre alcune strutture interne di PHP risultano inizializzate solo parzialmente. Le successive operazioni di pulizia possono quindi interpretare dati non validi come se fossero corretti, aprendo un possibile percorso verso l’esecuzione di codice.

CVE-2026-109619 – Utilizzo di stato globale non più valido

La seconda vulnerabilità riguarda la persistenza di stato interno associato a una richiesta dopo che la memoria di riferimento è stata liberata. Una richiesta successiva, gestita dallo stesso processo worker, può utilizzare tale stato prima che venga correttamente reimpostato, creando condizioni che possono portare all’esecuzione di codice.

Entrambe le vulnerabilità sono classificate come critiche e richiedono una gestione prioritaria.

Sistemi e componenti potenzialmente interessati

La verifica deve includere tutte le installazioni PHP utilizzate per servire richieste web, in particolare:

• Server web e runtime: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.
• Siti e applicazioni web: WordPress, Drupal e altri CMS o applicativi sviluppati in PHP.
• Pannelli di amministrazione e interfacce web: router, firewall e altri dispositivi che integrano PHP nei propri servizi web.
• Infrastrutture gestite da terze parti: hosting, server virtuali, container e servizi applicativi, verificando la versione PHP effettivamente in esecuzione e l’eventuale disponibilità di patch del fornitore.

La presenza di WordPress o di un altro CMS non è, da sola, sufficiente a determinare l’esposizione: è necessario verificare il runtime PHP sottostante, la versione installata e le eventuali correzioni distribuite dal vendor.

Mitigazioni e azioni raccomandate

1. Aggiornamento immediato

La misura prioritaria consiste nell’aggiornare PHP a una versione corretta:

Versione di partenza	Versione corretta
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Per le installazioni gestite tramite distribuzioni Linux, hosting provider o altri vendor, occorre verificare la disponibilità dei pacchetti aggiornati, incluse eventuali correzioni retroportate (backport).

Le versioni PHP 8.1 e precedenti non ricevono più aggiornamenti ordinari dal progetto PHP. Alcuni fornitori possono distribuire correzioni specifiche; in assenza di una patch verificata, è necessario pianificare la migrazione a una versione supportata.

Riferimenti: bollettino ufficiale · download PHP.

2. Misure temporanee in attesa dell’aggiornamento

Qualora non sia possibile applicare immediatamente le patch, il bollettino ufficiale descrive alcune misure per ridurre l’esposizione a specifici percorsi di attacco. Queste configurazioni non costituiscono una correzione completa e non garantiscono che il sistema sia sicuro.

Per la CVE-2026-109618:

• Valutare la configurazione memory_limit=-1, applicandola a livello di amministrazione PHP o del pool PHP-FPM in modo che le applicazioni non possano sovrascriverla. La misura riduce uno specifico percorso legato al limite di memoria PHP, ma non elimina il rischio associato a un effettivo esaurimento delle risorse.
• Ridurre post_max_size in funzione delle esigenze applicative. Il progetto PHP suggerisce 8 MB per applicazioni che non richiedono upload e 32 MB quando sono necessari caricamenti di file; mantenere upload_max_filesize inferiore a post_max_size.
• Applicare limiti alle richieste anche a livello di reverse proxy o web server, considerando dimensione dei dati elaborati, numero di campi, parti multipart, intestazioni e profondità di annidamento.
• Valutare limiti di risorse a livello di container o cgroup, con una gestione che circoscriva gli effetti di eventuali esaurimenti delle risorse.

Per la CVE-2026-109619:

• Disabilitare session.upload_progress.enabled tramite una configurazione applicata prima dell’elaborazione delle richieste e riavviare tutti i worker interessati.
• Per PHP 8.5, impostare fatal_error_backtraces=0 e riavviare i worker, tenendo presente che la misura contrasta soltanto uno dei percorsi di attacco confermati.
• Correggere configurazioni per richiesta non valide o obsolete che generino diagnostica prima della corretta inizializzazione.
• Individuare e correggere gli errori fatali e i timeout raggiungibili dall’esterno, inclusi quelli relativi a callback, caricamento o importazione di file e procedure di pulizia.

Le impostazioni devono essere validate rispetto all’architettura effettiva e ai requisiti delle applicazioni. In particolare, non è opportuno applicare indiscriminatamente modifiche ai limiti di memoria senza una valutazione preventiva dell’impatto operativo.

3. Verifiche successive all’intervento

Dopo l’aggiornamento o l’applicazione delle misure temporanee, si raccomanda di:

• Verificare la versione PHP realmente utilizzata dai servizi web, non soltanto quella installata sul sistema operativo.
• Riavviare o ricreare i processi worker e i container interessati, ove necessario.
• Controllare i log del web server, di PHP e dei sistemi di monitoraggio per individuare anomalie compatibili con tentativi di sfruttamento.
• Verificare che i servizi esposti non utilizzino runtime vulnerabili rimasti attivi su host, pool o container differenti.
• Riesaminare i privilegi dei processi PHP, la segmentazione di rete e l’isolamento tra applicazione e sistema operativo, così da limitare le conseguenze di un’eventuale compromissione.

Le due vulnerabilità rappresentano un rischio significativo per le infrastrutture che utilizzano PHP per erogare servizi web, soprattutto quando raggiungibili da Internet e configurate con privilegi elevati o con un isolamento limitato.

La priorità operativa è identificare le installazioni interessate e applicare le versioni corrette. Le misure temporanee possono contribuire a ridurre l’esposizione, ma non sostituiscono l’aggiornamento. È inoltre opportuno includere nella verifica i servizi gestiti da fornitori esterni e le interfacce web integrate nei dispositivi di rete.

Si raccomanda di procedere con una verifica urgente degli asset PHP e con l’aggiornamento prioritario dei sistemi esposti, documentando eventuali eccezioni e i relativi interventi compensativi fino alla completa correzione.

#cybersecurity #cyberthreat #php