Vulnerabilità critiche di PHP CVE-2026-109618 e CVE-2026-109619: cosa c'è da sapere

Il 21 ottobre 2026 il team di sicurezza di PHP ha rilasciato PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per correggere CVE-2026-109618 e CVE-2026-109619. Entrambe hanno un punteggio CVSS v4.0 di 9.2 e possono portare all'esecuzione di codice remoto senza autenticazione su qualsiasi installazione PHP che gestisca richieste web. Il team di PHP considera mod_php la configurazione più a rischio, con un exploit dimostrato che si attiva prima dell'esecuzione di qualsiasi codice applicativo. L'aggiornamento è l'unica soluzione completa. Red Sift ha analizzato la base clienti di Hardenize alla ricerca di host basati su PHP e ha avvisato direttamente i clienti interessati.

• Tutte le versioni a partire da PHP 5 potrebbero essere colpite, su PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed.
• PHP 8.1 e le versioni precedenti non riceveranno un rilascio ufficiale. Utilizzate un backport del vendor, le patch solo in formato sorgente del team di PHP per 7.4, 8.0 e 8.1, oppure effettuate l'upgrade.
• Le modifiche alla configurazione riducono l'esposizione ai vettori di attacco noti, ma non rendono sicura un'installazione.
• PHP è spesso incluso in appliance e prodotti di terze parti, quindi verificare la versione sui propri server non basta ad avere un quadro completo.

PHP alimenta una larga parte del web lato server, dai sistemi di gestione dei contenuti ai pannelli di amministrazione delle appliance di rete. Un bug che consente a una richiesta anonima di eseguire codice nel runtime PHP stesso, indipendentemente dall'applicazione che vi gira sopra, ha la portata più ampia che una vulnerabilità web possa avere.

Il team di PHP ha dato un preavviso il 20 ottobre e ha rilasciato le correzioni il giorno successivo. I CERT nazionali si sono mossi rapidamente. CERT-EU ha invitato le organizzazioni a prepararsi a un'applicazione immediata delle patch e a valutare l'isolamento delle applicazioni PHP esposte su Internet fino al rilascio delle correzioni. L'NCSC britannico ha chiesto alle organizzazioni di intervenire immediatamente, a partire dall'individuazione di tutti i sistemi su cui gira PHP.

Entrambi i bug risiedono nel modo in cui PHP gestisce lo stato di ciascuna richiesta all'interno di un worker, non nel codice applicativo.

• CVE-2026-109618, RCE tramite corruzione della memoria in condizioni di OOM (GHSA-w8hw-w9fx-j79w). Una condizione di memoria esaurita può interrompere PHP mentre i dati interni della richiesta sono solo parzialmente inizializzati. La fase di pulizia della richiesta tratta poi questi dati incompleti come validi, corrompendo la memoria. In determinate condizioni, un attaccante in grado di spingere una richiesta nel percorso OOM può sfruttare tale corruzione per eseguire codice.
• CVE-2026-109619, RCE tramite stato globale obsoleto (GHSA-6wmf-4rv5-p3rp). Lo stato interno associato a una richiesta può sopravvivere alla memoria che lo contiene. Una richiesta successiva gestita dallo stesso worker può utilizzare questo stato obsoleto prima che la normale inizializzazione lo azzeri, dando luogo a un use-after-free tra richieste diverse.

Il secondo bug è particolarmente rilevante per i worker di lunga durata, ovvero il modello di esecuzione di PHP-FPM, mod_php e FrankenPHP. Il team di PHP considera mod_php la configurazione più a rischio perché il relativo exploit dimostrato si attiva durante il parsing della richiesta, prima che questa raggiunga l'applicazione. Una regola di web application firewall legata alle route applicative non è in grado di intercettarlo.

Rientra nel perimetro qualsiasi installazione PHP che gestisca richieste web, inclusi PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. CERT-EU segnala che tutte le versioni a partire da PHP 5 potrebbero essere colpite: un numero di versione datato non è quindi un motivo per ridurre la priorità di un host, ma piuttosto per aumentarla, dato che PHP 8.1 e le versioni precedenti non riceveranno un pacchetto ufficiale.

La parte più difficile riguarda il PHP che non avete installato voi. Appliance, servizi in hosting e applicazioni di terze parti spesso includono PHP come componente interno, e questi prodotti vengono corretti solo quando il vendor rilascia un aggiornamento. NCSC-NL mantiene un inventario dei software con dipendenze da PHP potenzialmente colpiti, un ottimo punto di partenza per questa parte della ricerca.

In vista del rilascio di PHP, abbiamo analizzato gli host monitorati per l'intera base clienti di Hardenize per individuare quelli su cui gira PHP. Abbiamo poi associato tali host a ciascun cliente e contattato direttamente tutti gli interessati, fornendo l'elenco degli hostname potenzialmente esposti, l'orario di rilascio e i link agli advisory ufficiali. In questo modo i team hanno avuto visibilità sulla propria esposizione prima della pubblicazione delle versioni corrette e hanno potuto pianificare le finestre di manutenzione, anziché avviare l'attività di discovery dopo il rilascio.

