PHP2Shell: due vulnerabilità critiche in PHP. Come proteggere i server Linux

Il 21 ottobre 2026 sono state divulgate due gravi vulnerabilità di sicurezza che interessano PHP, uno dei linguaggi di programmazione più diffusi per lo sviluppo di siti web e applicazioni online.

Le vulnerabilità, identificate come CVE-2026-109618 e CVE-2026-109619 e conosciute collettivamente con il nome di PHP2Shell, hanno ricevuto entrambe un punteggio CVSS 4.0 di 9,2 su 10.

Il rischio principale è la possibilità che un attaccante riesca, in determinate condizioni, a eseguire codice da remoto sul server senza autenticazione.

La vicenda è particolarmente importante perché il problema non riguarda necessariamente il codice sviluppato per un’applicazione, ma direttamente l’interprete PHP, cioè il componente che esegue il codice delle applicazioni web.

Questo significa che anche un sito sviluppato seguendo le migliori pratiche di sicurezza può risultare vulnerabile se utilizza una versione di PHP interessata dal problema.

In questo articolo vediamo cosa è successo, come funzionano le due vulnerabilità, quali server possono essere interessati e soprattutto come verificare e aggiornare PHP su Debian e Ubuntu.

Cosa è successo il 21 ottobre 2026

La vicenda è iniziata il 20 ottobre, quando sono emersi anticipatamente dettagli relativi a due vulnerabilità critiche nel motore PHP.

La divulgazione coordinata era inizialmente prevista per il 22 ottobre, ma la diffusione anticipata di informazioni tecniche ha portato il PHP Security Team ad accelerare la pubblicazione degli aggiornamenti.

Il 21 ottobre sono state rilasciate le versioni corrette e pubblicati gli advisory ufficiali.

Numerose organizzazioni di cybersecurity hanno richiamato l’attenzione sulla necessità di aggiornare rapidamente i sistemi esposti a Internet.

Le due vulnerabilità sono particolarmente pericolose perché possono consentire una Remote Code Execution, abbreviata RCE.

Una vulnerabilità RCE permette a un attaccante di eseguire istruzioni su un sistema remoto. Nel caso di PHP, il codice viene inizialmente eseguito con i privilegi del processo compromesso.

Questo non significa necessariamente ottenere immediatamente i privilegi di amministratore del server, ma può comunque consentire attività molto gravi, come accedere ai file dell’applicazione, leggere dati riservati, recuperare credenziali o tentare ulteriori compromissioni.

Perché PHP2Shell è diverso da una normale vulnerabilità web

Per capire il problema dobbiamo considerare come funziona normalmente un’applicazione PHP.

Quando un utente apre una pagina web, il browser invia una richiesta HTTP al server. Apache o Nginx ricevono la richiesta e, quando necessario, la passano all’interprete PHP.

PHP esegue il codice dell’applicazione, eventualmente interroga un database e genera una risposta che viene restituita al browser.

Quando parliamo di vulnerabilità web, spesso pensiamo a SQL Injection, Cross-Site Scripting oppure a errori nell’autenticazione.

In questi casi il problema riguarda generalmente il codice dell’applicazione o il modo in cui vengono gestiti gli input dell’utente.

Con PHP2Shell, invece, il problema si trova a un livello differente.

Le vulnerabilità interessano il funzionamento interno dell’interprete PHP, in particolare alcune operazioni di gestione della memoria e del ciclo di vita delle richieste.

Nel caso di Apache con mod_php è stato dimostrato un percorso di sfruttamento che può raggiungere la vulnerabilità prima ancora che il codice dell’applicazione venga eseguito.

È proprio questo uno degli aspetti più delicati: la sicurezza del codice applicativo non è sufficiente a proteggere da una vulnerabilità presente nel runtime sottostante.

CVE-2026-109618: corruzione della memoria durante un errore Out Of Memory

La prima vulnerabilità, CVE-2026-109618, riguarda la gestione della memoria quando PHP incontra una condizione di Out Of Memory, abbreviata OOM.

Una condizione OOM si verifica quando un processo non riesce a ottenere la memoria necessaria per completare un’operazione.

PHP mette a disposizione una direttiva chiamata memory_limit, utilizzata per limitare la quantità di memoria che uno script può utilizzare.

