PHP, due vulnerabilità critiche: cosa sappiamo e come prepararsi al rilascio del 21 ottobre

Il 20 ottobre il team di sicurezza di PHP ha pubblicato un avviso breve e molto diretto: il 21 ottobre 2026, alle 14:00 UTC, uscirà una release di sicurezza che corregge due vulnerabilità critiche, entrambe valutate CVSS v4.0 9.2.

Il comunicato non dice quali versioni siano coinvolte né in cosa consistano i difetti. Quelle informazioni arriveranno insieme alla release, quando saranno disponibili anche le versioni corrette. L’invito, però, è già esplicito: prepararsi adesso, per poter aggiornare appena il pacchetto esce.

Qui sotto trovi i fatti confermati, una spiegazione di cosa significa un punteggio così alto e una checklist da usare nelle prossime ore.

Aggiornamento del 21 ottobre, ore 13:00 UTC

Da quando questo articolo è stato pubblicato, questa mattina, il quadro è cambiato in fretta. Ecco i fatti nuovi, tenuti separati da quelli già scritti sopra.

• Embargo saltato. Il 20 ottobre i dettagli delle due vulnerabilità sono circolati prima del previsto. watchTowr ha confermato che si tratta di CVE-2026-109618 e CVE-2026-109619, entrambe descritte come remote code execution nel core di PHP, con CVSS v4.0 9.2.
• Exploit pubblico. Un video diffuso da Kirill Firsov mostra la catena ribattezzata PHP2Shell, attribuita al ricercatore LCFR e a Calif.IO. Il banner dello strumento dichiara di funzionare da PHP 5.4.0 in poi: è una dichiarazione dell’autore, non una verifica indipendente.
• Attacchi già iniziati. Alle 07:43 UTC il CTO di Cloudflare, Dane Knecht, ha scritto di vedere attacchi precoci contro siti PHP. Cloudflare ha distribuito regole WAF per tutti i clienti, piano gratuito compreso, definendole un tampone.
• Riproduzione in laboratorio, non in the wild. watchTowr dice di aver riprodotto CVE-2026-109618 in laboratorio e, al momento della dichiarazione, di non aver osservato sfruttamento reale su larga scala.
• Siti offline per precauzione. Diversi siti olandesi hanno sospeso il servizio, tra cui Tweakers, il sito della Camera dei Deputati, il centro nazionale cybersicurezza e Security.NL.
• Repository Remi fermo. La PHP Foundation ha avvertito che il repository Remi, molto usato su RHEL, oggi non pubblicherà aggiornamenti.
• Versioni corrette attese: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. La release resta fissata alle 14:00 UTC, le 16:00 in Italia, con la possibilità di anticipo. Poi confermate al rilascio, senza anticipo.

Il dettaglio tecnico trapelato indicava un use-after-free nello heap legato a session.upload_progress, con un secondo percorso nel parser multipart. La causa ufficiale è diversa: corruzione durante la gestione dell’out-of-memory e stato interno rimasto attivo dopo la liberazione della memoria. session.upload_progress resta un vettore confermato, il parser multipart no. Il resto dell’articolo resta valido; le sezioni operative sono state integrate con la guida all’aggiornamento e con i passi per AppArmor.

Aggiornamento del 21 ottobre, ore 14:00 UTC

La release è uscita in punto, senza anticipo. Ecco cosa è cambiato rispetto a quanto scritto sopra.

• Versioni corrette: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
• CVE-2026-109618, RCE via corruzione OOM: la gestione dell’out-of-memory può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte, e la pulizia della richiesta tratta quei dati invalidi come validi.
• CVE-2026-109619, RCE via stato globale stale: uno stato interno della richiesta sopravvive dopo che la memoria che lo sosteneva è stata liberata, e una richiesta successiva sullo stesso worker può usarlo prima che l’inizializzazione normale lo azzeri.
• Entrambe CVSS v4.0 9.2, esecuzione di codice non autenticata.

Il punto che pesa di più: il rischio massimo è su mod_php, dove l’exploit dimostrato scatta prima che qualsiasi codice applicativo venga eseguito. Sono coinvolti anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed.

Per chi è su una branch fuori supporto c’è una novità: il team PHP ha pubblicato backport sorgente minimali per 7.4, 8.0 e 8.1. Solo sorgente, niente pacchetti pronti. Il repository Remi resta fermo oggi, come già scritto.

