PHP2Shell: il rischio può essere nel server PHP che non ricordi più di avere

Due vulnerabilità critiche nel motore PHP hanno riportato l'attenzione su un problema molto concreto: nelle infrastrutture aziendali possono esistere runtime PHP installati anni fa, integrati in software, pannelli Web, server secondari o container e ormai usciti dal normale controllo degli amministratori.

PHP2Shell: perché se ne sta parlando

Il 21 ottobre 2026 sono state rese pubbliche due vulnerabilità critiche del runtime PHP, identificate come CVE-2026-109618 e CVE-2026-109619.

Entrambe possono, in determinate condizioni, consentire l'esecuzione di codice da remoto senza autenticazione e sono state classificate con un punteggio CVSS 4.0 pari a 9,2.

Il punto più delicato è che la vulnerabilità non riguarda necessariamente il CMS, il sito Web o il codice PHP sviluppato dall'azienda.

Il problema si trova nel motore PHP stesso.

Questo significa che aggiornare soltanto WordPress, Joomla, Drupal, un plugin o l'applicazione Web non è sufficiente. Bisogna verificare quale versione del runtime PHP sta realmente elaborando le richieste Web.

Quali installazioni PHP possono essere interessate?

Le vulnerabilità riguardano installazioni PHP che elaborano richieste Web.

Tra gli ambienti potenzialmente interessati troviamo:

PHP-FPM;
Apache con mod_php;
php-cgi;
FrankenPHP;
LiteSpeed;
software e appliance che incorporano un proprio runtime PHP.

Secondo le indicazioni pubblicate dopo la disclosure, il rischio è particolarmente rilevante nelle configurazioni Apache con mod_php.
In questo modo il codice vulnerabile può essere raggiunto prima ancora che l'applicazione PHP inizi a eseguire la propria logica.

Il vero problema: il PHP nascosto

Sapere che un server utilizza PHP è relativamente semplice.

Molto più difficile è sapere quanti PHP sono realmente presenti nell'infrastruttura.

Un'applicazione installata anni fa, un vecchio pannello amministrativo, un software fornito da terzi oppure un container dimenticato possono includere autonomamente Apache, PHP e altri componenti.

Il sistema operativo può essere perfettamente aggiornato mentre quel singolo runtime PHP continua a utilizzare una release vulnerabile.

Perché aggiornare il server principale potrebbe non bastare

In una piccola infrastruttura si tende spesso a pensare: “abbiamo aggiornato PHP sul server Web, quindi siamo a posto”.

Non è necessariamente così.

Sul medesimo server possono convivere diverse versioni PHP.

Web server principale

Il sito pubblico può utilizzare, per esempio, una versione PHP recente tramite PHP-FPM.

Applicazione secondaria

Un gestionale o un'applicazione installata anni prima può utilizzare un proprio php-cgi.exe completamente indipendente.

Container

Docker può eseguire un'altra release PHP che non compare tra i pacchetti installati sul sistema host.

Per questo PHP2Shell mette in evidenza un problema più ampio della singola vulnerabilità: l'inventario reale del software aziendale.

PHP2Shell su Windows: attenzione a IIS e ai software autonomi

In ambiente Windows la presenza di PHP non è necessariamente evidente dall'elenco dei programmi installati. Molti prodotti possono infatti contenere direttamente php.exe oppure php-cgi.exe all'interno della propria directory. È quindi opportuno controllare non soltanto le installazioni PHP conosciute, ma anche le directory nelle quali sono presenti applicazioni Web e software server.