Le correzioni della vulnerabilità PHP chiudono due falle critiche di RCE
La vulnerabilità PHP corretta il 21 ottobre 2026 consiste in due falle critiche che possono consentire a un aggressore non autenticato, cioè che non ha effettuato l’accesso, di eseguire da remoto codice su un web server. PHP ha rilasciato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per risolvere entrambi i problemi. I siti web che utilizzano WordPress, Drupal, Magento, Joomla, Laravel o qualsiasi altra applicazione PHP sono esposti quando l’installazione PHP sottostante rimane vulnerabile.
Il rischio riguarda i principali modi in cui PHP elabora le richieste web, tra cui PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP considera mod_php la configurazione a rischio più elevato perché una richiesta malevola può raggiungere la falla prima che inizi l’esecuzione del codice dell’applicazione del sito. Il problema si trova nell’interprete PHP, il software che esegue il codice PHP, e non in uno specifico sistema di gestione dei contenuti o plugin.
Le falle sono CVE-2026-109618 e CVE-2026-109619, entrambe classificate Critical con un punteggio di 9,2 secondo CVSS v4.0, un sistema standard per descrivere la gravità delle vulnerabilità. CVE-2026-109618 riguarda l’out-of-memory handling. PHP può essere interrotto mentre le informazioni interne della richiesta sono state preparate solo in parte, dopodiché il cleanup può trattare erroneamente informazioni non valide come legittime. CVE-2026-109619 consente alle informazioni interne specifiche di una richiesta di permanere dopo che la relativa memoria è stata rilasciata. Una richiesta successiva elaborata dallo stesso worker, il processo PHP che gestisce le richieste, può utilizzare tali informazioni obsolete prima che il normale setup le elimini.
Wiz Research, che ha segnalato le vulnerabilità a PHP, afferma che ogni release di PHP a partire dalla 5.4 è interessata da almeno una falla. I suoi ricercatori hanno dimostrato la remote code execution sulle più recenti immagini container di WordPress, Drupal e Joomla, nonché lo sfruttamento di una semplice applicazione Hello World. Un container è un pacchetto isolato che contiene un’applicazione e il software di cui ha bisogno. I ricercatori hanno inoltre dimostrato di poter leggere la memoria dei worker PHP senza prima ottenere l’esecuzione di codice. Tale memoria può contenere password, chiavi API e token di accesso. Wiz afferma che la patch di PHP corregge il problema sottostante, comprese ulteriori varianti.
I dettagli sono trapelati il 20 ottobre, prima della divulgazione coordinata prevista, e il problema è diventato noto come PHP2Shell. La società di sicurezza watchTowr ha confermato prima del rilascio che le vulnerabilità erano reali. Alle 07:34 UTC del 21 ottobre, diversi partner di hosting hanno segnalato a Patchstack incidenti di sfruttamento attivo. Cloudflare ha segnalato i primi attacchi alle 07:43 UTC e ha distribuito le prime regole di Web Application Firewall, che esaminano e filtrano le richieste web, per i percorsi di exploit noti. Alle 13:52 UTC, PHP ha pubblicato le release corrette. Cinque minuti dopo, Patchstack ha dichiarato che la propria telemetria mostrava attività di probing, ma in quel momento nessuna prova concreta di violazioni, avvertendo tuttavia che la situazione avrebbe potuto cambiare quando i dettagli delle patch fossero diventati pubblici.
Diversi servizi sono stati messi offline a scopo precauzionale prima dell’arrivo delle correzioni. L’emittente olandese NOS ha segnalato interruzioni che hanno interessato DigiD, MijnOverheid, il sito web della Camera dei rappresentanti dei Paesi Bassi, Tweakers e il sito del National Cyber Security Centre olandese. ITmedia ha segnalato interventi di manutenzione d’emergenza presso servizi giapponesi tra cui Kodmon, Shadowverse: Worlds Beyond e Sakura Rental Server, ritenuti collegati alla vulnerabilità, mentre BASE e Xserver avrebbero dovuto fare altrettanto. Anche gli sviluppatori di The SEO Framework hanno dichiarato di aver messo offline i propri server. CERT-EU ha pubblicato un avviso, mentre il National Cyber Security Centre del Regno Unito ha sollecitato aggiornamenti immediati.
Cloudflare afferma che le sue regole firewall iniziali sono disponibili per tutti i clienti, compresi gli utenti gratuiti, ma le descrive soltanto come una barriera temporanea. Sono utili solo quando l’origin server accetta traffico esclusivamente attraverso Cloudflare. Non sostituiscono l’aggiornamento di sicurezza di PHP, perché potrebbero rimanere disponibili altri percorsi verso il server o varianti di attacco precedentemente sconosciute.
Gli amministratori devono installare PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure ottenere dal fornitore del sistema operativo il corrispondente pacchetto corretto. Le distribuzioni Linux e i fornitori di supporto a lungo termine hanno ricevuto le patch in anticipo. PHP ha avvertito che i pacchetti rpms.remirepo.net gestiti da volontari non sarebbero stati aggiornati quel giorno, raccomandando invece i pacchetti della distribuzione o una build dal codice sorgente. PHP 8.1 e le versioni precedenti non ricevono più correzioni dal progetto PHP, sebbene diversi manutentori esterni abbiano reso la correzione backported, adattandola cioè alle release meno recenti.
La disponibilità dei pacchetti variava al 22 ottobre. I pacchetti di packages.sury.org e ppa:ondrej/php coprivano i rami end-of-life da PHP 5.6 fino a 8.1, mentre Ubuntu 22.04 aveva corretto il proprio pacchetto PHP 8.1 con php8.1 8.1.2-1ubuntu2.28. Ubuntu Pro copriva le release dalla 14.04 alla 20.04, con la 14.04 e la 16.04 che richiedevano l’add-on Legacy. Freexian ELTS copriva PHP 7.0 su Debian 9, 7.3 su Debian 10 e 7.4 su Debian 11. Il supporto di Debian per Debian 11 era terminato il 31 agosto 2026, sebbene il pacchetto php7.4 di Sury offrisse un’opzione gratuita.
AlmaLinux ha pubblicato correzioni per gli stream PHP sulle versioni 8, 9 e 10, compresi gli stream end-of-life, ma non ha garantito correzioni future. Red Hat disponeva di correzioni per php:7.4 su RHEL 8 e PHP 8.0 su RHEL 9, ma non per stream ritirati come 7.2 e 8.1 su RHEL 9. Remi copriva 7.4, 8.0 e 8.1 su RHEL 8 e 9, ma non 7.2 o 7.3. CloudLinux ha rilasciato pacchetti EasyApache 4 ea-php corretti, da ea-php52 a ea-php85, per cPanel. TuxCare ELS stava distribuendo correzioni specifiche per ciascun ramo, mentre Zend ha dichiarato che le sue build con supporto a lungo termine di PHP 7.2, 7.3, 7.4 e 8.1 erano già corrette al momento del rilascio. Le immagini Docker ufficiali di PHP non hanno ricevuto alcuna correzione per PHP 8.1 o versioni precedenti.
PHP ha inoltre pubblicato source backport per 7.4, 8.0 e 8.1 come ultima risorsa. Si tratta di mitigazioni limitate, non di un rinnovo del supporto: disabilitano il session upload progress indipendentemente da php.ini e non aggiungono alcun hard memory limit. Su Ubuntu e sulle build Sury meno recenti che mantengono i numeri di versione upstream, gli amministratori devono controllare nei changelog dei pacchetti la presenza di entrambi i CVE. I pacchetti Debian e quelli Sury più recenti possono indicare soltanto una nuova versione upstream, mentre i changelog degli stream RHEL 8.2 e 8.3 possono riportare soltanto rebase; in questi casi PHP consiglia di utilizzare dnf updateinfo. Se non esiste una correzione del fornitore, occorre passare a una release supportata. PHP 8.2 riceverà correzioni di sicurezza solo fino al 31 dicembre 2026 e PHP 8.3 fino al 31 dicembre 2027, pertanto PHP consiglia di puntare alla versione 8.4 o 8.5.
Ogni installazione PHP richiede attenzione, compresi i server di produzione, i container, i siti di staging, le appliance e i prodotti di terze parti che includono PHP. I plugin di correzione non ufficiali e gli snippet di codice copiati devono essere evitati perché non sono verificati e potrebbero compromettere il funzionamento di un sito. Se un servizio ad alto rischio non può essere corretto immediatamente, metterlo offline o attivare la modalità di manutenzione è un’opzione raccomandata anche dal NCSC del Regno Unito.
Solo l’aggiornamento corregge completamente la vulnerabilità PHP.