Le mitigazioni ufficiali per chi non può aggiornare subito sono elencate più sotto, nella sezione dopo il rilascio.

Cosa sappiamo, senza aggiungere nulla

• Data e ora: mercoledì 21 ottobre 2026, alle 14:00 UTC. In Italia sono le 16:00.
• Contenuto: due vulnerabilità critiche, entrambe valutate CVSS v4.0 9.2.
• Versioni coinvolte: non ancora comunicate. Il team ha spiegato che dettagli completi, versioni affette e versioni corrette saranno pubblicati con il rilascio.
• Possibile anticipo: la release può arrivare prima se i dettagli diventano pubblici o se compare evidenza di sfruttamento attivo.

Quest’ultimo punto è quello che conta di più. Un annuncio di sicurezza con una data precisa è anche un avviso per chi cerca falle: se qualcuno riesce a ricostruire il problema prima delle 14:00 UTC, la patch esce prima. Non è una clausola di stile, è un meccanismo di sicurezza.

Cosa significa un CVSS v4.0 di 9.2

Il CVSS è un punteggio da 0 a 10 che prova a misurare la gravità di una vulnerabilità. La scala si divide in fasce: da 0,1 a 3,9 bassa, da 4,0 a 6,9 media, da 7,0 a 8,9 alta, da 9,0 a 10 critica. Un 9.2 sta in cima, appena sotto il massimo.

La versione 4.0 del sistema, in uso dal 2023, pesa anche fattori che le versioni precedenti trattavano in modo diverso: se l’attacco richiede condizioni particolari, se serve l’interazione dell’utente, quanto è ampia l’esposizione. Due falle con lo stesso punteggio possono quindi avere storie molto diverse.

Un 9.2, in pratica, dice che la falla è grave e va trattata come tale. Non dice che chiunque, da qualsiasi punto di internet, può compromettere il tuo server in questo momento. Le vulnerabilità PHP con punteggi simili, storicamente, riguardano aree come il parsing di input non fidato, la deserializzazione, il caricamento di estensioni o i motori di template. Non sappiamo quale sia il caso e indovinare non serve a nulla: la risposta operativa è la stessa in tutti gli scenari.

Quali versioni riceveranno la patch

Il comunicato non lo dice, ma il ciclo di supporto di PHP lo rende prevedibile. A oggi le branch supportate sono quattro.

Le versioni corrette, confermate al rilascio, coprono tutte e quattro le branch supportate: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Il ramo 8.6, ancora in release candidate con la RC4 prevista il 22 ottobre, oggi non riceve nulla.

Se invece sei su PHP 8.1 o precedenti, non aspettarti pacchetti: quelle branch sono fuori supporto e non ricevono correzioni di sicurezza. Il team PHP ha però pubblicato backport sorgente minimali per 7.4, 8.0 e 8.1, solo codice da compilare, senza pacchetti pronti. Resta il segnale che la piattaforma va spostata su una branch supportata, non che la falla si risolva da sola.

Perché due falle critiche nello stesso rilascio sono una faccenda seria

Il giorno del rilascio non è il giorno in cui il rischio finisce. È il giorno in cui inizia la corsa.

Appena la patch è online, il codice corretto diventa pubblico. Chi vuole sfruttare la falla può confrontare la versione vecchia con quella nuova e capire dove intervenire. Le prime scansioni automatiche arrivano in genere entro poche ore, a volte minuti. Due vulnerabilità nello stesso pacchetto significano due analisi in parallelo e due finestre di esposizione.

Per questo la domanda corretta non è “quando ho tempo di aggiornare”, ma “posso aggiornare il giorno stesso”. Un server PHP esposto e senza patch per un fine settimana è esattamente il tipo di bersaglio che questi strumenti cercano.

Prima del rilascio: inventario in cinque passi

Nelle prossime ore la cosa più utile è sapere esattamente cosa hai in mano. Non serve una procedura formale, bastano cinque risposte.

1. Che versione di PHP gira davvero

Da terminale: php -v. Da browser: una pagina con phpinfo(), da cancellare subito dopo. Su WordPress: Strumenti, Salute del sito, scheda Informazioni, voce Server.

Attenzione al dettaglio che frega tutti: la versione della CLI e quella di PHP-FPM possono essere diverse. Il sito usa FPM, gli script da riga di comando usano la CLI. Verifica entrambe.

