Oggi, 21 ottobre 2026, il team di sicurezza di PHP ha pubblicato un avviso di emergenza: due vulnerabilità critiche nel cuore stesso del linguaggio, denominate collettivamente PHP2Shell, permettono a un attaccante di eseguire codice da remoto e senza autenticazione su qualsiasi server che serve PHP via web. Non è un difetto di WordPress, né un plugin, né una tua configurazione errata – è nell'interprete.

La massima gravità deriva da un dettaglio tecnico importante: la richiesta dannosa viene elaborata prima che venga eseguita una singola riga del tuo codice. Non importa quanto sia ben scritta la tua applicazione — login, validazioni, WAF dell'applicazione — perché l'attacco avviene direttamente in PHP durante la preparazione della richiesta.

I due nuovi entri nel CVE

Entrambi condividono la stessa causa principale — PHP può lasciare la memoria in uno stato corrotto quando una richiesta termina in modo anomalo — ma vengono sfruttati in modi diversi. Ognuno ha un punteggio CVSS di 9,2 (critico):

  • CVE-2026-109618 — La gestione degli errori fuori memoria (OOM) può interrompere PHP mentre i dati interni della richiesta sono solo parzialmente inizializzati. La successiva pulizia delle richieste considera validi quei dati non validi, causando corruzione della memoria ed esecuzione remota di codice con privilegi web work.
  • CVE-2026-109619 — Lo stato interno posseduto da una richiesta può sopravvivere dopo che la memoria è stata liberata. Una richiesta successiva servita dallo stesso worker può utilizzare quello stato obsoleto prima che l'inizializzazione normale lo resetti: use-after-free sull'heap, divulgazione della memoria e, di nuovo, esecuzione remota del codice senza autenticazione.

Interessano tutte le installazioni PHP che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il team PHP considera il rischio più alto in mod_php, dove c'è già un exploit comprovato che si attiva prima che il codice dell'applicazione venga eseguito.

Pagine interessate

Abbiamo auditato tutta la nostra infrastruttura e queste sono le pagine che servono PHP con versioni inferiori a quelle patchate — cioè vulnerabili fino all'applicazione dell'aggiornamento:

  • PHP 8.3.35 (vulnerabile, richiede 8.3.36): www.io-backup.com, www.dynamicdnspro.com, www.fisem.com.
  • PHP 8.4.25 (vulnerabile, richiede 8.4.27): www.emhaseasociados.es, app.emhaseasociados.es.
  • PHP 8.4.26 (vulnerabile, richiede 8.4.27): scanner.net-analyzer.com, app.fisem.com, buy.dynamicdnspro.com.

Se gestisci i tuoi siti, puoi controllare la versione che espone ciascuno con curl -sI https://tudominio.com | grep -i x-powered-by. Nota: solo perché l'intestazione non appare non significa che tu sia al sicuro, solo che il server non lo annuncia.

Misure urgenti

L'unica soluzione completa è aggiornare PHP. Le versioni con la patch sono:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Per PHP 8.1 e precedenti — fuori supporto — il team PHP ha rilasciato backport minimi per 7.4, 8.0 e 8.1, ma la raccomandazione ufficiale è di migrare a un branch supportato. Nel frattempo, ecco le misure che stiamo implementando e raccomandando:

  1. Aggiorna il prima possibile alla versione patchata del tuo ramo, dando priorità ai server esposti a Internet.
  2. Mitigazione parziale immediata: disabilitazione session.upload_progress.enabled=0 in php.ini y, in PHP 8.5, anche fatal_error_backtraces=0. Riavvia tutti i lavoratori dopo la modifica. Nota: secondo le analisi di Datadog e JFrog questa mitigazione è parziale, non completa — non sostituisce la patch.
  3. Correzione memory_limit=-1 invece di usare limiti RLIMIT, per ridurre i percorsi di corruzione da OOM.
  4. Filtro al bordo: Un WAF o reverse proxy davanti a PHP può bloccare richieste multiparti anomale prima che raggiungano il parser vulnerabile.
  5. Monitor: Controlla i log per invii di moduli molto grandi, errori di esaurimento della memoria durante l'inizializzazione delle richieste e processi shell inattesi avviati dai lavoratori PHP.

Se non puoi aggiornare subito, CISA consiglia persino di mettere offline i sistemi PHP esposti finché non possono essere aggiornati con una patch. È una raccomandazione drastica per una vulnerabilità drastica.

Conclusione

PHP2Shell è uno dei bug che si presenta solo una volta ogni pochi anni: critico, senza autenticazione e nel livello inferiore a qualsiasi applicazione. La patch esiste già e applicarla richiede pochi minuti sulla maggior parte dei sistemi. Stiamo già aggiornando tutte le pagine interessate elencate sopra; se hai un sito gestito con PHP, questo è il momento giusto per fare lo stesso.