Le vulnerabilità critiche annunciate per #PHP impongono di ridurre subito l’esposizione. Per i sistemi rimasti su PHP 8.1 e precedenti, il problema comprende anche l’assenza di manutenzione ufficiale.
Nota temporale: articolo preparato il 21 ottobre 2026 sulla base delle informazioni disponibili prima della pubblicazione delle correzioni annunciate. Versioni vulnerabili, release corrette e copertura delle mitigazioni devono essere aggiornate alla pubblicazione del bollettino definitivo. L’articolo viene aggiornato con il susseguirsi degli eventi.
TOOLS: tra le cose utili che stanno emergendo segnalo che online si trovano diversi strumenti per identificare se il tuo ambiente PHP è impattato dalle vulnerabilità e da #PHP2Shell oppure se è sicuro. Come questo e questo.
Una #patch annunciata non protegge un server esposto. Tra il preavviso di una vulnerabilità critica e l’installazione effettiva della correzione esiste una finestra operativa nella quale il rischio va gestito con gli strumenti già disponibili: inventario, configurazione, controllo degli accessi e, quando necessario, isolamento. È questa la priorità che emerge dal caso PHP2Shell, il nome con cui vengono indicate pubblicamente le vulnerabilità associate a #CVE-2026-109618 e CVE-2026-109619. Aspettare il pacchetto del proprio repository senza intervenire sull’esposizione significa lasciare che sia il calendario della distribuzione a determinare la propria capacità di difesa.
Il preavviso ufficiale del PHP #Security Team, datato 20 ottobre, annuncia una release di #sicurezza per il 21 ottobre 2026 alle 14:00 UTC, le 16:00 italiane. Le vulnerabilità sono due, entrambe con punteggio CVSS v4.0 pari a 9,2. Il team invita a prepararsi immediatamente all’aggiornamento e si riserva di anticipare il rilascio se emergessero dettagli pubblici o evidenze di sfruttamento. Il documento rinvia però alla release la pubblicazione dei dettagli tecnici, delle versioni interessate e di quelle corrette. Una distinzione essenziale per evitare di trasformare le informazioni circolate anticipatamente in un bollettino ufficiale che ancora non c’è.
Anche #CERT-EU tratta la possibilità di esecuzione remota di codice richiamando le informazioni trapelate e segnala una possibile esposizione estesa alle versioni storiche, da PHP 5 in avanti. Quel “possibile” va conservato: la verifica del perimetro richiede i dettagli del produttore. La raccomandazione operativa è invece esplicita: identificare le applicazioni PHP, preparare il patching immediato e considerare l’isolamento dei servizi pubblici quando non sia possibile correggerli tempestivamente.
Il dettaglio su cui si stanno concentrando le prime analisi è il tracciamento nativo dell’avanzamento degli upload. L’analisi preliminare pubblicata da Upwind associa le due vulnerabilità a errori di tipo use-after-free nel relativo gestore. È un’attribuzione tecnica del ricercatore, da distinguere dalla conferma ufficiale del progetto PHP. La conseguenza difensiva da valutare è comunque concreta: rimuovere, dove inutilizzata, una funzionalità del runtime raggiungibile attraverso l’elaborazione delle richieste.
La direttiva da esaminare è:
session.upload_progress.enabled = OffPHP documenta questa funzione come abilitata per impostazione predefinita. Serve a registrare nella sessione l’avanzamento degli upload, così che un’altra richiesta possa consultarlo. Disabilitarla interrompe quel tracciamento, senza disabilitare di per sé il caricamento dei file o le normali sessioni applicative; occorre verificare se il software utilizza proprio quel meccanismo per mostrare l’avanzamento. La documentazione distingue inoltre questa elaborazione dall’esecuzione ordinaria dello script: affidare la protezione soltanto a controlli inseriti nel codice applicativo rischia quindi di collocare la difesa troppo tardi.
La formulazione corretta è “riduzione preventiva della superficie esposta”. In assenza di una conferma del produttore, non è giustificato promettere che questa singola modifica neutralizzi entrambe le CVE in ogni configurazione. Lo stesso vale per un filtro sulle richieste multipart: può essere valutato a monte del runtime come misura temporanea, ma richiede verifica della copertura e dell’impatto sulle funzioni legittime. Un sito che accetta allegati, importazioni o moduli multipart può perdere funzionalità importanti. Quando il rischio residuo resta inaccettabile, limitare l’accesso al servizio offre una scelta più controllabile di una regola applicata alla cieca.
L’intervento deve essere verificato nell’ambiente che serve realmente il traffico web. Una modifica al php.ini della riga di comando non dimostra che il pool PHP-FPM del sito utilizzi la stessa configurazione. Bisogna controllare ciascun runtime, virtual host e container interessato, applicare l’eventuale reload richiesto e verificare il valore effettivo attraverso il web server. La direttiva è classificata INI_PERDIR: non bisogna affidarsi a un ini_set() dentro l’applicazione come rimedio per la richiesta già in elaborazione. Negli hosting condivisi va verificato il meccanismo consentito dal provider e il tempo necessario perché la modifica diventi effettiva.
Il problema più duraturo riguarda però i sistemi per i quali l’aggiornamento ufficiale non è previsto. Al 21 ottobre 2026, i rami mantenuti dal progetto PHP sono 8.2, 8.3, 8.4 e 8.5; PHP 8.1 e precedenti sono fuori supporto upstream. Conviene scrivere esplicitamente “PHP 8.2 e successivi ancora supportati”, evitando una formula come “PHP > 8.1”, che può essere letta in modo ambiguo. Essere nel ramo 8.x, da solo, non garantisce manutenzione. Inoltre PHP 8.2 raggiungerà la fine del supporto di sicurezza il 31 dicembre 2026: una migrazione d’emergenza verso quel ramo avrebbe già un orizzonte molto breve.
Questo non equivale a sostenere che nessun fornitore possa distribuire correzioni per una versione precedente. Distribuzioni e servizi di manutenzione estesa possono offrire backport secondo politiche proprie. Chi dipende da questi pacchetti deve ottenere una conferma specifica per entrambe le CVE, verificando advisory, build e copertura contrattuale. La presenza di una vecchia versione sul server non prova automaticamente l’assenza di backport; allo stesso modo, una generica promessa di “supporto legacy” non prova che queste vulnerabilità siano state corrette. Per i rami fuori supporto, non si può pianificare la difesa contando su una normale release del progetto PHP.
La sequenza operativa è dunque immediata: censire i servizi, ridurre l’esposizione, verificare le misure e predisporre l’aggiornamento. Quando le correzioni saranno disponibili, andranno installate senza rinviare l’intervento perché è già presente una mitigazione. L’aggiornamento dovrà raggiungere anche immagini, repliche e template usati per ricreare i servizi, altrimenti una successiva distribuzione potrebbe reintrodurre il runtime vulnerabile. Se emergessero indizi di compromissione, il patching andrebbe accompagnato da una verifica dell’incidente: correggere il difetto non elimina eventuali accessi persistenti già ottenuti.
PHP2Shell rende visibile il costo operativo del software fuori manutenzione. Un’applicazione può continuare a funzionare per anni mentre perde progressivamente la possibilità di essere difesa attraverso gli aggiornamenti ordinari. La mitigazione serve a guadagnare tempo controllando il rischio; quel tempo deve finanziare la correzione o la migrazione, con una scadenza e un responsabile. La disponibilità futura di una patch non è un motivo per rimandare la difesa di oggi.
AggiornamentiAlle 16.00 ora italiana sono state rilasciate le patch che ovunque nel mondo si sta iniziando ad applicare:
PHP 8.5 https://www.php.net/archive/2026.php#2026-10-21-4
PHP 8.4 https://www.php.net/archive/2026.php#2026-10-21-3
PHP 8.3 https://www.php.net/archive/2026.php#2026-10-21-2
PHP 8.2 https://www.php.net/archive/2026.php#2026-10-21-1
Fonti:
[1] PHP Security Team, Upcoming Critical PHP Security Release: https://www.php.net/archive/2026.php#2026-10-20-1
[2] CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
[3] Upwind, Initial Assessment — PHP2Shell: https://www.upwind.io/feed/initial-assessment-php2shell-two-critical-unpatched-php-rces-cve-2026-109618-cve-2026-109619
[4] PHP Manual, Session Runtime Configuration: https://www.php.net/manual/en/session.configuration.php
[5] PHP Manual, Session Upload Progress: https://www.php.net/manual/en/session.upload-progress.php
[6] PHP, Supported Versions: https://www.php.net/supported-versions.php