2. Dove gira PHP

Sito, gestione dell’hosting, cron job, code di lavoro, API interne, container Docker, pipeline di integrazione. Un aggiornamento fatto solo sul sito lascia scoperti gli altri pezzi e spesso sono proprio quelli esposti.

3. Da dove arriva il pacchetto

Repository della distribuzione, PPA di terze parti, immagine Docker ufficiale, pannello del hosting, pacchetto compilato a mano. La velocità con cui arrivi alla patch dipende da questa risposta: i repository delle distro a volte pubblicano con qualche ora di ritardo, le immagini Docker in genere seguono in giornata, un host gestito può decidere per te.

4. Hai un posto dove provare

Una copia di staging, un backup recente, un piano di rollback scritto. Tre cose che sembrano burocrazia finché l’aggiornamento non rompe qualcosa.

5. Cosa potrebbe rompersi

Estensioni PECL, opcache con preload, librerie native compilate contro una versione specifica, dipendenze Composer con vincoli su ext-*. Un giro di composer check-platform-reqs prima e dopo l’aggiornamento chiarisce in fretta se il progetto regge.

AppArmor o SELinux, la cintura di sicurezza

Kevin Beaumont ha suggerito un’altra mitigazione: confinare PHP con AppArmor o SELinux. L’idea è che l’exploit, per arrivare all’esecuzione di comandi, deve uscire dal processo PHP; un profilo che gli vieta di lanciare altri programmi e di scrivere fuori dalle cartelle previste gli toglie l’ultimo passo. Non corregge la falla e non sostituisce la patch: riduce il danno se qualcuno ci arriva prima.

Su Ubuntu e Debian AppArmor è spesso già installato. Verifica:

sudo aa-status
systemctl is-enabled apparmor

Se manca:

sudo apt update
sudo apt install apparmor apparmor-utils apparmor-profiles
sudo systemctl enable --now apparmor

Poi crea un profilo per il binario di PHP-FPM, per esempio /etc/apparmor.d/usr.sbin.php-fpm8.4. Adatta versione e percorsi:

#include <tunables/global>

