Un sito web può avere il codice aggiornato, plugin sicuri e nessuna vulnerabilità nota nella propria applicazione. Eppure, potrebbe essere compromesso attraverso la tecnologia su cui si basa.

È quello che dimostra PHP2Shell, il nome con cui sono state identificate due vulnerabilità critiche scoperte nel cuore di PHP, uno dei linguaggi di programmazione più utilizzati al mondo per lo sviluppo web.

Le vulnerabilità, identificate come CVE-2026-109618 e CVE-2026-109619, hanno entrambe un punteggio CVSS 4.0 di 9.2 e possono consentire a un attaccante non autenticato di eseguire codice da remoto (Remote Code Execution, RCE) sui server vulnerabili.

Il 21 ottobre 2026 il team di sicurezza PHP ha rilasciato gli aggiornamenti per correggerle, quando gli attacchi erano già iniziati.

Ma la portata di PHP2Shell va oltre due nuove CVE: mostra quanto una vulnerabilità in una componente software condivisa possa trasformarsi rapidamente in un rischio per un intero ecosistema digitale.

Il problema non è WordPress. È ciò che c'è sotto

PHP è alla base di una parte significativa del web, dai siti aziendali alle piattaforme di e-commerce, fino a Content Management System (CMS) come WordPress, Drupal e Joomla.

Normalmente, quando si parla di vulnerabilità di un CMS, l'attenzione si concentra sul codice dell'applicazione, sui plugin o sulle estensioni installate.

Con PHP2Shell il problema è diverso.

Le vulnerabilità si trovano direttamente nel motore PHP, nello specifico nei meccanismi con cui gestisce la memoria e gli errori critici durante l'elaborazione delle richieste.

In determinate condizioni, questi errori possono lasciare riferimenti a porzioni di memoria non più valide, che vengono successivamente riutilizzate. Un attaccante può sfruttare questo comportamento per leggere informazioni sensibili dalla memoria del processo o arrivare a eseguire codice arbitrario sul server.

I ricercatori di Wiz e Calif hanno dimostrato attacchi RCE non autenticati su WordPress, Drupal, Joomla e Magento, pur in assenza di vulnerabilità nel codice di queste applicazioni.

In alcuni scenari, come con Apache mod_php, l'attacco può essere innescato prima ancora che venga eseguito il codice dell'applicazione.

È questo l'aspetto più critico: proteggere e aggiornare l'applicazione non significa necessariamente aver messo in sicurezza tutte le tecnologie su cui funziona.

PHP2Shell: due vulnerabilità, un rischio esteso

Le vulnerabilità identificate presentano caratteristiche tecniche differenti, ma condividono un problema legato alla gestione dello stato interno di PHP.

CVE-2026-109618 – RCE attraverso la gestione della memoria. Un errore durante la gestione di condizioni di memoria esaurita (Out-of-Memory) può interrompere l'elaborazione mentre alcune strutture interne non sono ancora completamente inizializzate. La fase di chiusura della richiesta può utilizzare dati non validi, aprendo la strada alla corruzione della memoria e all'esecuzione di codice.

CVE-2026-109619 – RCE attraverso riferimenti di memoria obsoleti. Alcune informazioni interne possono rimanere accessibili anche dopo che la memoria a cui fanno riferimento è stata liberata. Quando lo stesso processo gestisce una nuova richiesta, questi riferimenti possono essere utilizzati impropriamente, consentendo ulteriori forme di corruzione della memoria.

Le conseguenze di uno sfruttamento riuscito possono comprendere la compromissione del server, l'accesso a dati sensibili, la sottrazione di credenziali e token di autenticazione, fino all'installazione di malware o web shell.

Secondo Unit 42 di Palo Alto Networks, le rilevazioni hanno individuato oltre 22,6 milioni di istanze esposte potenzialmente vulnerabili.

Un dato che restituisce la dimensione del problema, pur senza indicare che tutte queste istanze siano effettivamente sfruttabili o già compromesse.

Il rischio nascosto nelle dipendenze software

PHP2Shell riporta al centro una questione spesso sottovalutata: un'organizzazione può conoscere le applicazioni che utilizza, senza avere piena visibilità delle componenti tecnologiche da cui dipendono.

