PHP2Shell: le falle critiche di PHP colpiscono soprattutto i server mod_php

PHP ha anticipato il rilascio di sicurezza a mercoledì 21 ottobre, alle 14:00 UTC, dopo che i dettagli di due vulnerabilità erano trapelati su Hacker News il giorno prima. Le correzioni sono incluse in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Entrambi i bug si trovano nell'interprete stesso, anziché in un CMS. Gli avvisi di sicurezza di PHP per CVE-2026-109618 e CVE-2026-109619 assegnano a ciascuna vulnerabilità un punteggio di 9,2 secondo CVSS 4.0 e confermano la possibilità di eseguire codice da remoto senza autenticazione con i privilegi del processo worker web.

La gestione dell'esaurimento della memoria lascia la memoria parzialmente inizializzata

La prima vulnerabilità riguarda il modo in cui PHP gestisce gli errori di esaurimento della memoria. In caso di OOM, l'interprete usa longjmp() per uscire dal contesto corrente, anche quando la memoria della richiesta è solo parzialmente inizializzata in quel momento. La procedura di chiusura legge poi quello stato come se fosse valido. Un attaccante può provocare l'OOM con una richiesta multipart che rimane al di sotto di post_max_size, per esempio tramite un numero illimitato di intestazioni per parte, campi file vuoti che non vengono conteggiati ai fini di max_file_uploads o nomi di campo annidati. La patch sostituisce longjmp() con una gestione non immediata dell'OOM al successivo punto sicuro della VM e un'uscita forzata tramite _exit() al superamento di una seconda soglia più alta.

La seconda vulnerabilità riguarda uno stato globale che persiste oltre la durata di una richiesta. Se un errore fatale interrompe un'operazione prima che questa reimposti il proprio stato, un campo globale continua a puntare a memoria heap già liberata. Quando la richiesta successiva sullo stesso worker legge quel valore prima della normale inizializzazione, si verifica un use-after-free. PHP elenca due percorsi confermati: l'impostazione fatal_error_backtraces in PHP 8.5 e il monitoraggio dell'avanzamento dei caricamenti tramite sessione, che è abilitato per impostazione predefinita e non richiede che l'applicazione chiami session_start().

Perché mod_php è il più esposto

Apache con mod_php chiama la procedura di chiusura della richiesta anche quando l'avvio della richiesta è già fallito. È sufficiente che la memoria si esaurisca mentre PHP analizza il corpo della richiesta, senza che venga eseguito alcun codice applicativo. PHP ha verificato la possibilità di eseguire codice arbitrario su mod_php con i limiti predefiniti di memoria e input. PHP-FPM termina un processo figlio il cui avvio fallisce, bloccando così il percorso diretto. Per la seconda vulnerabilità, PHP ha comunque confermato un exploit contro un normale pool FPM, anche se dipende dalla presenza di un'operazione adatta nell'applicazione. L'analisi del codice sorgente suggerisce che FrankenPHP si comporti come mod_php, mentre LSAPI è un potenziale bersaglio a determinate condizioni. L'elevata complessità dell'attacco nel vettore CVSS riflette il fatto che la build di PHP e la disposizione della memoria heap influiscono sull'affidabilità.

I tentativi di sfruttamento e il ruolo dell'IA

watchTowr afferma di osservare tentativi attivi di sfruttamento di entrambe le vulnerabilità, e Cloudflare ha dichiarato a The Hacker News di aver rilevato i primi attacchi prima del rilascio della patch. Finora non è stata confermata alcuna compromissione riuscita. I servizi governativi olandesi, tra cui DigiD e MijnOverheid, sono comunque stati messi offline per precauzione, e l'NCSC del Regno Unito consiglia di mettere offline i sistemi privi di patch se non sono disponibili altre opzioni.

Wiz Research ha scoperto i bug e li ha segnalati il 24 agosto. Secondo Wiz, Gemini 4 Argon e GPT-5.6 Sol hanno contribuito alla scoperta, allo sviluppo degli exploit e alla convalida delle patch, soprattutto nell'adattamento dell'exploit a ciascun bersaglio. Wiz riconosce inoltre il contributo di OpenAI e Calif nella scoperta e nel coordinamento. Il quadro è coerente con quanto Anthropic ha scritto di recente a proposito di IA capaci di autoreplicarsi che prendono di mira TV box economici, dove i modelli abbassano anche la soglia di accesso agli attacchi.

Cosa dovrebbero fare ora gli amministratori

L'aggiornamento è l'unica soluzione completa. Le distribuzioni Linux e i fornitori di versioni LTS hanno ricevuto le patch in anticipo e spesso le applicano anche a versioni precedenti mantenendone il numero, quindi controllate gli identificativi CVE nel registro delle modifiche anziché la stringa della versione. I rami 7.4, 8.0 e 8.1, non più supportati, ricevono solo backport minimi del codice sorgente. Se non potete aggiornare subito, PHP consiglia di impostare memory_limit=-1 a livello amministrativo, perché è proprio un limite prevedibile per ogni richiesta a rendere possibile l'exploit OOM confermato. Aggiungete session.upload_progress.enabled=0 e, su PHP 8.5, fatal_error_backtraces=0, quindi riavviate tutti i worker. Se la vostra applicazione non usa moduli multipart, bloccateli sul frontend. Nessuna di queste impostazioni costituisce una soluzione completa. Su un hosting condiviso o un NAS con un server web, verificate quale versione di PHP viene fornita dal vostro provider.