PHP2Shell: cosa puoi fare subito

Due vulnerabilità critiche di PHP, soprannominate PHP2Shell (CVE-2026-109618 e CVE-2026-109619), consentono a un utente malintenzionato di eseguire codice su un server web senza effettuare l'accesso. PHP ha un punteggio di 9,2 su 10 per entrambe le vulnerabilità e le relative correzioni saranno rilasciate il 21 ottobre 2026 alle 14:00 UTC. I dettagli sono trapelati un giorno prima e sono già stati segnalati degli attacchi.

Se il tuo sito è basato su PHP, ecco cosa puoi fare oggi, dalla soluzione definitiva alle soluzioni temporanee. Per maggiori dettagli tecnici e una cronologia in tempo reale, leggi Avviso di Sansec.

1. Aggiorna PHP il prima possibile

L'unica vera soluzione è aggiornare PHP. Tutto il resto descritto in questo articolo serve solo a ridurre il rischio nel frattempo.

• Versioni fisse previste: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Questi numeri provengono da ricercatori di sicurezza e da tracker di distribuzioni Linux; PHP stesso li conferma solo con il rilascio.
• Versioni precedenti (8.1, 8.0, 7.x, 5.x) sono fuori produzione e non è previsto alcun aggiornamento ufficiale. Se utilizzi uno di questi dispositivi, pianifica un aggiornamento ora e mantieni attive le soluzioni temporanee descritte di seguito.
• Verifica che il pacchetto contenga effettivamente la correzione. Il solo numero di versione può essere fuorviante, perché le distribuzioni spesso effettuano il backport delle correzioni. Cerca il numero CVE nel registro delle modifiche, ad esempio con Registro delle modifiche di apt php8.3-cli (Debian/Ubuntu) o rpm -q --changelog php (RHEL/Alma/Rocky).
• Riavviare PHP dopo l'aggiornamento (Per esempio systemctl restart php8.3-fpm), altrimenti il vecchio codice continua a essere eseguito.
• Su hosting condiviso, chiedi al tuo provider di hosting quando implementeranno la versione di PHP aggiornata.

2. Disattiva l'avanzamento del caricamento della sessione

Le prime analisi indicano che la vulnerabilità risiede nella funzionalità di PHP relativa all'avanzamento del caricamento delle sessioni, che è attiva per impostazione predefinita e si attiva al momento del caricamento di un file. Disattivandola e abilitando la modalità di sessione rigorosa si riduce l'esposizione al rischio. Questa soluzione non risolve la vulnerabilità e i ricercatori di sicurezza avvertono che potrebbe bloccare solo uno dei due bug.

Aggiungi questo a php.ini, .user.ini oppure le impostazioni PHP del tuo host:

session.upload_progress.enabled = Off session.use_strict_mode = 1

Se utilizzi PHP-FPM, puoi impostarlo anche per ogni pool:

php_admin_flag[session.upload_progress.enabled] = off

Ricarica PHP in seguito. Pochissimi siti si affidano a barre di avanzamento del caricamento basate su questa funzionalità, quindi questa modifica raramente causa problemi.

3. Bloccare i caricamenti sul server web (nginx)

I percorsi di attacco noti utilizzano richieste multipart, il formato che i browser usano per caricare i file. Bloccarle sul server web le interrompe prima che raggiungano PHP. Sansec raccomanda questa soluzione come misura temporanea.

Aggiungi questo all'interno del tuo server { } blocco, fuori da qualsiasi posizione:

if ($http_content_type ~* "multipart/form-data") { rewrite ^ /__upload_blocked last; } location = /__upload_blocked { internal; default_type text/plain; return 403 "Il caricamento non è attualmente consentito a causa di un grave bug. Torneremo presto.\n"; }

I visitatori che ora tentano di caricare un file ricevono un messaggio chiaro invece di una semplice pagina di errore. interno la linea significa che nessuno può aprire /__caricamento_bloccato direttamente, e le altre pagine di errore rimangono invariate.

Prova e ricarica:

nginx -t && nginx -s reload curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Entrambi arricciare i test dovrebbero restituire 403 con il messaggio. Se una sottopagina si carica ancora, controlla che il Se si siede direttamente in server { } e non all'interno di un posizione, e che tu abbia modificato il server blocco che effettivamente serve il sito. Una normale richiesta di pagina senza caricamento dovrebbe comunque funzionare.

4. Bloccare i caricamenti sul server web (Apache / .htaccess)

Su Apache 2.4, aggiungi questo al .htaccess nella directory principale del tuo documento. Funziona in qualsiasi punto del file, anche prima o dopo le regole del tuo CMS:

ErroreDocumento 403 "Il caricamento non è attualmente consentito a causa di un grave bug. Torneremo presto." Richiesta di tutti i permessi negata

Apache rifiuta la richiesta prima che vengano eseguite le regole di riscrittura, quindi ogni URL è coperto, non solo la home page. Una versione basata su Regola di riscrittura [F] È facile sbagliare: se posizionato al di sotto delle regole di un CMS, blocca solo la home page mentre le sottopagine possono ancora accedere a PHP.

• Utilizzare il .htaccess Apache legge effettivamente per il tuo sito. Per Magento 2 è spesso quello in pub/.
• Una sottocartella con la propria .htaccess, come ad esempio una seconda installazione di WordPress, potrebbe richiedere lo stesso blocco.
• Un errore 500 dopo il salvataggio di solito significa che il tuo host non consente queste direttive in .htaccess. Chiedi loro di consentirlo o di aggiungere la regola nella configurazione del server.

Testa la home page e almeno una sottopagina. Entrambe dovrebbero restituire 403 con il messaggio:

curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Se una sottopagina restituisce comunque la pagina principale, il blocco non è attivo per quell'URL.

Cosa aspettarsi e quando annullare l'effetto

Il blocco del server web interrompe tutte le richieste multipart, non solo i caricamenti di file. Aspettati che queste funzioni smettano di funzionare finché non lo rimuovi:

• Caricamento di file e immagini, anche nella tua area di amministrazione o nel CMS
• Alcuni moduli ordinari, come i moduli di contatto o le modifiche dei prodotti, che vengono inviati come moduli multipart
• Caricamenti in background in JavaScript, che potrebbero mostrare un errore generico invece del tuo messaggio

Le impostazioni PHP del passaggio 2 raramente causano problemi e possono rimanere invariate. Rimuovi il blocco del server web una volta che PHP è stato aggiornato e hai verificato la correzione nel registro delle modifiche del pacchetto. Quindi ricarica nginx o Apache ed esegui un test di caricamento.

Per approfondire

• Vulnerabilità di esecuzione di codice remoto (RCE) critiche in PHP: CVE-2026-109618 e CVE-2026-109619 (Sansec): avvisi, misure di mitigazione e cronologia in tempo reale
• Prossima release critica di sicurezza di PHP (Annuncio PHP)
• Avviso di sicurezza importante: PHP è vulnerabile a una grave vulnerabilità di esecuzione di codice remoto (RCE). (Patchstack)
• PHP2Shell: cosa ti protegge realmente prima della patch (The Hacker News)

Ultimo aggiornamento: 21 ottobre 2026