PHP2Shell, due falle in PHP esigono aggiornamenti urgenti sui server

Un sito WordPress perfettamente aggiornato può nascondere una vulnerabilità grave. Il motivo si chiama PHP2Shell, il nome dato a una coppia di falle nel linguaggio PHP, il software che sul server esegue le istruzioni di moltissimi siti web, dai blog ai negozi online. Il difetto si trova a un livello sottostante rispetto alle applicazioni come WordPress, che poggiano su di esso.

Le correzioni sono disponibili dal 21 ottobre 2026, mentre i fornitori di sicurezza hanno osservato traffico di attacco e tentativi di aggirare le protezioni. Per chi gestisce un sito l'urgenza consiste nel verificare quale interprete PHP stia effettivamente servendo le richieste dei visitatori, cioè quale versione del programma legga ed esegua il codice a ogni visita.

Un linguaggio presente quasi ovunque

Per capire la dimensione dell'allarme serve un dato accompagnato dal suo denominatore. Nella rilevazione del 23 ottobre 2026, PHP compare nel 69,3% dei siti di cui è identificabile il linguaggio lato server, quello che lavora sui computer che ospitano il sito e resta invisibile al visitatore. Tra i siti PHP osservati, il 26,9% utilizza ancora il ramo principale 7, una generazione più vecchia del linguaggio.

Questi numeri raccontano quanto il web dipenda da PHP e quanto pesino le installazioni meno recenti. Misurano l'adozione; per sapere quali siti siano realmente esposti o già compromessi servono verifiche distinte.

Due falle nel motore di PHP

PHP2Shell raccoglie due vulnerabilità, identificate dalle sigle CVE-2026-109618 e CVE-2026-109619: sono codici standard, usati a livello internazionale per distinguere ciascun difetto di sicurezza. La prima riguarda l'esaurimento della memoria. Se il programma viene interrotto nel momento sbagliato, può lasciare dati interni incompleti che PHP tratta poi come validi. La seconda conserva riferimenti a memoria già liberata, riutilizzabili durante una richiesta successiva: un po' come una chiave che continua ad aprire una stanza già assegnata a un altro ospite.

Sono errori nei meccanismi con cui il motore gestisce richieste e guasti. In condizioni sfruttabili permettono l'esecuzione remota di codice, cioè l'invio di istruzioni dell'attaccante che il server esegue come proprie.

Le condizioni operative fanno la differenza. Il rischio maggiore riguarda Apache con mod_php, la modalità che integra PHP direttamente nel server web: è stato dimostrato un attacco senza autenticazione, quindi senza credenziali, prima ancora dell'esecuzione dell'applicazione. Anche PHP-FPM, che gestisce PHP attraverso processi separati, rientra nel perimetro, con percorsi di sfruttamento dipendenti dall'applicazione. WordPress, Drupal e Joomla, tre piattaforme molto usate per costruire siti, sono esempi importanti dell'ecosistema interessato; il difetto risiede nell'interprete che condividono.

Come controllare il proprio sito

Le versioni correttive sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Chi ha il sito su un hosting può chiedere al fornitore se abbia aggiornato l'ambiente che lo esegue e riavviato i processi interessati. Chi amministra direttamente un server deve controllare lo stesso passaggio: installare il pacchetto lascia aperta la verifica del software ancora in memoria, perché un programma già avviato continua a usare la vecchia versione finché non riparte. Il comando php -v mostra l'interprete da riga di comando, che può differire da quello utilizzato dal sito. L'aggiornamento del solo sistema di gestione dei contenuti lascia irrisolto il problema sottostante.

L'aggiornamento del solo WordPress lascia aperta la falla nel PHP del server

Per le installazioni più vecchie la numerazione va letta con cautela. I distributori, cioè chi prepara e mantiene i pacchetti software dei sistemi Linux, possono trasferire una correzione su un ramo precedente mantenendone la versione: è il "backport". Uno scanner basato soltanto sul numero può quindi segnalare come vulnerabile un pacchetto già corretto. Il progetto PHP ha inoltre fornito correzioni minime nel codice sorgente per alcuni rami fuori supporto, un intervento eccezionale che richiede competenze di compilazione oppure un distributore che prepari i pacchetti. La prova utile resta l'avviso di sicurezza applicabile al pacchetto realmente installato.

