PHP2Shell: vulnerabilità PHP, CVE e guida agli aggiornamenti urgenti

PHP2Shell richiede un aggiornamento urgente dei server che eseguono PHP. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619, annunciate il 20 ottobre 2026 e corrette il 21 ottobre, possono consentire l’esecuzione remota di codice senza autenticazione. Il progetto PHP assegna a entrambe un punteggio CVSS 4.0 di 9,2 su 10. La priorità è verificare il motore PHP effettivamente usato da ogni sito, applicare la correzione e controllare il servizio dopo l’intervento.

Guida aggiornata il 21 ottobre 2026. Stato delle patch verificato durante la preparazione: disponibilità e indicazioni dei fornitori possono cambiare rapidamente. Avviso ufficiale PHP.

Se gestisci un sito aziendale, un e-commerce o un’applicazione su hosting, questo problema riguarda una componente che spesso non compare tra gli aggiornamenti del CMS. Avere WordPress aggiornato non dimostra che PHP sia corretto. E la dicitura “PHP 8.3” non identifica la revisione di sicurezza installata.

Non sai se il tuo server è sicuro? Contatta WebAlchemy per verificare versione PHP, configurazione dell’hosting e aggiornamenti necessari. Possiamo aiutarti a capire cosa controllare e come organizzare l’intervento.

Che cos’è PHP2Shell: il rischio per siti, e-commerce e applicazioni

PHP2Shell è il nome con cui vengono indicate le due vulnerabilità del runtime PHP. Il repository ufficiale NCSC-NL raccoglie informazioni operative e prodotti potenzialmente coinvolti. PHP è impiegato da CMS, webmail e applicazioni aziendali: l’inventario deve comprendere anche componenti incorporate nei prodotti di terze parti.

“Remote Code Execution”, o RCE, significa che un attaccante può arrivare a eseguire codice nel processo vulnerabile. Il termine “senza autenticazione” indica che non è necessario possedere prima un account valido. Nei casi confermati l’esecuzione avviene con i privilegi dell’utente del processo web: non equivale automaticamente ad accesso root, ma può già essere sufficiente a compromettere l’applicazione.

Le conseguenze possibili dipendono dai permessi e dall’isolamento del server. Un processo web che può leggere configurazioni e credenziali del database offre un impatto diverso da un servizio rigidamente isolato. Per un’azienda, gli scenari da valutare comprendono accesso non autorizzato ai dati dell’applicazione, modifica dei contenuti, indisponibilità del sito e uso dell’ambiente compromesso per ulteriori attività. Sono rischi da analizzare sul sistema reale, non la prova che ogni installazione vulnerabile sia già stata violata.

CVE-2026-109618 e CVE-2026-109619: due problemi distinti

CVE-2026-109618: corruzione della memoria durante un errore OOM

La prima falla riguarda la gestione degli errori di memoria esaurita, chiamati out-of-memory o OOM. In alcuni passaggi PHP può interrompere una richiesta mentre strutture interne non sono ancora inizializzate completamente. La successiva fase di pulizia può usare quei dati invalidi, aprendo la strada alla corruzione della memoria e alla RCE.

L’advisory PHP sulla CVE-2026-109618 descrive un exploit completo confermato su Apache con mod_php, anche prima dell’esecuzione del codice applicativo. Per PHP-FPM, lo stesso documento distingue la suscettibilità emersa dall’analisi del codice dall’assenza, in quell’advisory, di un exploit completo dimostrato per questa specifica falla. Non significa che PHP-FPM possa evitare l’aggiornamento.

CVE-2026-109619: stato interno residuo tra richieste

La seconda falla riguarda informazioni interne appartenenti a una richiesta che possono restare raggiungibili dopo la liberazione della memoria. Una richiesta successiva, servita dallo stesso worker, può riutilizzare quello stato non più valido prima che la normale inizializzazione lo ripulisca.

L’advisory PHP sulla CVE-2026-109619 documenta percorsi legati al ciclo di vita delle sessioni e alle informazioni raccolte sugli errori fatali. La RCE del percorso relativo alle sessioni è stata validata sia su mod_php sia su FPM; per FPM occorre un’operazione applicativa adatta. Aumentare i worker o riciclarli più spesso non elimina la vulnerabilità.