/usr/sbin/php-fpm8.4 flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  /etc/php/8.4/fpm/** r,
  /run/php/** rw,
  /var/log/php8.4-fpm.log rw,
  /var/www/** r,
  /var/www/*/wp-content/uploads/** rw,
  /tmp/** rwk,

  deny /bin/** x,
  deny /usr/bin/** x,
  deny /usr/local/bin/** x,
  deny /sbin/** x,
  deny /home/** rwklx,
  deny /root/** rwklx,
  deny /etc/shadow r,
  deny /etc/sudoers r,
}

Le righe che contano sono i deny ... x: negano l’esecuzione di qualunque comando. Il resto tiene il webroot in sola lettura, lasciando scrivere solo upload e /tmp: una webshell non può essere creata in wp-content, e se l’applicazione ha bisogno di scrivere altrove il profilo va allargato di conseguenza.

Non caricarlo subito in enforcing. Mettilo in complain, fai girare il sito, leggi i log e correggi:

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.php-fpm8.4
sudo aa-complain /etc/apparmor.d/usr.sbin.php-fpm8.4
sudo systemctl restart php8.4-fpm
sudo aa-logprof
sudo aa-enforce /etc/apparmor.d/usr.sbin.php-fpm8.4

Verifica che il profilo sia attivo con sudo aa-status | grep php. Poi prova su staging una pagina che chiama shell_exec('id'): deve fallire. Se funziona ancora, il profilo non è applicato al processo giusto.

Su RHEL e derivate il discorso è SELinux, spesso già in enforcing. Controlla con getenforce e sestatus, guarda i dinieghi con sudo ausearch -m avc -ts recent e non disattivarlo per fare prima: un SELinux permissivo è rumore, non sicurezza. Beaumont sottolinea “configured correctly” perché è quello il punto, un profilo generico non serve.

Due limiti da tenere presenti. Primo, AppArmor confina il processo, non la memoria: se l’exploit riesce a leggere file che PHP può leggere, il profilo non lo ferma. Secondo, nei container il profilo dell’host non si applica da solo: va passato con --security-opt apparmor=... o definito nel compose. È una cintura, non una patch.

Guida all’aggiornamento, passo per passo

La patch è una sola, ma i modi per applicarla cambiano molto in base a come è installato PHP. Qui sotto trovi i percorsi più comuni. In tutti i casi la regola è la stessa: resta sulla tua branch, non saltare a una versione maggiore mentre stai correndo.

Prima di toccare qualsiasi cosa

• Backup o snapshot del server o del container. Se l’aggiornamento rompe un’estensione, tornare indietro deve richiedere minuti, non ore.
• Annota la versione attuale di CLI, FPM e pannello, e il comando esatto con cui hai installato PHP. Serve per il rollback.
• Aggiorna prima lo staging, poi un solo server di produzione, poi il resto. Se hai un bilanciatore, togli il nodo dal pool durante il riavvio.
• Riavvia anche i worker: cron PHP, code, supervisor, unit systemd. Un worker con il vecchio interprete resta vulnerabile anche dopo l’aggiornamento del sito.

Debian e Ubuntu

Se usi i pacchetti della distribuzione, aggiorna i pacchetti PHP della branch che hai già:

sudo apt update
sudo apt install --only-upgrade php8.4-fpm php8.4-cli
sudo systemctl reload php8.4-fpm

Sostituisci 8.4 con la tua branch. Se hai estensioni separate, aggiorna anche quelle: php8.4-curl, php8.4-mbstring, php8.4-xml, php8.4-mysql e così via. Il comando dpkg -l | grep php mostra cosa è installato. Attenzione a chi installa PHP da PPA di terze parti: la patch arriva quando il manutentore del repository la pubblica, e non è detto che coincida con le 16:00.

RHEL, AlmaLinux, Rocky Linux

Con i pacchetti della distribuzione o con i module stream:

sudo dnf update php-fpm php-cli
sudo systemctl restart php-fpm

Se usi il repository Remi, oggi è il caso peggiore: la PHP Foundation ha avvertito che il repository, gestito da volontari, non pubblicherà aggiornamenti il 21 ottobre. Le opzioni sono passare ai pacchetti della distribuzione, compilare da sorgente o isolare il server fino a quando il repository si allinea. Non aspettare Remi con le mani in mano.

Docker e container

Un container non si aggiorna con un riavvio: va ricostruito con l’immagine nuova. Cambia il tag nel Dockerfile o nel compose, per esempio da php:8.4-fpm a una versione fissata come php:8.4.27-fpm, poi:

docker compose build --pull
docker compose up -d

Evita latest e i tag generici: volevi una versione precisa proprio per poter dire cosa gira. Se l’immagine ufficiale non è ancora aggiornata, aspetta il push e non ripiegare su una build non verificata. Nei cluster Kubernetes il discorso è lo stesso: nuova immagine, nuovo rollout, verifica che i pod vecchi siano spariti.

Pannelli di controllo e hosting gestito

Su cPanel l’aggiornamento passa da EasyApache 4 o dal selettore MultiPHP, a seconda di come è configurato l’account. Su Plesk da Tools & Settings, PHP Settings, oppure dal pacchetto del sistema. Se il server è gestito e non hai accesso root, l’unica strada è un ticket al supporto con i due CVE e una domanda secca: a che ora applicate la patch e come mi avvisate. Chiedi anche se l’intervento riguarda solo il sito o tutto lo stack, container e cron inclusi.

WordPress senza accesso al server

Se non puoi toccare PHP, puoi però verificare cosa gira: Strumenti, Salute del sito, scheda Informazioni, voce Server. Se la versione è vecchia, apri un ticket con l’hosting e cita CVE-2026-109618 e CVE-2026-109619. Non perdere tempo a cercare plugin che “proteggono” da questa falla: il difetto è nel runtime, non in WordPress.

Verifica dopo l’aggiornamento

• php -v per la CLI e una pagina con phpinfo() per il PHP che serve davvero le richieste. Cancella la pagina subito dopo.
• php -i | grep "Loaded Configuration File" per capire quale php.ini sta usando quel SAPI. CLI e FPM leggono file diversi.
• systemctl status php8.4-fpm e php-fpm -tt per controllare che la pool sia ripartita con la configurazione giusta.
• composer check-platform-reqs dentro il progetto, per vedere se le estensioni richieste ci sono ancora.
• Un giro funzionale: login, upload, form, pagamento, area riservata, cron. Sono i cinque punti dove un aggiornamento PHP fa danni silenziosi.

Se qualcosa si rompe, ripristina lo snapshot invece di improvvisare downgrade a mano: un rollback pulito vale più di un’ora passata a cercare la versione esatta del pacchetto.

Dopo il rilascio: le prime due ore

1. Leggi il changelog, non i titoli. Cerca le CVE, le versioni corrette e le condizioni di sfruttamento.
2. Controlla la tua branch. Se usi 8.4 ti serve la nuova 8.4.x, non la 8.5. Le correzioni di sicurezza escono su ogni branch supportata.
3. Aggiorna prima lo staging, poi fai un giro veloce: login, form, upload, pagamenti, area riservata, cron.
4. Aggiorna la produzione lo stesso giorno. Non aspettare la finestra di manutenzione settimanale, se puoi evitarlo.
5. Verifica la versione effettiva con php -v e con phpinfo(). Il pannello che dice “aggiornato” non sempre coincide con il PHP che serve le pagine.
6. Tieni d’occhio i log e le regole del WAF nelle 24-48 ore successive.

Se non puoi aggiornare subito, ora le indicazioni ufficiali esistono e sono specifiche: memory_limit=-1 impostato dove l’applicazione non può sovrascriverlo, post_max_size=8M (32M se servono upload) con upload_max_filesize sotto quella soglia, session.upload_progress.enabled=0 con restart di ogni worker, fatal_error_backtraces=0 su PHP 8.5. Aiutano a ridurre l’esposizione, non sostituiscono la patch. E non usare RLIMIT_AS o RLIMIT_DATA: possono provocare proprio il fallimento di allocazione da cui parte l’exploit.

Se sei su una versione fuori supporto

PHP 8.1 è arrivato a fine supporto a dicembre 2025. Le versioni precedenti sono fuori da più tempo. In questi casi la patch di domani non ti riguarda, perché non esce per te e il rischio resta aperto a tempo indefinito.

Il salto a una branch supportata richiede tempo e va pianificato, ma la direzione non è negoziabile. Un sito su PHP 7.4 oggi è un sito che accumula falle non corrette.

Come seguire la notizia senza inseguire i titoli

Le fonti che contano sono tre: la pagina news di php.net, il repository php-src su GitHub e gli avvisi di sicurezza della tua distribuzione. Aggiungi il canale del tuo hosting, se ne ha uno. Il resto, nella maggior parte dei casi, arriva dopo.

Domande frequenti

Il mio sito WordPress è a rischio?

WordPress gira su PHP, quindi il runtime è la parte che conta. Che tu usi WordPress, Laravel, Drupal o codice scritto a mano, il rischio dipende dalla falla e dalla configurazione, non dal CMS. Aggiornare i plugin senza aggiornare PHP non risolve questo tipo di problema.

Devo aggiornare subito o posso aspettare qualche giorno?

Subito. Le vulnerabilità critiche con dettagli pubblici vengono sfruttate in tempi brevi, spesso prima che la maggior parte dei siti sia aggiornata. Ogni giorno di ritardo allarga la finestra.

Ho PHP 8.1: riceverò comunque la correzione?

Non come pacchetto. Le branch fuori supporto non ricevono aggiornamenti ufficiali, quindi non troverai 8.1.x nei repository. Il team PHP ha però pubblicato un backport sorgente minimale per 7.4, 8.0 e 8.1: va compilato a mano. La strada normale resta passare a 8.2 o superiore, meglio ancora 8.3 o 8.4.

Il punteggio 9.2 significa che posso essere attaccato adesso?

Non è detto che il tuo server sia già compromesso, ma la finestra è aperta. I dettagli sono circolati, Cloudflare ha segnalato attacchi precoci e gli exploit pubblici esistono. Il punteggio misura la gravità potenziale; lo stato del tuo server lo dicono i log, non il CVSS. Aggiorna appena esce la patch.

Come faccio a sapere se il mio hosting ha già aggiornato?

Chiedi al supporto e verifica da solo con phpinfo() o con una pagina che stampa PHP_VERSION. L’header X-Powered-By non è affidabile, perché spesso viene rimosso o mostra informazioni non aggiornate.

Se gestisci più siti, la cosa più utile che puoi fare in queste ore sta in tre righe: versione PHP, dove gira, chi la aggiorna. Il resto della checklist viene da sé.

Fonti: avviso “Upcoming Critical PHP Security Release” su php.net (20 ottobre 2026) e pagina ufficiale delle versioni supportate.