# Falsi consigli pericolosi su PHP2Shell che circolano in questo periodo

> Consigli su PHP2Shell sotto verifica: quali suggerimenti in circolazione non proteggono o danneggiano e cosa raccomandano php.net, BSI e specialisti.

Fonte: https://phpsos.de/it/blog/gefaehrliche-falschtipps/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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](https://phpsos.de/it/blog/session-upload-progress-abschalten/). L'elenco completo delle misure transitorie si trova in [Misure immediate senza patch](https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-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](https://phpsos.de/it/blog/waf-oder-update/).

## 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:

1. **Fonte:** la raccomandazione proviene da php.net, dalla Sua distribuzione, dal BSI o da un autore specializzato citato per nome?
2. **Pretesa:** la misura è descritta come transitoria o come soluzione? Con PHP2Shell solo l'aggiornamento è una soluzione.
3. **Effetto collaterale:** che cosa si rompe quando la misura è attiva? Un consiglio senza indicazione degli effetti collaterali è incompleto.
4. **Luogo di attuazione:** l'impostazione è applicata lato server e in modo non sovrascrivibile, seguita da un riavvio di tutti i worker?

> **Importante:**
> 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](https://phpsos.de/it/leistungen/waf-virtuelles-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.

## Fonti

- [php.net: segnalazioni di sicurezza](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell e versioni di PHP](https://www.drweb.de/php2shell-update-php-versionen/)
- [Blog di Cloudflare](https://blog.cloudflare.com/)