In breve: molti consigli su PHP2Shell che circolano in questo periodo nei forum e sui social network non proteggono o addirittura danneggiano: bloccare le richieste con cookie di sessione, nascondere i messaggi di errore, impostare valori tramite .user.ini o aggiornare solo il CMS. php.net è inequivocabile: non esistono misure transitorie complete, l'aggiornamento di PHP con riavvio di tutti i processi è l'unica via sicura.
Perché in questa situazione i falsi consigli sono pericolosi
Con una vulnerabilità critica che attira grande attenzione nasce un mercato per soluzioni rapide. I consigli vengono condivisi, abbreviati e inoltrati, spesso senza le limitazioni della fonte originale. Con PHP2Shell si aggiunge che i dettagli, secondo i rapporti, sono diventati noti già prima della data ufficiale e che la situazione nei primi giorni era confusa.
Un falso consiglio danneggia due volte. Lascia aperta la vulnerabilità e dà la sensazione di aver fatto qualcosa. Proprio questa sensazione fa sì che l'aggiornamento vero e proprio resti lì. Alcuni consigli, inoltre, paralizzano il proprio sito.
Nove consigli sotto verifica
La tabella seguente riassume ciò che abbiamo letto spesso negli ultimi giorni e vi contrappone le affermazioni delle fonti primarie.
| Consiglio in circolazione | Perché non regge | Che cosa vale invece |
|---|---|---|
Bloccare tutte le richieste con PHPSESSID |
Respinto espressamente dagli autori specializzati; paralizza login e carrelli | Aggiornare PHP |
session.upload_progress.enabled=0 basta |
Secondo i rapporti specializzati non chiude entrambe le vulnerabilità | Misura transitoria sensata, l'aggiornamento resta obbligatorio |
Impostare i valori con ini_set() o .user.ini |
php.net lo sconsiglia espressamente | Lato server in php.ini, pool FPM o configurazione del server |
| Nascondere i messaggi di errore | Secondo php.net error_reporting, display_errors o @ non aiutano |
Aggiornamento; non mostrare comunque pubblicamente l'output degli errori |
Limitare la memoria con RLIMIT_AS o RLIMIT_DATA |
php.net avverte che proprio questo può innescare la situazione vulnerabile | Limite tramite container o cgroup |
| Aggiornare WordPress o i plugin | La vulnerabilità sta nell'interprete PHP, non nel CMS | Aggiornare il runtime PHP |
| Cloudflare o un altro WAF bastano | Protezione solo per il traffico che passa dal servizio; i server raggiungibili direttamente restano aperti | WAF come livello aggiuntivo, non come sostituto |
| Ricaricare il servizio invece di riavviarlo | Secondo Red Hat un reload non basta, i worker esistenti possono mantenere il vecchio stato | Riavviare completamente tutti i worker |
| Aggiornato significa pulito | Una patch non rimuove il software dannoso introdotto in precedenza | Conservare i log dal 20/10 e cercare tracce |
I tre equivoci più frequenti spiegati meglio
Il divieto dei cookie
Il consiglio di respingere tutte le richieste con il cookie di sessione PHPSESSID suona tecnico e deciso. Gli autori specializzati lo respingono espressamente. In pratica rompe tutto ciò che richiede una sessione: account clienti, carrelli, aree di amministrazione, moduli con protezione contro la falsificazione. Una protezione contro la vulnerabilità non è.
L'unica impostazione che risolve tutto
session.upload_progress.enabled=0 è nelle raccomandazioni di php.net ed è il rimedio indicato contro CVE-2026-115560. In alcuni articoli ne è diventato «PHP2Shell disattivato». Secondo i rapporti specializzati, questa impostazione da sola non chiude però entrambe le vulnerabilità. Anche memory_limit=-1 elimina, secondo php.net, solo l'innesco controllabile; un errore di memoria a un livello più profondo può comunque raggiungere il percorso vulnerabile. Su PHP 8.5 fatal_error_backtraces=0 blocca, secondo php.net, solo il percorso confermato tramite i backtrace.
Come impostare comunque l'opzione in modo corretto e permanente lo descrive l'articolo Disattivare session.upload_progress. L'elenco completo delle misure transitorie si trova in Misure immediate senza patch.
Lo scudo davanti
Cloudflare, secondo le proprie dichiarazioni, ha regole di protezione attive dal 21 ottobre, anche per i clienti del piano gratuito. Cloudflare stessa indica però dei limiti: la protezione agisce solo sul traffico che passa da Cloudflare. Se il server di origine è raggiungibile direttamente, viene aggirata. Inoltre Cloudflare controlla anche la risposta del server, perché la sola richiesta non sempre basta. Perché un WAF non sostituisca l'aggiornamento lo spiega l'articolo WAF o aggiornamento.
Un consiglio con rischio: filtrare le richieste di upload al perimetro
Non ogni consiglio scomodo è sbagliato. Gli autori specializzati propongono come misura temporanea e non ufficiale di bloccare, sul proxy o nel WAF, le richieste multipart/form-data al di fuori dei veri percorsi di upload. Può ridurre la superficie di attacco, ma rompe moduli e upload se l'elenco dei percorsi consentiti è incompleto.
Chi percorre questa strada dovrebbe prima verificarla in un ambiente di test, concordarla con i reparti interessati e documentarla come misura a termine. Neppure questa è un sostituto dell'aggiornamento.
Molte soluzioni WAF offrono a tale scopo una modalità di osservazione, in cui le regole inizialmente si limitano a registrare anziché bloccare. Lasci girare una nuova regola così per alcuni giorni e valuti quali richieste legittime sarebbero interessate. Solo dopo passi al blocco. In questo modo evita che moduli di candidatura, portali clienti o upload di immagini nello shop smettano di funzionare senza che nessuno se ne accorga.
Come verificare un consiglio prima di applicarlo
Quattro domande separano i consigli utilizzabili da quelli pericolosi:
- Fonte: la raccomandazione proviene da php.net, dalla Sua distribuzione, dal BSI o da un autore specializzato citato per nome?
- Pretesa: la misura è descritta come transitoria o come soluzione? Con PHP2Shell solo l'aggiornamento è una soluzione.
- Effetto collaterale: che cosa si rompe quando la misura è attiva? Un consiglio senza indicazione degli effetti collaterali è incompleto.
- Luogo di attuazione: l'impostazione è applicata lato server e in modo non sovrascrivibile, seguita da un riavvio di tutti i worker?
Annoti quali misure transitorie ha applicato e quando. Così potrà verificarle in seguito in modo mirato e riconoscere se una presunta protezione abbia ritardato l'aggiornamento vero e proprio.
Come aiuta concretamente PHP SOS?
- Verifichiamo le misure già attuate presso di Lei e separiamo quelle efficaci da quelle inefficaci.
- Installiamo l'aggiornamento di PHP, riavviamo tutti i processi e documentiamo lo stato.
- Dove un aggiornamento non è ancora possibile, applichiamo le misure transitorie secondo php.net lato server e in modo documentato.
- Con WAF e virtual patching integriamo la protezione al perimetro, senza sostituire l'aggiornamento.
Domande frequenti
Bloccare le richieste con PHPSESSID protegge?
No. Gli autori specializzati respingono espressamente questo consiglio in circolazione. Paralizza accessi, carrelli e moduli, senza chiudere la vulnerabilità nell'interprete.
session.upload_progress.enabled=0 basta contro PHP2Shell?
No. L'impostazione è una delle diverse misure transitorie e, secondo i rapporti specializzati, non chiude entrambe le vulnerabilità. È sensata, ma non sostituisce l'aggiornamento di PHP.
Aiuta disattivare display_errors?
Per PHP2Shell no. php.net fa notare che nascondere le diagnosi tramite error_reporting, display_errors o l'operatore @ non aiuta. In produzione display_errors dovrebbe comunque essere disattivato per altri motivi.
Da che cosa riconosco un consiglio affidabile?
Un consiglio affidabile cita la sua fonte, descrive i limiti e definisce le misure transitorie come tali. Chi promette che una singola impostazione renda superfluo l'aggiornamento sbaglia, con PHP2Shell.