In breve: PHP2Shell indica due vulnerabilità critiche in PHP stesso, attraverso le quali gli aggressori possono eseguire codice dannoso senza alcuna autenticazione. Se Le serve un aiuto rapido per questa vulnerabilità PHP, ci occupiamo da remoto di inventario, patch o misura provvisoria, riavvio di tutti i processi PHP e di una prima ricerca di tracce. Alla fine riceve una conferma scritta dello stato.
Aiuto per la vulnerabilità PHP: perché agire adesso
Il 21/10/2026 alle 16:00, ora tedesca, il progetto PHP ha pubblicato le patch per CVE-2026-109618 e CVE-2026-109619. Entrambe le vulnerabilità hanno un punteggio CVSS v4.0 di 9,2 e consentono l'esecuzione di codice dannoso da remoto, senza che nessuno debba autenticarsi. Sono interessate le modalità di esecuzione abituali: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.
Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha dichiarato il livello di allerta 3 (arancione). Raccomanda l'aggiornamento immediato e, se questo non è possibile subito, di scollegare temporaneamente i server web dalla rete. Palo Alto Networks (Unit 42) ha contato più di 22,6 milioni di istanze esposte e potenzialmente vulnerabili. Secondo il BSI, inizialmente non erano noti attacchi riusciti su larga scala, ma Cloudflare ha già segnalato tentativi di attacco.
Per la direzione e i titolari questo significa: ogni server PHP raggiungibile pubblicamente è un candidato, finché non è dimostrato il contrario. Una spiegazione comprensibile della vulnerabilità si trova alla pagina Che cos'è PHP2Shell?.
A chi è rivolta l'assistenza urgente PHP2Shell?
Alle imprese, alle agenzie e agli enti pubblici che gestiscono applicazioni PHP e non possono o non vogliono affrontare da soli la situazione con la profondità necessaria. Riguarda i root server e i vServer propri così come i server con Plesk o cPanel, gli ambienti a container e i server gestiti in cui la competenza non è chiara.
Anche chi ha un hoster ha spesso bisogno di supporto. Molti fornitori applicano dei backport; in tal caso Plesk, ad esempio, continua a mostrare 8.2.34 anche se lo stato dei pacchetti è aggiornato. Al contrario, può comparire un nuovo numero di versione mentre vecchi processi PHP girano ancora in memoria. Quali stati si considerino corretti è indicato alla pagina Quali versioni di PHP sono interessate?.
Come aiuta concretamente PHP SOS?
- Inventario: rileviamo tutte le installazioni PHP, le modalità di esecuzione e le versioni sui Suoi server, compresi lo stato dei pacchetti e i processi in esecuzione. Il risultato è un elenco che indica quali sistemi sono interessati, corretti o poco chiari.
- Patch o misura provvisoria: dove possibile, installiamo le versioni corrette (8.5.12, 8.4.27, 8.3.36, 8.2.35) oppure i pacchetti della Sua distribuzione. Se non è possibile subito, applichiamo le misure provvisorie indicate da php.net e diciamo apertamente che non offrono una protezione completa.
- Riavvio e controllo: riavviamo tutti i worker e i processi PHP e verifichiamo poi che non giri più nessun processo vecchio. I nuovi file da soli non chiudono la vulnerabilità.
- Prima ricerca di tracce: salviamo i log del server a partire dal 20/10 e cerchiamo anomalie come nuovi file PHP, cronjob sconosciuti o processi insoliti. Poiché non esistono Indicators of Compromise pubblicati e confermati, questa verifica si basa sull'analisi del comportamento.
- Conferma e passi successivi: riceve un rapporto scritto. In caso di sospetta compromissione consigliamo i passi successivi adatti, ad esempio la rimozione del malware o un'indagine forense.
Una patch non rimuove il malware già introdotto e non dimostra che prima non sia successo nulla. Per questo l'assistenza urgente comprende sempre uno sguardo al periodo a partire dal 17/10/2026.
Che cosa riceve da noi
- una panoramica di tutti i server verificati, con versione di PHP, stato dei pacchetti, modalità di esecuzione e stato della patch
- la documentazione degli aggiornamenti installati o delle misure provvisorie adottate
- la prova che tutti i processi PHP sono stati riavviati
- una valutazione della ricerca di tracce, distinta in provato, probabile e sconosciuto
- un elenco dei punti aperti, ad esempio i sistemi con PHP 8.1 o precedente
Questo rapporto può essere inoltrato alla direzione, ai responsabili della protezione dei dati o all'assicuratore. Non sostituisce la valutazione giuridica.
Che cosa ci serve da Lei
- Accesso: accesso SSH o al pannello con privilegi sufficienti, in alternativa un'autorizzazione al Suo hoster a fornirci informazioni
- Referente: una persona autorizzata a prendere decisioni, ad esempio su una breve messa offline o su un riavvio
- Panoramica: quali siti web, shop e applicazioni girano su quali server
- Finestra di manutenzione: le Sue indicazioni su quando sono consentiti i riavvii
- Backup: informazioni su dove si trovano i salvataggi più recenti
Per gli amministratori che vogliono verificare in anticipo da soli, spesso basta questo sguardo innocuo allo stato:
php -v
# Debian/Ubuntu: pacchetti PHP installati con versione
dpkg -l | grep -i php
# processi PHP in esecuzione e loro ora di avvio
ps -eo pid,lstart,cmd | grep -i php
Che cosa non promettiamo
Non promettiamo una sicurezza assoluta né l'affermazione che il Suo server non sia mai stato attaccato, se le prove non lo consentono. Lavoriamo sull'incidente finché non è concluso e documentato. Se sussista un obbligo di notifica ai sensi del GDPR o se debba informare la Sua assicurazione, lo chiarisca per favore con il responsabile della protezione dei dati, un avvocato o l'assicuratore. Noi forniamo i fatti tecnici a questo scopo.
Se Le serve soltanto l'aggiornamento con relativa conferma, fa al caso Suo il nostro servizio di patch PHP. Se ci sono già segni di un attacco, il punto di partenza giusto è l'assistenza urgente per sito web hackerato.
Domande frequenti
È sufficiente che il mio hoster abbia aggiornato PHP?
Può bastare, se l'hoster conferma per iscritto lo stato dei pacchetti e tutti i processi PHP sono stati riavviati. Il solo numero di versione visualizzato non costituisce una prova, perché le distribuzioni applicano dei backport. Se il server sia già stato attaccato prima, in ogni caso una patch non lo chiarisce.
Il mio sito web deve andare offline per l'assistenza urgente?
Non necessariamente. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente i server web dalla rete se l'aggiornamento non è subito possibile. Se nel Suo caso sia necessario lo decidiamo insieme dopo l'inventario.
Un aggiornamento di WordPress o Shopware protegge da PHP2Shell?
No. PHP2Shell si trova in PHP stesso, non nel CMS. Aggiornare il CMS resta sensato, ma non chiude questa vulnerabilità.
Che cosa succede con PHP 8.1 o versioni precedenti?
Per queste versioni il progetto PHP non rilascia più aggiornamenti ufficiali, solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Mettiamo in sicurezza il server in via provvisoria e pianifichiamo con Lei il passaggio a una versione supportata.