La distinzione conta: non esiste un unico interruttore di configurazione che risolva entrambi i problemi. E proteggere il login del CMS non è una risposta sufficiente ai percorsi che si attivano prima del codice del sito.

Siti istituzionali offline: una misura precauzionale, non la prova di un attacco

Il caso ha già avuto conseguenze sulla disponibilità dei servizi. Il National Cyber Security Centre dei Paesi Bassi ha dichiarato di aver temporaneamente messo offline il proprio sito ncsc.nl per precauzione. Le comunicazioni sono proseguite attraverso la sua community. È una conferma diretta dell’ente, non una deduzione da un errore HTTP.

Anche l’Università di Friburgo ha comunicato il distacco precauzionale di siti e servizi centrali basati su PHP, con aggiornamento e verifica prima del ripristino. Il problema coinvolge quindi anche continuità operativa, didattica e accesso ai servizi.

Il PHPocalypse Tracker segnalato dai lettori raccoglie ulteriori disservizi, compresi servizi pubblici finlandesi e olandesi. È utile per seguire il contesto, ma è un progetto indipendente: alcune voci derivano da aggregatori, altre non indicano la causa del fermo. Non è un elenco di vittime confermate né una fonte istituzionale. Gli orari indicano la prima segnalazione pubblica, non necessariamente l’inizio dell’interruzione.

Il CERT-EU raccomanda di applicare subito le patch e, quando non sia possibile, valutare l’isolamento delle applicazioni esposte a Internet fino all’applicazione e verifica della correzione. L’esistenza di dimostrazioni tecniche e PoC pubblici aumenta l’urgenza; non consente, da sola, di affermare che tutti i siti citati siano stati attaccati.

Quali versioni PHP correggono PHP2Shell

Le release correttive pubblicate il 21 ottobre sono le seguenti. La tabella si riferisce alle versioni upstream: i pacchetti delle distribuzioni possono integrare una correzione mantenendo un numero di versione di base precedente.

Fonte: PHP Security Team, avviso del 21 ottobre. Sono coinvolte le installazioni che servono richieste web, incluse PHP-FPM, Apache/mod_php, php-cgi, FrankenPHP e LiteSpeed.

PHP 7.4, 8.0, 8.1 e versioni ancora più vecchie

PHP 8.1 e precedenti sono fuori dal supporto ordinario del progetto PHP. Per la gravità dell’evento, il team ha pubblicato patch minime al sorgente per 7.4, 8.0 e 8.1. Una patch al sorgente non equivale a un pacchetto installabile già disponibile nel tuo hosting. Occorre verificare il backport effettivo del fornitore oppure pianificare il passaggio a un ramo supportato. Il NCSC-NL richiama anche il controllo separato di immagini, appliance e runtime incorporati: correggere PHP sull’host non aggiorna automaticamente tutte queste copie.

Plesk: distinguere PHP dei siti, Windows e motore del pannello

La pagina ufficiale Plesk su PHP2Shell, verificata il 21 ottobre durante la preparazione, riporta:

• Plesk per Linux: disponibili PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12; correzioni per 7.4, 8.0 e 8.1 ancora in sviluppo.
• Plesk per Windows: pacchetti correttivi ancora indicati in sviluppo.
• Componente sw-engine del pannello: hotfix pianificati per 18.0.80#11 e 18.0.81#4. Non vanno confusi con l’aggiornamento del PHP assegnato ai domini.

Questi stati sono uno snapshot, non una promessa sulla disponibilità futura. Prima dell’intervento riaprire l’avviso del produttore. Dire genericamente “Plesk è aggiornato” non documenta la correzione di tutti i suoi componenti.

Guida operativa: come verificare il server e aggiornare senza perdere il controllo

Quella che segue è una checklist operativa proposta da WebAlchemy. L’obiettivo è ottenere prove dell’intervento, non soltanto una schermata con un aggiornamento riuscito. Se non amministri il server, puoi inoltrarla al tuo hosting o al referente tecnico.

1. Identificare tutte le installazioni realmente usate

