Falle critiche in PHP: cosa fare subito (CVE-2026-109618)

Pubblicato 23 ottobre 2026

Author Sigilium Intelligence

Perché questa volta è diverso

La maggior parte delle vulnerabilità che leggete nei bollettini riguarda un plugin, un CMS o una libreria. Queste no: stanno nel motore di PHP, nel modo in cui gestisce la memoria tra una richiesta HTTP e l’altra. Per questo aggiornare WordPress, Laravel, Drupal o i plugin non serve: il codice dell’applicazione è corretto, è l’interprete sotto di lui a essere vulnerabile.

E in uno dei casi dimostrati l’attacco parte prima che il codice dell’applicazione venga eseguito: un sito con un’applicazione scritta perfettamente è esposto quanto uno scritto male.

Le due vulnerabilità, in breve

CVE-2026-109618, corruzione della memoria in caso di esaurimento (OOM). Quando PHP finisce la memoria disponibile durante l’avvio di una richiesta, interrompe il lavoro lasciando alcune strutture interne inizializzate a metà. La fase di chiusura della richiesta le tratta poi come valide. Un attaccante può provocare l’esaurimento con una richiesta multipart costruita ad arte (form e upload di file) che resta entro i limiti configurati, per esempio con un numero enorme di intestazioni in una singola parte. Secondo l’advisory l’esecuzione di codice è stata dimostrata via HTTP contro Apache con mod_php e con i limiti di default.

CVE-2026-109619, stato “stantio” tra una richiesta e l’altra. I processi PHP che servono il web vengono riutilizzati per più richieste. Dopo un errore fatale, alcune strutture interne possono continuare a puntare a memoria già liberata, e una richiesta successiva servita dallo stesso processo può usarle prima che vengano azzerate: un classico use-after-free. Tra i percorsi confermati c’è il monitoraggio dell’avanzamento degli upload nelle sessioni, attivo di default, che non richiede nemmeno che l’applicazione apra una sessione.

Chi è esposto

Secondo il progetto PHP, ogni installazione che serve richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto è su Apache con mod_php, dove l’attacco è stato dimostrato senza alcun prerequisito lato applicazione.

Su PHP-FPM, la configurazione più comune con Nginx, il quadro è più sfumato: l’advisory non riporta un exploit completo per la prima vulnerabilità e, per la seconda, un percorso validato che richiede condizioni specifiche dell’applicazione. “Più difficile” però non significa “al sicuro”: la correzione va applicata comunque.

Versioni corrette

Ramo	Vulnerabile	Corretto
PHP 8.5	prima della 8.5.12	8.5.12
PHP 8.4	prima della 8.4.27	8.4.27
PHP 8.3	prima della 8.3.36	8.3.36
PHP 8.2	prima della 8.2.35	8.2.35
PHP 8.1 e precedenti	tutte	nessuna release ufficiale

Due note importanti:

PHP 8.1, 8.0 e 7.4 non ricevono più aggiornamenti. Vista la gravità, il team di PHP ha pubblicato delle patch minime in sorgente per questi tre rami, ma non ci sono pacchetti pronti: servono la vostra distribuzione Linux, un fornitore di supporto esteso oppure, meglio, il passaggio a una versione supportata. Per le versioni ancora più vecchie non esiste alcuna correzione.
PHP 8.2 esce dal supporto il 31 dicembre 2026. Se aggiornate oggi alla 8.2.35, mettete in agenda la migrazione a un ramo più recente nelle prossime settimane.

Cosa fare oggi

1. Scoprite che versione state usando davvero. Da terminale php -v mostra la versione della riga di comando, che non sempre coincide con quella che serve il sito. Controllate anche php-fpm -v (o php-fpm8.3 -v e simili) oppure, in un ambiente non pubblico, la pagina phpinfo().

2. Aggiornate, nel modo giusto per la vostra infrastruttura.

Hosting condiviso o gestito: molti provider hanno già aggiornato i server. Verificate con il vostro fornitore, e se il pannello vi lascia scegliere la versione di PHP, assicuratevi di non essere su un ramo fuori supporto.
Server o VPS: aggiornate i pacchetti PHP dal repository della vostra distribuzione e verificate che la versione installata sia quella corretta. Se usate Laravel Forge, attenzione: secondo la documentazione di Forge gli aggiornamenti di sicurezza automatici non aggiornano PHP, va fatto a mano per ogni versione installata.
Container Docker: aggiornare il server non basta. Va ricostruita l’immagine partendo da un’immagine base con la versione corretta, e poi va ridistribuita.

3. Riavviate tutto ciò che esegue PHP. Un aggiornamento non ha effetto finché i processi in esecuzione non ripartono. Oltre a PHP-FPM o Apache, contano i processi di lunga durata: code e worker (php artisan queue:restart), Horizon, Octane, Reverb, demoni e consumer avviati da riga di comando.