Anche dopo l'aggiornamento va seguito l'avviso aggiuntivo pubblicato il 23 ottobre 2026, successivo al riferimento iniziale della notizia. Riguarda un ulteriore percorso di esecuzione remota nella funzione che registra l'avanzamento degli upload, i caricamenti di file, possibile con una combinazione insolita di configurazione e codice applicativo. L'indicazione prudenziale è impostare session.upload_progress.enabled=0 fino alla prossima correzione ordinaria; le applicazioni che mantengono invariato il gestore di serializzazione delle sessioni, il meccanismo con cui vengono salvati i dati di sessione, possono conservare la funzione. È uno sviluppo distinto dalle due falle iniziali.

Nell'attesa delle patch, limitare l'accesso ai servizi e applicare filtri alle richieste può ridurre l'esposizione. Un WAF, il firewall che esamina il traffico delle applicazioni web, aggiunge una protezione temporanea; la sua efficacia dipende però dalle varianti dell'attacco e dalla configurazione. Le modifiche ai limiti di memoria richiedono particolare cautela, perché possono trasferire il rischio sulla disponibilità del servizio. Le indicazioni vanno quindi applicate seguendo il proprio distributore, insieme a un percorso di aggiornamento.

Password e chiavi nella memoria del server

Il danno possibile comprende conseguenze meno visibili di una pagina alterata. I ricercatori hanno dimostrato anche la lettura della memoria dei processi senza ottenere prima l'esecuzione di codice: tra i dati potenzialmente esposti figurano password, token di autenticazione e chiavi di accesso ai servizi. Cercare soltanto una web shell, il componente malevolo che permette di comandare il server attraverso il web, coprirebbe dunque solo parte del problema. Errori di memoria, richieste anomale e riavvii inattesi meritano un esame correlato, pur avendo anche spiegazioni legittime.

La lettura della memoria espone password e chiavi anche senza codice malevolo sul server

Per un'organizzazione italiana l'eventuale sottrazione di dati apre anche il fronte del Regolamento generale sulla protezione dei dati (GDPR). Quando una violazione comporta un rischio per i diritti e le libertà delle persone, il titolare del trattamento deve notificarla al Garante per la protezione dei dati personali senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza dell'accaduto. La presenza di PHP vulnerabile richiede una valutazione tecnica; l'obbligo di notifica scatta davanti a una violazione di dati personali, secondo le condizioni previste dal regolamento.

Una divulgazione sotto pressione

La gestione dell'annuncio mostra quanto sia delicata questa catena. Nella ricostruzione ufficiale, il 20 ottobre 2026 circolarono inizialmente gli identificativi delle vulnerabilità, privi di dettagli tecnici; successivamente comparve un video dimostrativo. Il rilascio fu anticipato dal 22 ottobre 2026 alle 14:00 UTC al 21 ottobre alle 14:00 UTC. Attendere la preparazione dei pacchetti dava agli amministratori un aggiornamento utilizzabile; pubblicare immediatamente avrebbe favorito soprattutto chi poteva compilare autonomamente. Quanti attacchi in più o in meno ci sarebbero stati con una scelta diversa resta indimostrabile.

La velocità degli strumenti di ricerca aggiunge pressione. Il gruppo Wiz riferisce che l'intelligenza artificiale ha facilitato l'adattamento degli exploit, i programmi che sfruttano una falla, a configurazioni differenti: una testimonianza degli autori, senza una misura indipendente dell'efficienza degli attaccanti. Ryan Austin, ricercatore di Calif, precisa invece che la propria scoperta iniziale utilizzò modelli generalmente disponibili e conoscenza storica del bersaglio. Il contributo umano comprendeva la scelta di dove cercare e l'interpretazione dei risultati.

Il problema di memoria era stato intravisto già nel 2024. La correzione si era arenata fra compatibilità, possibili regressioni, decisioni difficili e scarsità di sviluppatori con una conoscenza profonda del motore; le regressioni sono i nuovi difetti che una modifica può introdurre. Qui emerge lo squilibrio strutturale: trovare più difetti aumenta anche il lavoro necessario per valutarli e correggerli. Il precedente della vulnerabilità PHP-CGI su Windows, ancora oggetto di sfruttamento crescente nel marzo 2025 dopo la disponibilità delle correzioni, mostra inoltre quanto possa durare la fase degli aggiornamenti incompleti, pur riguardando condizioni tecniche differenti.

Per chi visita i siti, l'intervento decisivo resta sul server. Per chi li gestisce, una risposta generica dell'hosting sull'avvenuto aggiornamento lascia un punto concreto da chiarire: quale pacchetto corretto stia usando quel sito e se tutti i processi che ricevono le richieste siano stati effettivamente riavviati.