Preparare un elenco di domini, sottodomini, applicazioni, webmail, ambienti di staging e pannelli. Per ciascuno annotare versione completa, handler, sistema operativo e fornitore dei pacchetti. In un hosting con più versioni, due siti sullo stesso server possono avere un’esposizione diversa.

Su Plesk, partire da Strumenti e impostazioni → Impostazioni PHP, poi verificare la versione assegnata a ogni dominio. Per un controllo preliminare in sola lettura da SSH, l’esempio ufficiale per il ramo 8.3 è:

/opt/plesk/php/8.3/bin/php -v

Il comando identifica quel binario CLI. Da solo non dimostra quale versione stiano usando tutti i pool FPM in esecuzione. Non pubblicare una pagina phpinfo() accessibile a chiunque per fare la verifica: usa strumenti amministrativi autenticati o diagnostica temporanea protetta.

2. Stabilire chi aggiorna ogni componente

Su hosting gestito, chiedere al provider conferma scritta della copertura di entrambe le CVE. Su VPS o server dedicato, identificare chi gestisce PHP, pannello e applicazioni. Un contratto di manutenzione del CMS non implica necessariamente gestione del sistema operativo: chiarire subito la responsabilità evita che tutti presumano che intervenga qualcun altro.

Una richiesta utile al fornitore è: “Quale pacchetto e revisione correggono CVE-2026-109618 e CVE-2026-109619 sul mio ambiente? La correzione è installata e caricata dai processi web? Restano runtime legacy, pannelli o componenti incorporati da aggiornare?”.

3. Preparare backup, verifica e ripristino

Prima della modifica acquisire configurazioni, associazioni dominio/handler e stato dei servizi; verificare un backup recuperabile di dati e applicazione. Definire i controlli essenziali e chi deve eseguirli. Per una patch di emergenza, organizzare attività e responsabili subito, senza trasformare la preparazione in giorni di attesa.

Il ripristino deve considerare anche la sicurezza: tornare al vecchio binario vulnerabile può riaprire l’esposizione. Se un problema applicativo impedisce il mantenimento della patch, valutare l’isolamento del servizio durante la correzione della regressione.

4. Applicare i pacchetti corretti e ricaricare i processi

Usare i canali ufficiali del sistema o del pannello. Quando disponibile, una release correttiva nello stesso ramo evita di sommare all’emergenza un salto di versione maggiore. La migrazione da un ramo obsoleto richiede comunque una valutazione specifica di compatibilità, estensioni e applicazione.

Seguire la procedura del fornitore per il ricambio dei worker e verificare che i processi non continuino a usare il vecchio eseguibile. Non confondere un pacchetto scaricato, un aggiornamento installato e un runtime effettivamente corretto: sono tre passaggi diversi.

5. Controllare le funzioni che contano

Una homepage HTTP 200 è un primo segnale, non un collaudo completo. Verificare login, caricamento media, moduli di contatto, ricerca e operazioni amministrative. Per gli e-commerce includere carrello e checkout con modalità di test concordate, evitando ordini o addebiti reali involontari. Controllare error log e comportamento dei servizi dopo l’intervento.

6. Conservare una ricevuta e valutare eventuali anomalie

Registrare data, pacchetti prima/dopo, componenti ancora scoperti e risultati delle prove. Se emergono file sospetti, processi inattesi o accessi anomali, separare il contenimento dall’aggiornamento e preservare le evidenze. Installare una patch impedisce lo sfruttamento della falla corretta; non elimina da solo una compromissione già avvenuta. Anche l’assenza di errori nei log non certifica la sicurezza: l’advisory PHP sulla seconda CVE richiama espressamente i limiti dell’audit basato soltanto sui log.

Mitigazioni temporanee e Cloudflare: perché non sostituiscono la patch

PHP documenta misure per ridurre singoli percorsi d’attacco. Per la seconda CVE indica, tra le altre, la disabilitazione di session.upload_progress.enabled nella configurazione applicata prima del parsing, seguita dal riavvio dei worker; per PHP 8.5 cita anche fatal_error_backtraces. Queste impostazioni non coprono tutte le varianti. Un ini_set() nell’applicazione non interviene abbastanza presto.

