Indice dell'articolo
Rischio e azione: il progetto PHP ha corretto due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che possono consentire esecuzione di codice da remoto senza autenticazione. Chi gestisce siti, portali, gestionali o pannelli basati su PHP deve aggiornare subito alle versioni 8.2.35, 8.3.36, 8.4.27 o 8.5.12, riavviare tutti i worker e verificare il servizio dalla stessa runtime usata in produzione. Il 23 ottobre è arrivata anche una mitigazione informativa aggiuntiva: mantenere disabilitato il progresso degli upload di sessione fino al prossimo rilascio ordinario.[1]
Quali server sono esposti
L’avviso riguarda le installazioni PHP che servono richieste web: PHP-FPM, Apache con mod_php, PHP-CGI, FrankenPHP e LiteSpeed. Il rischio più alto documentato è su mod_php, dove è stato dimostrato un attacco che può raggiungere il processo prima dell’esecuzione del codice applicativo. FPM riduce alcuni percorsi perché elimina il worker quando l’avvio della richiesta fallisce, ma non è considerato immune.[1][2]
Le due vulnerabilità hanno meccanismi diversi. CVE-2026-109618 sfrutta la gestione degli errori di memoria: richieste multipart costruite ad arte possono portare PHP in uno stato incoerente durante un out of memory e arrivare all’esecuzione di codice con l’account del worker web. CVE-2026-109619 riguarda invece stato globale appartenente a una richiesta che può sopravvivere dopo la liberazione della memoria ed essere riutilizzato da una richiesta successiva gestita dallo stesso worker.[2][3]
Versioni corrette e sistemi fuori supporto
Le release corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. PHP 8.1 e i rami precedenti non ricevono più correzioni dal progetto principale; alcune distribuzioni e fornitori LTS possono fornire backport, ma la presenza di un numero di versione precedente non dimostra da sola che la patch manchi. Va verificato il pacchetto del vendor, il changelog di sicurezza e la runtime effettivamente associata al sito o al pool.
Per WordPress non è previsto un aggiornamento del core per queste CVE: il componente da correggere è PHP sul server. La versione in uso può essere controllata in Strumenti → Salute del sito → Informazioni → Server, ma negli ambienti con più pool, container, chroot o pannelli hosting il dato deve essere confermato anche a livello infrastrutturale.[4]
Se non potete aggiornare immediatamente
Le mitigazioni riducono alcuni percorsi, ma non sostituiscono la patch. Per CVE-2026-109618 il progetto PHP indica di impostare amministrativamente memory_limit=-1, controllando che applicazioni, directory o pool non ripristinino un limite finito; suggerisce inoltre limiti conservativi per post_max_size e controlli sul proxy o web server per dimensione decodificata, campi, parti multipart, header e profondità degli input. Non usate RLIMIT_AS o RLIMIT_DATA come ripiego: possono ricreare il fallimento di allocazione vulnerabile.[1][2]
Per CVE-2026-109619 occorre impostare session.upload_progress.enabled=0 in una configurazione applicata prima del parsing della richiesta e riavviare ogni worker. Su PHP 8.5 va inoltre impostato fatal_error_backtraces=0. Il 23 ottobre PHP ha chiarito che la disabilitazione del progresso upload protegge anche da un ulteriore vettore, CVE-2026-115560, possibile solo con una combinazione insolita di handler di serializzazione della sessione; chi aveva già applicato la mitigazione non deve fare altro, ma deve mantenerla fino al prossimo bugfix release.[1]
Patching o risposta all’incidente?
Le fonti primarie consultate richiedono un intervento immediato, ma non dichiarano sfruttamento attivo osservato. L’attività iniziale è quindi patch management: inventario, backup, aggiornamento, riavvio e collaudo. Passate a incident response se emergono file o account inattesi, processi PHP anomali, crash o esaurimenti di memoria sospetti associati a upload, modifiche non autorizzate, connessioni insolite o lacune nei log. In quel caso preservate log, snapshot e telemetria esterna prima di ripulire o reinstallare.
Checklist operativa
- Inventariare siti, API, pannelli, pool FPM, container e runtime CLI.
- Identificare SAPI, versione PHP, origine del pacchetto e stato di supporto.
- Salvare configurazioni, backup recuperabili e piano di rollback.
- Aggiornare al pacchetto corretto del progetto o del vendor LTS.
- Riavviare Apache, PHP-FPM, LSAPI o i container interessati; non lasciare worker precedenti in memoria.
- Verificare la versione dalla runtime del sito, non soltanto dalla CLI globale.
- Se la patch è rinviata, applicare le mitigazioni documentate e isolare da Internet i sistemi che non possono essere protetti.[5]
- Collaudare login, upload, form, cron, code, cache, email, API e monitoraggio esterno.
- Separare gli errori applicativi post-update dagli indicatori di compromissione e conservare le evidenze prima della bonifica.
Devi aggiornare PHP su più siti o pool senza interrompere i servizi? Richiedi una verifica tecnica a MSP In Cloud.