PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 correggono due falle critiche

Una richiesta HTTP costruita ad arte, inviata senza alcuna autenticazione, può far eseguire codice su un server prima ancora che parta l’applicazione web: è l’exploit dimostrato dal progetto PHP contro le installazioni con Apache e mod_php. Il 21 ottobre 2026 sono usciti PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, che correggono due vulnerabilità critiche (CVE-2026-109618 e CVE-2026-109619). Chi gestisce un sito, un server o un’applicazione in PHP deve controllare quale versione gira davvero sul web server e aggiornarla, riavviando poi i processi.

Le versioni da installare

Secondo l’avviso pubblicato su php.net, il progetto invita tutti gli utenti ad aggiornare subito. I sorgenti si scaricano dalla pagina dei download, dove ci sono anche i binari per Windows. Le distribuzioni Linux e i fornitori di supporto a lungo termine hanno ricevuto le patch in anticipo: i pacchetti aggiornati vanno cercati presso il proprio fornitore.

PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto. Il team di sicurezza ha però preparato backport minimi dei sorgenti per PHP 7.4, 8.0 e 8.1, pensati per chi compila da sé o non ha un fornitore LTS. L’allerta dell’ACN (Agenzia per la cybersicurezza nazionale) riporta invece che per le versioni 8.1 e precedenti il vendor non rilascerà workaround né patch, vista la fine del supporto. Le strade indicate da php.net sono due: chiedere al proprio fornitore un backport oppure passare a una versione supportata.

Chi è esposto e come agiscono le due falle

Secondo php.net sono a rischio le installazioni che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è massimo con mod_php. Entrambe le falle hanno un punteggio CVSS v4.0 di 9,2, come indicano ACN, CERT-AgID e Ubuntu.

• CVE-2026-109618: quando la memoria si esaurisce, PHP può interrompersi mentre i dati interni della richiesta sono inizializzati solo in parte, e la pulizia successiva li tratta come validi. L’ACN cita come esempio la gestione delle richieste multipart e parla di esecuzione di codice con i privilegi del processo worker PHP.
• CVE-2026-109619: lo stato interno di una richiesta può sopravvivere alla liberazione della memoria che lo sostiene, e una richiesta successiva gestita dallo stesso worker può usarlo prima della normale inizializzazione. Tra i percorsi indicati dall’ACN ci sono il monitoraggio dell’avanzamento degli upload di sessione e, su PHP 8.5, i backtrace degli errori fatali.

CERT-AgID segnala che online circolano diversi proof-of-concept che dichiarano di sfruttare le falle; la loro efficacia non risulta ancora pienamente verificata, ma aumenta il rischio di tentativi contro i sistemi esposti. Chiarisce anche che le falle riguardano l’interprete: possono toccare CMS, applicazioni web, appliance e interfacce di amministrazione basate su PHP, e aggiornare solo il CMS o i suoi plugin non le corregge.

Come controllare cosa gira sul server

CERT-AgID avverte che php -v mostra la versione da riga di comando, che può differire da quella usata dal web server. Propone quindi di verificare prima la modalità di esecuzione e, per le distribuzioni che applicano le correzioni in backport, di leggere gli avvisi del distributore. I comandi suggeriti per Linux:

• apachectl -M 2>/dev/null | grep -i php per vedere se Apache carica il modulo PHP;
• ps -eo pid,ppid,args | grep '[p]hp-fpm' per trovare i processi PHP-FPM attivi;
• php -v per la versione da riga di comando.

Dopo l’aggiornamento bisogna accertarsi che Apache o PHP-FPM siano stati riavviati. L’ACN raccomanda inoltre un’analisi retrospettiva di log ed eventi, in cerca di richieste HTTP anomale, errori ricorrenti di memoria esaurita, interruzioni inattese dei processi PHP, processi imprevisti o modifiche ai file dell’applicazione. CERT-AgID cita tra i segnali gli errori «Allowed memory size exhausted».

Ubuntu: pacchetti già pronti

Il blog di Ubuntu spiega che le due falle circolano anche con il soprannome php2shell e che le correzioni sono uscite per tutte le release supportate. Secondo Ubuntu, la PHP Foundation aveva fissato la divulgazione al 22 ottobre alle 14:00 UTC, anticipata al 21 ottobre alla stessa ora a causa di una fuga di notizie.

Per la 20.04 e le precedenti le correzioni passano da Ubuntu Pro con l’Expanded Security Maintenance, gratuito fino a 5 macchine. Per aggiornare si usa sudo apt update && sudo apt upgrade, poi si riavvia l’applicazione, per esempio con sudo systemctl restart apache2 se si usa mod_php. Gli aggiornamenti automatici, attivi di default dalla 16.04, applicano le patch entro 24 ore, ma il riavvio resta necessario.

Se non si può aggiornare subito

Secondo php.net solo l’aggiornamento risolve il problema; le misure seguenti riducono l’esposizione a percorsi di attacco specifici ma non rendono sicura l’installazione.

• Per CVE-2026-109618: memory_limit=-1, preferibilmente in un punto che le applicazioni non possano sovrascrivere (php_admin_value nel pool FPM o nella configurazione di Apache), verificando che nessuna impostazione di pool, directory o applicazione reimposti un limite finito. Attenzione: così si elimina il limite di memoria PHP per richiesta, e un’allocazione fallita a monte può comunque raggiungere il percorso vulnerabile. Va affiancato un limite di container o cgroup come confine di disponibilità, preferibilmente con una policy che termini solo il worker coinvolto; non lo si sostituisce con RLIMIT_AS o RLIMIT_DATA, che possono causare proprio il fallimento di allocazione vulnerabile. Poi post_max_size a 8M (32M se servono gli upload) con upload_max_filesize più basso, e limiti su dimensione decodificata, campi, parti multipart, intestazioni e annidamento a livello di web server o proxy, anche per richieste senza Content-Length utilizzabile.
• Per CVE-2026-109619: session.upload_progress.enabled=0 e riavvio di tutti i worker, e su PHP 8.5 anche fatal_error_backtraces=0. Vanno impostati in php.ini, nel pool FPM o nella configurazione del server, non con ini_set() né con .user.ini.

Il ruolo di OpenAI nella scoperta

Nel suo annuncio OpenAI racconta di aver guidato per due mesi una coalizione con maintainer, ricercatori e fornitori di sicurezza. Calif ha individuato una falla critica usando GPT-5.6 Sol nell’ambito dell’iniziativa Patch the Planet, mentre Wiz ha scoperto e segnalato in modo indipendente entrambe le vulnerabilità. Le correzioni sono state guidate dai maintainer di PHP. OpenAI mette a disposizione un PHP version checker come skill di Codex, per individuare le versioni potenzialmente vulnerabili, da usare insieme alle indicazioni di PHP e del proprio fornitore. Nello stesso testo propone un processo in cinque fasi per gestire le vulnerabilità critiche nel software molto diffuso.

Leggi anche

• Aggiornamento Chrome: come farlo su Windows, Mac, Linux e Android
• Chrome 156 corregge 353 vulnerabilità, 6 critiche: aggiornare