In breve: su Windows con IIS, PHP gira di solito come php-cgi.exe tramite FastCGI, una modalità di esecuzione espressamente interessata da PHP2Shell. Un aggiornamento PHP su IIS consiste in tre passaggi: trovare tutte le installazioni di PHP, sostituirle con una versione corretta e riciclare gli application pool. Una gestione dei pacchetti e backport come su Linux qui di norma non esistono.
Come gira PHP sotto IIS
Sui server Windows, IIS collega PHP tramite il modulo FastCGI. Per ogni versione di PHP esiste una voce FastCGI che punta a un php-cgi.exe e un'assegnazione di handler che indirizza lì i file con estensione .php. IIS avvia all'occorrenza più processi php-cgi e li tiene attivi per le richieste successive.
A differenza di Linux, qui PHP di solito non proviene da una gestione dei pacchetti, ma da un archivio ZIP delle build Windows del progetto PHP, da un'applicazione specialistica o da vecchi installer. Ciò significa: gli aggiornamenti non avvengono in automatico e non ci sono backport di un distributore. Conta il numero di versione dei file installati.
Che cosa significa PHP2Shell per i server Windows
PHP2Shell comprende CVE-2026-109618 e CVE-2026-109619 in PHP stesso, entrambe con CVSS v4.0 9.2. Entrambe consentono l'esecuzione di codice senza autenticazione. Il progetto PHP cita espressamente php-cgi tra le modalità di esecuzione interessate. Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali. I server Windows con applicazioni specialistiche girano per esperienza spesso con questi stati, perché l'applicazione richiede una determinata versione. Qui, oltre alle misure transitorie, serve un chiarimento con il produttore dell'applicazione. Il contesto su questa modalità di esecuzione si trova alla pagina php-cgi: un'eredità del passato a rischio.
Aggiornamento PHP su IIS: trovare le installazioni
I comandi PowerShell seguenti leggono soltanto. Mostrano quali installazioni di PHP usa IIS e che versione hanno. I percorsi sono esempi.
# Voci FastCGI in IIS: quale php-cgi.exe viene usato?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi
# Versione di ogni installazione trovata (percorso a titolo di esempio)
& "C:\PHP\8.3\php.exe" -v
# Processi php-cgi in esecuzione con orario di avvio
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Cerchi inoltre su tutte le unità altri php-cgi.exe, perché le applicazioni specialistiche a volte portano con sé copie proprie. Annoti per ogni installazione versione, variante (Thread Safe o Non Thread Safe) e architettura.
Installare l'aggiornamento e riciclare gli application pool
Scarichi la versione corretta dalle build Windows ufficiali del progetto PHP, collegate da php.net, nella stessa variante e con la stessa architettura. Si è dimostrato valido decomprimere la nuova versione in una nuova cartella, riprendere il php.ini esistente e le estensioni necessarie e poi portare la voce FastCGI sul nuovo percorso. Così lo stato precedente resta disponibile per un eventuale ritorno.
# Riciclare un application pool (nome a titolo di esempio)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"
# In alternativa riavviare tutti i servizi IIS
iisreset
# Controllo: tutti i processi php-cgi sono stati avviati dopo l'aggiornamento?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Ogni processo php-cgi deve avere un orario di avvio successivo all'aggiornamento e puntare al nuovo percorso. Poi testi i siti. Rimuova la vecchia cartella PHP non appena il nuovo stato gira in modo stabile, perché non venga ricollegata per errore.
I nuovi file nella cartella PHP non bastano finché girano vecchi processi php-cgi. Solo dopo aver riciclato i pool o riavviato IIS la patch è efficace.
Misure transitorie nel php.ini
Se un'installazione non può essere aggiornata subito, php.net raccomanda misure transitorie senza protezione completa. Sotto IIS imposti i valori nel php.ini centrale della rispettiva installazione. I file .user.ini e ini_set() non bastano, secondo php.net.
; php.ini dell'installazione interessata
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Con la funzione di upload, php.net indica post_max_size = 32M. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. Perché i siti non modifichino i valori tramite propri file .user.ini, nel php.ini centrale si può lasciare vuoto user_ini.filename; verifichi prima se le applicazioni ne dipendono. Poi ricicli i pool. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete i web server se l'aggiornamento non è possibile subito. Altre impostazioni sono spiegate alla pagina Configurare php.ini in modo sicuro.
Dopo l'aggiornamento
Una patch non rimuove il malware introdotto in precedenza. Conservi i log di IIS a partire dal 20/10/2026, verifichi nelle directory web la presenza di nuovi file di script e controlli attività pianificate e account utente locali alla ricerca di elementi sconosciuti. Se il server gira in un dominio, vanno controllati anche gli accessi.
Faccia attenzione inoltre ai diritti delle identità degli application pool. Se un pool gira con un account che ha diritti di scrittura sull'intera directory web o addirittura diritti amministrativi, dopo un'intrusione riuscita un aggressore può causare molti più danni. Ha senso un'identità propria e limitata per ogni pool, con diritti di scrittura solo dove l'applicazione ne ha davvero bisogno, ad esempio nella cartella di upload o di cache. In queste cartelle IIS non dovrebbe eseguire file PHP; ciò si regola tramite le assegnazioni di handler della rispettiva cartella. Verifichi anche se nella directory web ci sono vecchi file di test e di installazione come output di phpinfo, e li rimuova.
Come aiuta concretamente PHP SOS?
- Troviamo tutte le installazioni di PHP sui Suoi server Windows, comprese le copie nelle applicazioni specialistiche.
- Tramite il servizio di patch PHP sostituiamo PHP, ricicliamo i pool e documentiamo versione e orari dei processi.
- Per le versioni vecchie chiariamo con Lei e con il produttore dell'applicazione la strada verso la migrazione a una versione di PHP supportata.
- Verifichiamo i server alla ricerca di tracce di un attacco e salviamo i log.
Domande frequenti
Quale variante di PHP serve per IIS?
Per IIS con FastCGI si usa di norma la variante Non-Thread-Safe (NTS). Nell'aggiornamento faccia attenzione a scegliere di nuovo la stessa variante e la stessa architettura, in modo che le estensioni continuino a essere compatibili.
Basta decomprimere la nuova cartella PHP?
No. IIS tiene attivi per un po' i processi php-cgi.exe. Ricicli gli application pool o riavvii IIS e verifichi che non girino più vecchi processi.
Posso far girare più versioni di PHP su un solo IIS?
Sì, tramite più voci FastCGI e assegnazioni di handler per ogni sito. Questo però aumenta l'impegno di manutenzione. Ogni installazione richiede un proprio aggiornamento e un proprio controllo.
PHP su Windows è interessato da PHP2Shell?
Le vulnerabilità si trovano in PHP stesso. Sotto IIS PHP gira di norma come php-cgi, che il progetto PHP annovera espressamente tra le modalità di esecuzione interessate. Tratti quindi i server Windows con la stessa urgenza dei server Linux.