Se siete clienti Hardenize e non avete ricevuto alcuna notifica, non abbiamo rilevato PHP sugli host che monitoriamo per voi; vi consigliamo comunque di effettuare alcune verifiche di base internamente. La scansione esterna vede solo ciò che un host rende visibile e copre esclusivamente gli asset presenti nel vostro account. I sistemi interni, gli host al di fuori del perimetro monitorato e i prodotti che nascondono il proprio runtime PHP devono comunque essere verificati da voi.

Se siete colpiti, applicate le patch il prima possibile dove potete. Le indicazioni seguenti riguardano gli host che non potete aggiornare oggi stesso.

• Individuate ogni installazione PHP, a partire dagli host esposti su Internet. Non filtrate per versione, poiché tutte le versioni potrebbero essere colpite. Includete container, immagini di base e tutto ciò che viene compilato da sorgente.
• Aggiornate a una versione corretta. Passate a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure installate il pacchetto corretto della vostra distribuzione. Le distribuzioni Linux e i vendor LTS hanno ricevuto le patch in anticipo. Se utilizzate rpms.remirepo.net, il team di PHP consiglia di passare ai pacchetti della distribuzione o di compilare da sorgente, perché quel repository non ha ricevuto gli aggiornamenti in giornata.
• Gestite i rami a fine supporto. Per 8.1 e versioni precedenti, utilizzate un backport del vendor, compilate a partire dai backport in formato sorgente del team di PHP per 7.4, 8.0 o 8.1, oppure effettuate l'upgrade.
• Riavviate tutti i worker. Un binario aggiornato non ha alcun effetto sui pool FPM o sui processi figli di Apache che eseguono ancora il vecchio codice.
• Rintracciate il PHP integrato in altri prodotti. Consultate gli advisory dei vendor per le appliance e i prodotti che incorporano PHP e applicate i relativi aggiornamenti non appena disponibili.
• Mitigate o isolate ciò che non potete aggiornare. Applicate le misure temporanee riportate di seguito. Se non è possibile, CERT-EU e NCSC consigliano entrambi di mettere offline l'applicazione esposta su Internet fino alla correzione.
• Cercate indicatori di compromissione sugli host rimasti esposti. L'NCSC raccomanda di verificare la presenza di backdoor prima o durante la remediation su tutti i sistemi che non è stato possibile aggiornare rapidamente.

• Impostate memory_limit=-1 in modo che le applicazioni non possano sovrascriverlo, ad esempio con php_admin_value nel pool FPM o nella configurazione di Apache. Assicuratevi che nessuna impostazione di pool, directory o applicazione reintroduca un limite finito. Un errore di allocazione sottostante può comunque raggiungere il percorso vulnerabile.
• Riducete post_max_size a 8M dove gli upload non sono necessari, o a 32M dove lo sono, e mantenete upload_max_filesize al di sotto di tale valore. Applicate a livello di web server o proxy limiti su dimensione delle richieste, numero di campi, numero di parti multipart, numero di header e profondità di annidamento, anche per le richieste prive di un Content-Length utilizzabile.
• Utilizzate un limite di memoria a livello di container o cgroup che termini solo il worker interessato. Non utilizzate RLIMIT_AS o RLIMIT_DATA, che possono innescare proprio l'errore di allocazione vulnerabile.

• Impostate session.upload_progress.enabled=0 in php.ini, nel pool FPM o nella configurazione del server, quindi riavviate tutti i worker. ini_set() e .user.ini vengono applicati troppo tardi per essere utili.
• Su PHP 8.5, impostate fatal_error_backtraces=0 e riavviate tutti i worker.
• Rimuovete le impostazioni per richiesta non valide o deprecate che generano messaggi diagnostici prima dell'inizializzazione. Sopprimere l'output con error_reporting, display_errors o @ non serve.
• Correggete gli errori fatali e i timeout di esecuzione che un attaccante può provocare, anche nelle callback, nell'elaborazione di upload o importazioni e nelle fasi di pulizia.

Queste misure bloccano i vettori di attacco confermati, non tutte le loro varianti. Consideratele una soluzione ponte in attesa delle patch.

La prima indicazione degli advisory di CERT-EU e NCSC è la stessa: individuare dove gira PHP. Per la maggior parte dei team è il passaggio più lento, perché la risposta è distribuita tra account cloud, domini acquisiti, siti di marketing e appliance dei vendor che nessuno ha mai inventariato.

Red Sift Hardenize individua e monitora costantemente i vostri asset esposti all'esterno e in cloud, così quando viene scoperta una vulnerabilità a livello di runtime come questa, l'elenco degli host esposti è già disponibile. È questo che ci consente di avvisare i clienti indicando hostname specifici prima ancora che vengano rilasciate le versioni corrette.

• Advisory di sicurezza e annunci di rilascio di PHP, 20 e 21 ottobre 2026
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• CERT-EU Security Advisory 2026-018
• NCSC, problema di sicurezza critico che interessa PHP
• Inventario NCSC-NL php2shell dei software colpiti