Quando un’operazione supera il limite previsto, PHP deve interromperla e gestire correttamente l’errore.

La vulnerabilità nasce proprio in questa fase.

In determinate circostanze, la gestione dell’errore può lasciare alcune strutture interne in uno stato parzialmente inizializzato. Durante la successiva pulizia della richiesta, PHP può utilizzare queste strutture come se fossero valide.

Questo comportamento può provocare una corruzione della memoria e, attraverso un attacco opportunamente costruito, arrivare all’esecuzione di codice da remoto.

Uno dei percorsi di sfruttamento documentati coinvolge l’elaborazione di richieste HTTP di tipo multipart/form-data, comunemente utilizzate dai form web e dai sistemi di caricamento dei file.

Il problema non dipende necessariamente dall’accettazione di un file dannoso da parte dell’applicazione, ma può manifestarsi durante l’elaborazione della richiesta da parte dell’interprete stesso.

CVE-2026-109619: il problema dello Use After Free

La seconda vulnerabilità, CVE-2026-109619, è legata alla gestione dello stato interno tra richieste successive.

Per capire il problema dobbiamo ricordare che molti processi PHP vengono riutilizzati per gestire più richieste nel corso della propria esistenza.

Durante l’elaborazione di una richiesta, PHP mantiene in memoria diverse strutture e informazioni temporanee.

Quando la richiesta termina, queste risorse devono essere eliminate o reinizializzate correttamente.

In alcune condizioni di errore, però, determinati riferimenti possono continuare a puntare a memoria già liberata.

Questa situazione è conosciuta come Use After Free.

Il programma tenta cioè di utilizzare una porzione di memoria dopo averla liberata.

Se una richiesta successiva riutilizza quei riferimenti, può verificarsi una corruzione della memoria, potenzialmente sfruttabile per modificare il comportamento del processo.

Anche per questa vulnerabilità sono stati dimostrati scenari di esecuzione di codice da remoto.

Le due CVE hanno quindi cause tecniche differenti, ma condividono un elemento fondamentale: riguardano il motore PHP e non una particolare applicazione sviluppata con questo linguaggio.

Quali versioni di PHP sono vulnerabili?

Il PHP Security Team ha pubblicato aggiornamenti per i rami supportati.

Le versioni precedenti all’interno di questi rami sono interessate dalle vulnerabilità, salvo che il fornitore del sistema operativo abbia già integrato le correzioni tramite backport.

Le versioni PHP 8.1 e precedenti non ricevono più il normale supporto del progetto PHP. Alcuni fornitori possono comunque distribuire patch specifiche, ma in questi casi è consigliabile pianificare una migrazione verso un ramo supportato.

Apache con mod_php e PHP-FPM: quali sono le differenze?

Le vulnerabilità possono interessare diverse modalità di esecuzione di PHP:

• Apache con mod_php
• PHP-FPM
• php-cgi
• FrankenPHP
• LiteSpeed

Non tutte le configurazioni presentano però lo stesso livello di esposizione.

Apache con mod_php è lo scenario considerato maggiormente a rischio, perché è stato dimostrato un percorso di sfruttamento che non richiede l’esecuzione del codice applicativo.

Anche PHP-FPM può essere vulnerabile, ma i percorsi di sfruttamento possono richiedere condizioni differenti.

Questo non significa che PHP-FPM possa essere escluso dagli aggiornamenti.

La raccomandazione è aggiornare tutte le installazioni vulnerabili utilizzate per gestire richieste web.

Come verificare la versione PHP su Debian e Ubuntu

Passiamo adesso alla parte pratica.

Il primo controllo consiste nell’identificare quali versioni di PHP sono installate sul server.

Verificare la versione PHP da terminale

Possiamo iniziare con:

php -v

Il comando restituisce la versione PHP utilizzata nell’ambiente a riga di comando.

Attenzione però: questa potrebbe non essere la stessa versione utilizzata da Apache o da un altro server web.

Visualizzare i pacchetti PHP installati

Su Debian e Ubuntu possiamo utilizzare:

dpkg -l | grep '^ii' | grep php

Questo comando permette di individuare i pacchetti installati, compresi l’interprete PHP e le relative estensioni.

Per ottenere un elenco con nome e versione completa dei pacchetti PHP possiamo eseguire:

dpkg-query -W \
  -f='${db:Status-Abbrev} ${binary:Package} ${Version}\n' \
  'php*' 2>/dev/null | grep '^ii'

La versione completa del pacchetto è importante perché può contenere informazioni sugli aggiornamenti di sicurezza distribuiti dalla distribuzione.

Verificare quale PHP utilizza Apache

La prima cosa da fare è capire come Apache esegue PHP.

apache2ctl -M | grep -E 'php|proxy_fcgi'

Se troviamo:

php_module (shared)

Apache ha caricato il modulo PHP.

Possiamo verificare quale versione del modulo è abilitata con:

ls -l /etc/apache2/mods-enabled/php*.load

Se invece troviamo:

proxy_fcgi_module (shared)

Apache dispone del modulo necessario per utilizzare un backend FastCGI, ma dobbiamo verificare nella configurazione se il sito utilizza effettivamente PHP-FPM.

Possiamo cercare i riferimenti ai socket PHP-FPM:

grep -R -E 'php[0-9.]+-fpm.sock|SetHandler|ProxyPassMatch' \
  /etc/apache2/sites-enabled/ \
  /etc/apache2/conf-enabled/

Per esempio, una configurazione che contiene:

/run/php/php8.4-fpm.sock

indica che il relativo VirtualHost è configurato per comunicare con PHP 8.4-FPM.

Possiamo quindi verificare la versione dell’eseguibile:

php-fpm8.4 -v

Se il server ospita più siti, occorre verificare la configurazione del VirtualHost specifico.

Come aggiornare PHP con APT

Una volta identificati i pacchetti PHP utilizzati dal server possiamo procedere con gli aggiornamenti.

Prima di intervenire su un server di produzione è opportuno verificare la compatibilità delle applicazioni, programmare l’intervento e disporre di un piano di ripristino.

Aggiornare l’indice dei pacchetti

sudo apt update

Questo comando aggiorna l’elenco delle versioni disponibili nei repository configurati, senza modificare i pacchetti installati.

Verificare gli aggiornamenti disponibili

apt list --upgradable 2>/dev/null | grep php

Possiamo anche controllare la versione installata e quella candidata all’aggiornamento:

apt policy php8.4-fpm

Naturalmente dobbiamo adattare il nome del pacchetto alla versione PHP utilizzata.

Aggiornare solamente PHP

Se utilizziamo PHP-FPM 8.4 possiamo eseguire una simulazione:

sudo apt install --only-upgrade --dry-run php8.4-fpm

Dopo aver verificato le modifiche previste:

sudo apt install --only-upgrade php8.4-fpm

Se Apache utilizza mod_php:

sudo apt install --only-upgrade libapache2-mod-php8.4

APT può aggiornare anche le dipendenze necessarie, come php8.4-common.

È importante controllare tutti i componenti PHP installati, comprese le estensioni, ed evitare di aggiornare esclusivamente il metapacchetto generico php.

I comandi mostrati si riferiscono a PHP 8.4: se il server utilizza un altro ramo, bisogna adattarli.

Riavviare Apache o PHP-FPM

Dopo l’aggiornamento è necessario riavviare i processi che utilizzano PHP.

Se Apache utilizza mod_php:

sudo apache2ctl configtest
sudo systemctl restart apache2

Se utilizziamo PHP-FPM 8.4:

sudo systemctl restart php8.4-fpm

Verifichiamo poi che il servizio sia attivo:

systemctl status php8.4-fpm

Il riavvio è importante perché i processi già in esecuzione potrebbero continuare a utilizzare componenti caricati prima dell’aggiornamento.

Attenzione ai backport di sicurezza

Questo è uno degli aspetti più importanti quando lavoriamo con distribuzioni come Debian e Ubuntu.

Una distribuzione Linux non sempre aggiorna un software alla versione upstream più recente.

Può invece integrare una correzione di sicurezza nella versione già distribuita.

Questo meccanismo viene chiamato backport.

Di conseguenza, una versione PHP apparentemente precedente a quelle corrette dal progetto PHP non è necessariamente vulnerabile.

Per determinare se il server è protetto dobbiamo verificare la versione completa del pacchetto e consultare gli advisory ufficiali della distribuzione.

In particolare, non dobbiamo considerare il solo output di php -v come prova definitiva dell’applicazione delle patch.