4. Verificate. Ripetete il controllo del punto 1 e confermate che sia la riga di comando sia il processo che serve il web riportino la versione corretta.

Se non potete aggiornare subito

Il progetto PHP indica alcune misure che riducono l’esposizione a percorsi di attacco specifici, ma non rendono sicura un’installazione. Vanno applicate a livello di server (php.ini, pool di FPM, configurazione di Apache) e seguite da un riavvio di tutti i processi; ini_set() e .user.ini agiscono troppo tardi.

session.upload_progress.enabled = 0: blocca i percorsi confermati che passano dalle sessioni. Se l’applicazione non usa questa funzione, conviene lasciarla disattivata anche dopo l’aggiornamento.
Su PHP 8.5, fatal_error_backtraces = 0: blocca il percorso confermato legato ai backtrace degli errori fatali.
Limiti stretti sulle richieste: post_max_size = 8M se l’applicazione non riceve upload, 32M se li riceve, con upload_max_filesize più basso. Dove possibile, imponete limiti anche sul reverse proxy (dimensione del corpo, numero di parti e di intestazioni) e bloccate le richieste multipart se l’applicazione non le usa.
memory_limit = -1 impostato in modo che le applicazioni non possano sovrascriverlo: elimina il limite che un attaccante può far scattare, ma non ogni esaurimento di memoria possibile. Da affiancare a un limite di memoria a livello di container o cgroup, e mai a RLIMIT_AS o RLIMIT_DATA, che riaprono proprio il percorso vulnerabile.

Sono misure tampone, utili per guadagnare qualche giorno. Non sostituiscono l’aggiornamento.

Quanto è urgente

Molto. Il 22 ottobre erano già disponibili diverse prove di concetto pubbliche. Rapid7 osserva che ciascuna funziona solo con una combinazione specifica di sistema operativo, versione di PHP e web server, e segnala tentativi di sfruttamento; watchTowr riporta attacchi osservati sulla propria rete di honeypot già dal 21 ottobre.

La storia delle vulnerabilità di questo tipo è sempre la stessa: gli exploit diventano più affidabili nel giro di giorni, e da quel momento la scansione di internet alla ricerca di server non aggiornati è automatica.

Come lo abbiamo gestito noi

Il 20 ottobre il progetto PHP ha preannunciato il rilascio per il giorno dopo alle 14:00 UTC, le 16:00 in Italia, senza dettagli sulle vulnerabilità. Quel preavviso cambia i tempi: una patch di sicurezza, una volta pubblicata, indica anche a chi attacca dove si trova il difetto. Il momento più rischioso è quindi subito dopo il rilascio, quando i dettagli sono pubblici e la maggior parte dei server non è ancora aggiornata.

Abbiamo scelto la misura più prudente: prima delle 16:00 abbiamo spento PHP-FPM sui server PHP dei nostri clienti. Qualche ora di servizio sospeso contro il rischio di un accesso al server e di una violazione dei dati. Senza un interprete in esecuzione non c’è niente da attaccare.

Dopo il rilascio abbiamo proceduto server per server:

PHP 8.3, 8.4 e 8.5: aggiornamento alla versione corretta e riavvio dei processi PHP. Davanti ai siti abbiamo messo Cloudflare, per avere il suo WAF come livello di protezione in più.
PHP 8.1: per un cliente non esisteva un pacchetto aggiornato, e abbiamo compilato PHP dal sorgente con le patch minime pubblicate dal team di PHP per quel ramo.
Versioni non aggiornabili: abbiamo applicato le misure indicate dal progetto PHP e informato i clienti che è necessario valutare nei prossimi giorni un aggiornamento del sistema operativo, per portare PHP almeno alla 8.4, insieme alla riscrittura delle parti di codice che non sono compatibili.

Le misure tampone e il WAF fanno guadagnare tempo, ma non risolvono il problema: su quei server la soluzione resta l’aggiornamento.

Il problema vero: il PHP che nessuno aggiorna

Aggiornare un server PHP 8.4 richiede pochi minuti. Il caso difficile è un altro: il gestionale scritto anni fa che gira ancora su PHP 7.4, il sito che “funziona, quindi non si tocca”, il server di cui nessuno ricorda più come è stato configurato. Su queste installazioni non esiste un pacchetto da applicare: l’unica strada è portare l’applicazione su una versione supportata, con il lavoro di adeguamento del codice che comporta.

Una vulnerabilità come questa è il momento giusto per fare l’inventario: quali applicazioni avete, su quale versione di PHP girano, chi le aggiorna e con quale frequenza.

Fonti

Se avete applicazioni PHP in produzione e non siete certi di quali versioni girino davvero sui vostri server, o se un aggiornamento è bloccato da codice datato, possiamo aiutarvi a mettere in sicurezza l’infrastruttura e a pianificare la migrazione. Leggete come Sigilium affronta gli audit e la remediation di infrastruttura oppure parlateci del vostro caso.