Per la prima CVE, le indicazioni temporanee comprendono una gestione specifica del limite di memoria e limiti delle richieste. Sono scelte da valutare con un sistemista: rimuovere il limite PHP senza protezioni e controllo delle risorse può avere conseguenze sulla disponibilità. I dettagli e i vincoli sono nell’advisory OOM. Non proponiamo una sequenza di comandi universale per server diversi.

Cloudflare ha annunciato protezioni WAF per PHP2Shell e riferisce di aver osservato traffico di attacco contro i propri clienti. Il fornitore indica protezioni distribuite anche sul piano Free e, per i piani a pagamento, raccomanda di verificare il Managed Ruleset in modalità block. È una segnalazione diretta di tentativi di sfruttamento, non una prova di compromissione per ciascun sito coinvolto. Sono un livello di difesa aggiuntivo: bisogna verificare copertura effettiva del traffico, regole applicate e raggiungibilità diretta dell’origine. La semplice presenza del DNS su Cloudflare non dimostra che ogni richiesta PHP attraversi una protezione attiva.

Bloccare indiscriminatamente le richieste multipart/form-data può inoltre interrompere upload e moduli legittimi. Prima di applicare un filtro occorre conoscere i flussi che lo usano. Se manca una correzione verificabile, il CERT-EU invita a considerare l’isolamento dell’esposizione pubblica. La scelta va presa per servizio e documentata.

Domande frequenti su PHP2Shell

Il mio WordPress è aggiornato: devo fare altro?

Sì. Chiedi conferma della versione PHP che esegue il sito e della copertura di entrambe le CVE. CMS, plugin e runtime sono componenti distinti: vanno verificati separatamente.

Uso PHP-FPM: posso ignorare l’allarme?

No. PHP include FPM tra le installazioni a rischio; per CVE-2026-109619 è documentato un percorso validato che dipende dall’applicazione. Il minor rischio relativo di alcune configurazioni non equivale a immunità.

Una versione con numero più vecchio è sempre vulnerabile?

Non necessariamente: un fornitore può applicare un backport mantenendo il numero upstream. Serve la revisione completa del pacchetto e un avviso del vendor che confermi la correzione di entrambe le CVE, non una supposizione sul numero mostrato.

Devo spegnere subito ogni sito?

La priorità è aggiornare immediatamente. Se non puoi applicare e verificare la correzione, valuta con il responsabile tecnico l’isolamento del servizio, come raccomanda CERT-EU. Una pagina di manutenzione generata dallo stesso PHP vulnerabile non prova che l’esposizione sia eliminata.

Un sito presente nel tracker è stato violato?

No: il tracker raccoglie interruzioni e segnalazioni, anche precauzionali. Solo evidenze e comunicazioni specifiche permettono di parlare di attacco o fuga di dati. NCSC ha dichiarato esplicitamente una scelta preventiva.

Non sai se il tuo server è sicuro? Parti da una verifica concreta

Per affrontare PHP2Shell servono risposte precise: quale PHP usa il sito, quali pacchetti sono corretti, quali componenti restano esposti e quali prove sono state eseguite. Se il fornitore risponde soltanto “è tutto aggiornato”, chiedi questi dettagli.

WebAlchemy può affiancarti nella verifica del server e nella gestione dell’aggiornamento, dal confronto con l’hosting al controllo dei siti dopo la patch. Se vuoi approfondire il lavoro preventivo, consulta anche il nostro servizio di cybersecurity e sicurezza online.

Contattaci se non sai se il tuo server è sicuro: indica dominio, provider e pannello utilizzato, se li conosci. Non inviare password nel messaggio. Partiamo dalla situazione reale per definire verifiche e interventi necessari.

Fonti ufficiali e criterio editoriale

Analisi tecnica e stato delle patch basati sull’avviso PHP e sui due advisory del progetto, CERT-EU, NCSC-NL e bollettino Plesk, collegati nei rispettivi paragrafi. Stop precauzionali verificati sulle comunicazioni dirette di NCSC e Università di Friburgo. Cloudflare è fonte diretta per le proprie protezioni WAF. PHPocalypse Tracker è citato esclusivamente come raccolta indipendente di segnalazioni, con i suoi limiti. La checklist operativa è una proposta editoriale WebAlchemy: va adattata all’ambiente amministrato.