Server web, runtime, librerie, container e servizi gestiti costituiscono una rete di dipendenze che può essere difficile ricostruire, soprattutto negli ambienti IT più articolati.

Quando una vulnerabilità interessa una componente condivisa, le conseguenze possono estendersi contemporaneamente a numerose applicazioni, anche sviluppate e gestite da soggetti differenti.

Non significa che tutti i sistemi presentino lo stesso livello di rischio.

La reale esposizione dipende dalla versione installata, dalla configurazione, dall'accessibilità del servizio e dalla possibilità di sfruttare la vulnerabilità nello specifico ambiente.

È qui che la gestione delle vulnerabilità deve andare oltre la semplice identificazione delle CVE.

Sapere che una vulnerabilità esiste è il primo passo. Capire dove si trova, quali servizi espone e quale impatto potrebbe avere sull'operatività aziendale è ciò che consente di stabilire le corrette priorità di intervento.

Come proteggersi da PHP2Shell

La priorità è applicare gli aggiornamenti di sicurezza distribuiti dal team PHP il 21 ottobre 2026.

Le versioni che includono le correzioni sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le versioni 8.1 e precedenti, non più supportate, richiedono una valutazione specifica, considerando gli aggiornamenti eventualmente distribuiti dai fornitori o la necessità di migrare a release supportate.

Per ridurre il rischio occorre intervenire su più livelli:

• Identificare i sistemi esposti. Individuare le applicazioni e i servizi che utilizzano PHP, verificando versioni, configurazioni e accessibilità da Internet, senza trascurare container e ambienti gestiti da fornitori esterni.

• Applicare tempestivamente le patch. Aggiornare le installazioni interessate, riavviare i processi PHP e ricostruire le immagini container quando necessario. Per i pacchetti distribuiti dai vendor, verificare la presenza delle correzioni anche quando il numero di versione non cambia.

• Ridurre temporaneamente la superficie di attacco. Dove non è possibile aggiornare subito, l'advisory PHP indica misure parziali, da applicare nella configurazione del server (non con ini_set() o .user.ini) riavviando i processi PHP: session.upload_progress.enabled=0, fatal_error_backtraces=0 su PHP 8.5 e memory_limit=-1, compensato da limiti di memoria a livello di container o cgroup. Per i sistemi critici va valutato l'isolamento temporaneo.

• Verificare eventuali segnali di compromissione. Analizzare i log almeno dal 17 ottobre, cercando richieste multipart anomale (ad esempio con il campo PHP_SESSION_UPLOAD_PROGRESS), errori di memoria esaurita, riavvii inattesi dei processi PHP, file sospetti e connessioni in uscita non giustificate. La memoria esposta può contenere segreti: valutare la rotazione di credenziali e token.

La disponibilità di una patch non garantisce, da sola, che un sistema non sia già stato compromesso.

Per questo la remediation dovrebbe essere accompagnata da attività di monitoraggio e, quando necessario, da verifiche mirate per escludere attività malevole precedenti all'aggiornamento.

Oltre la vulnerabilità: dalla gestione delle CVE alla gestione del rischio

PHP2Shell dimostra che anche componenti software consolidate possono nascondere vulnerabilità critiche per oltre un decennio.

Il punto non è eliminare ogni vulnerabilità prima che possa essere scoperta. È sviluppare la capacità di comprendere rapidamente quali rappresentino un rischio concreto per la propria organizzazione.

Questo richiede visibilità sugli asset e sulle dipendenze tecnologiche, capacità di correlare le vulnerabilità al contesto aziendale e monitoraggio continuo delle attività potenzialmente malevole.

In questa prospettiva, Vulnerability Management e Managed Detection & Response diventano attività complementari: la prima aiuta a identificare e ridurre l'esposizione, la seconda a individuare e contenere eventuali tentativi di compromissione, anche mentre le vulnerabilità sono ancora in fase di risoluzione.

Perché una CVE critica non rappresenta necessariamente lo stesso rischio per ogni azienda.

E soprattutto, conoscere una vulnerabilità non equivale a conoscere il proprio rischio.

È questa la lezione più importante di PHP2Shell: quando una falla interessa le fondamenta del web, la capacità di difendersi dipende anche da quanto bene un'organizzazione conosce le proprie.