Vulnerabilità PHP, due falle critiche: patch urgenti per i server web

Il progetto PHP ha pubblicato il 21 ottobre 2026 aggiornamenti per due vulnerabilità critiche che possono consentire l’esecuzione di codice da remoto senza autenticazione. Per chi gestisce siti e applicazioni basati su PHP, la priorità è aggiornare il motore usato dal server e verificare che i processi attivi abbiano caricato la versione corretta. Aggiornare soltanto il CMS non risolve un difetto del linguaggio sottostante.

Le falle sono identificate come CVE-2026-109618 e CVE-2026-109619, entrambe con gravità 9,2 su 10 nella scala CVSS v4.0. Cloudflare dichiara di aver osservato traffico di attacco contro i propri clienti, mentre CloudLinux segnala tentativi corrispondenti ai modelli noti. Sono evidenze di attività ostile: non dimostrano che ogni installazione vulnerabile sia stata compromessa.

Due problemi nella gestione della memoria

La CVE-2026-109618 riguarda il comportamento di PHP quando un’operazione esaurisce la memoria disponibile. L’interruzione può lasciare dati interni parzialmente inizializzati; durante la chiusura della richiesta, il processo può trattarli come validi. L’advisory ufficiale documenta un impatto che può arrivare all’esecuzione di codice senza credenziali, con i privilegi dell’account che esegue il processo web.

PHP: News Archive - 2026

PHP is a popular general-purpose scripting language that powers everything from your blog to the most popular websites in the world.

2026

La CVE-2026-109619 riguarda invece uno stato interno che rimane accessibile dopo il rilascio della memoria alla quale faceva riferimento. Una richiesta successiva, gestita dallo stesso processo, può utilizzare quei riferimenti ormai invalidi. Anche in questo caso è stata dimostrata la possibilità di eseguire codice da remoto. Non significa automaticamente ottenere i privilegi di amministratore del sistema: l’impatto iniziale dipende dai permessi del processo coinvolto.

Quali server sono esposti

L’avviso PHP comprende le installazioni che elaborano richieste web tramite PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il progetto considera il rischio più alto per Apache con mod_php, dove un attacco dimostrato può attivarsi prima che inizi l’esecuzione del codice dell’applicazione. Un controllo inserito nel CMS non può quindi essere considerato una protezione sufficiente per quel percorso.

Il rischio non è identico in tutte le configurazioni. Gli advisory distinguono percorsi dimostrati e condizioni che dipendono da modalità di esecuzione, estensioni e applicazione. Per la seconda vulnerabilità è stata validata l’esecuzione remota anche in PHP-FPM attraverso il ciclo di gestione delle sessioni. Usare PHP-FPM, da solo, non permette quindi di considerare il server esente.

I tre punti da ricordare

• Gravità: due vulnerabilità critiche, entrambe CVSS v4.0 9,2.
• Correzione: aggiornare PHP e far caricare il codice corretto ai processi che servono il sito.
• Verifica: controllare il motore effettivamente usato dal web server, non soltanto il comando disponibile nel terminale.

Le versioni corrette e il caso dei pacchetti con backport

Il progetto PHP indica queste prime release corrette per i quattro rami mantenuti. La tabella si riferisce alle versioni distribuite dal progetto: per i pacchetti delle distribuzioni Linux e dei fornitori di supporto va controllato anche il relativo bollettino di sicurezza.

Le versioni sono riportate negli advisory ufficiali delle due vulnerabilità.

PHP 8.1 e i rami precedenti non ricevono più aggiornamenti dal progetto PHP, ma alcuni fornitori mantengono pacchetti con correzioni riportate su versioni meno recenti, i cosiddetti backport. Per questi pacchetti, il solo numero della versione originaria non basta a stabilire se la correzione sia presente: serve verificare la revisione distribuita e le indicazioni del fornitore. Il supporto di sicurezza ufficiale di PHP 8.2 termina inoltre il 31 dicembre 2026: applicare questa patch e pianificare la migrazione sono due esigenze distinte.

Come aggiornare e controllare il risultato

L’aggiornamento deve interessare tutte le installazioni PHP utilizzate sul server. Un singolo sistema può ospitare più versioni, più siti e processi separati. Le note di cPanel distinguono, per esempio, il PHP interno del pannello dai pacchetti EasyApache destinati ai siti. Anche Plesk e CloudLinux pubblicano indicazioni per componenti e piattaforme specifici: la disponibilità va verificata per l’ambiente effettivamente utilizzato.

Cloudflare deploys protections against php2shell vulnerability

Cloudflare has deployed default web application firewall (WAF) protections for newly disclosed PHP vulnerabilities before public disclosure. The rules use request and response signals to stop exploit attempts and prevent exposed data from reaching attackers.

Cloudflare BlogDaniele Molteni

Il comando php -v identifica il programma eseguito dalla shell, che può essere diverso dal motore configurato per il sito. Una verifica nel pannello o una pagina diagnostica eseguita dal web server permette di controllare il contesto corretto. Se si usa phpinfo(), l’accesso deve essere limitato e la pagina rimossa dopo il controllo: può mostrare percorsi, configurazioni, intestazioni e variabili d’ambiente. La procedura da concordare con il proprio amministratore o fornitore è questa:

1. Preparare un backup o uno snapshot, con una procedura di ripristino disponibile.
2. Individuare versioni e componenti in uso, compresi i motori assegnati ai diversi siti e quelli utilizzati dai pannelli.
3. Installare i pacchetti corretti attraverso il gestore della distribuzione o gli strumenti ufficiali del fornitore.
4. Riavviare i servizi e i processi interessati, seguendo le indicazioni per PHP-FPM, Apache o l’ambiente utilizzato: i vecchi processi non devono continuare a gestire richieste.
5. Controllare il risultato dal terminale e dal sito, verificando versione, revisione del pacchetto e funzionamento delle applicazioni.

WAF e misure temporanee non sostituiscono la patch

Cloudflare e CloudLinux hanno annunciato regole per intercettare alcuni schemi di attacco. Sono un livello aggiuntivo di protezione, non la rimozione del difetto dal server. Cloudflare stessa raccomanda di applicare gli aggiornamenti PHP anche in presenza delle protezioni WAF.

Anche le modifiche di configurazione indicate negli advisory ufficiali coprono percorsi specifici e non costituiscono una soluzione generale. Vanno valutate rispetto all’applicazione e applicate nel punto corretto della configurazione. La protezione completa da queste due falle richiede il codice corretto, distribuito dal progetto PHP o tramite un pacchetto del fornitore che includa le patch.

La lettura più grande

Il controllo decisivo riguarda ciò che il server sta realmente eseguendo. La presenza di un pacchetto aggiornato o di un pannello all’ultima versione non dimostra, da sola, che ogni sito abbia abbandonato il vecchio motore. La verifica deve arrivare fino al processo che riceve e gestisce le richieste.

Per i gestori, l’intervento si completa quindi con tre risultati verificabili: correzioni installate, processi aggiornati e controllo delle applicazioni esposte. Questa sequenza evita di confondere la disponibilità della patch con la sua effettiva applicazione.

Fonti

• PHP, avviso ufficiale del 21 ottobre 2026.
• PHP, advisory CVE-2026-109618 e advisory CVE-2026-109619.
• PHP, calendario delle versioni supportate.
• Cloudflare, attacchi osservati e protezioni WAF.
• CloudLinux, stato degli aggiornamenti e delle mitigazioni.
• cPanel, note di rilascio e Plesk, bollettino sui componenti interessati.
• Manuale PHP: opzioni della riga di comando e informazioni esposte da phpinfo.