Mitigazioni temporanee: cosa fare se non possiamo aggiornare subito

In alcuni ambienti produttivi potrebbe non essere possibile applicare immediatamente gli aggiornamenti.

Il PHP Security Team ha documentato alcune misure temporanee per ridurre determinati percorsi di sfruttamento.

Tra queste rientrano, a seconda della vulnerabilità e della configurazione, modifiche alle direttive:

memory_limit = -1
session.upload_progress.enabled = Off

La prima disabilita il limite di memoria imposto direttamente da PHP e richiede particolare attenzione, perché può aumentare il rischio di esaurimento delle risorse del server.

La seconda disabilita la funzionalità di monitoraggio dell’avanzamento degli upload associata alle sessioni PHP.

Queste impostazioni devono essere valutate consultando gli advisory ufficiali, considerando la versione e la configurazione del server e riavviando i processi interessati.

Nessuna di queste mitigazioni rappresenta una correzione completa delle vulnerabilità.

Quando non è possibile aggiornare rapidamente un sistema esposto a Internet, è opportuno considerare anche misure più incisive, come limitarne l’accessibilità pubblica o sospendere temporaneamente il servizio.

Dopo l’aggiornamento: verificare che il server sia protetto

Una volta installati gli aggiornamenti, è necessario verificare che i servizi funzionino correttamente e che le patch siano effettivamente presenti.

Possiamo iniziare controllando nuovamente i pacchetti installati:

dpkg -l | grep '^ii' | grep php

Successivamente possiamo verificare lo stato dei servizi:

systemctl status apache2
systemctl status php8.4-fpm

Naturalmente il secondo comando è necessario soltanto se utilizziamo PHP-FPM.

Per esaminare gli ultimi eventi del servizio PHP-FPM possiamo utilizzare:

journalctl -u php8.4-fpm -n 50

È inoltre opportuno controllare gli error log di Apache e PHP e verificare il funzionamento delle applicazioni.

E se il server fosse già stato compromesso?

Questo è un aspetto particolarmente importante.

Quando viene divulgata una vulnerabilità critica, aggiornare il software impedisce lo sfruttamento futuro del problema corretto, ma non elimina eventuali conseguenze di una compromissione già avvenuta.

Per questo motivo dovremmo analizzare anche i log precedenti all’aggiornamento.

Tra gli elementi da approfondire troviamo errori ripetuti di memoria, crash anomali dei processi PHP, richieste HTTP sospette e processi inattesi avviati dall’utente del web server.

È utile controllare anche eventuali file PHP sconosciuti, modifiche inattese alle applicazioni, nuove attività pianificate e connessioni di rete sospette.

Nessuno di questi elementi dimostra, da solo, che sia avvenuto un attacco. Tuttavia possono costituire indicatori utili per avviare ulteriori verifiche.

Se emergono evidenze credibili di compromissione, è necessario gestire l’evento attraverso un processo strutturato di incident response, preservando le informazioni utili all’analisi.

Conclusioni: cosa ci insegna PHP2Shell

Le vulnerabilità PHP2Shell dimostrano quanto sia importante mantenere aggiornati non soltanto i software applicativi, ma anche tutti i componenti sui quali questi si basano.

Abbiamo visto due vulnerabilità critiche nell’interprete PHP che possono consentire, in determinate condizioni, l’esecuzione di codice da remoto senza autenticazione.

Abbiamo analizzato i meccanismi di corruzione della memoria, le differenze tra Apache con mod_php e PHP-FPM e le procedure per verificare e aggiornare PHP sui server Debian e Ubuntu.

Ma la lezione più importante va oltre queste due CVE.

La sicurezza di un’applicazione dipende anche dal sistema operativo, dalle librerie, dall’interprete, dal web server e dal modo in cui tutti questi componenti vengono mantenuti.

Un’organizzazione che dispone di un inventario aggiornato dei propri server, monitora gli advisory di sicurezza e possiede procedure affidabili di patch management può reagire molto più rapidamente quando viene pubblicata una vulnerabilità critica.

Conoscere la vulnerabilità è soltanto il primo passo. Sapere dove si trova il software interessato e riuscire ad aggiornarlo rapidamente è ciò che permette davvero di ridurre il rischio.