En bref : sous Windows avec IIS, PHP tourne le plus souvent comme php-cgi.exe via FastCGI, un mode d'exécution expressément concerné par PHP2Shell. Une mise à jour PHP IIS comprend trois étapes : trouver toutes les installations de PHP, les remplacer par une version corrigée et recycler les pools d'applications. Un gestionnaire de paquets et des backports comme sous Linux n'existent généralement pas ici.
Comment PHP tourne sous IIS
Sur les serveurs Windows, IIS intègre PHP via le module FastCGI. Pour chaque version de PHP, il existe une entrée FastCGI qui pointe vers un php-cgi.exe et une association de handler qui y dirige les fichiers avec l'extension .php. IIS démarre au besoin plusieurs processus php-cgi et les garde actifs pour les requêtes suivantes.
Contrairement à Linux, PHP ne provient ici le plus souvent pas d'un gestionnaire de paquets, mais d'une archive ZIP des builds Windows du projet PHP, d'une application métier ou d'anciens installateurs. Cela signifie : les mises à jour ne se font pas automatiquement et il n'existe pas de backports d'un distributeur. Le numéro de version des fichiers installés fait foi.
Ce que PHP2Shell signifie pour les serveurs Windows
PHP2Shell regroupe CVE-2026-109618 et CVE-2026-109619 dans PHP lui-même, chacune CVSS v4.0 9.2. Toutes deux permettent l'exécution de code sans authentification. Le projet PHP cite expressément php-cgi parmi les modes d'exécution concernés. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles. Les serveurs Windows avec des applications métier tournent, d'après l'expérience, souvent sur de tels états, parce que l'application exige une version précise. Il faut ici, en plus des mesures transitoires, une clarification avec l'éditeur de l'application. Le contexte de ce mode d'exécution figure sous php-cgi : un héritage risqué.
Mise à jour PHP IIS : trouver les installations
Les commandes PowerShell suivantes se contentent de lire. Elles montrent quelles installations de PHP IIS utilise et quelle version elles ont. Les chemins sont des exemples.
# Entrées FastCGI dans IIS : quel php-cgi.exe est utilisé ?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi
# Version de chaque installation trouvée (chemin à titre d'exemple)
& "C:\PHP\8.3\php.exe" -v
# Processus php-cgi en cours avec heure de démarrage
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Recherchez en outre sur tous les lecteurs d'autres php-cgi.exe, car les applications métier apportent parfois leurs propres copies. Notez pour chaque installation la version, la variante (Thread Safe ou Non Thread Safe) et l'architecture.
Installer la mise à jour et recycler les pools d'applications
Téléchargez la version corrigée depuis les builds Windows officiels du projet PHP, liés depuis php.net, dans la même variante et la même architecture. Il a fait ses preuves de décompresser la nouvelle version dans un nouveau dossier, de reprendre le php.ini existant et les extensions nécessaires, puis de faire pointer l'entrée FastCGI vers le nouveau chemin. L'ancien état reste ainsi disponible pour un retour en arrière.
# Recycler un pool d'applications (nom à titre d'exemple)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"
# Ou bien redémarrer tous les services IIS
iisreset
# Contrôle : tous les processus php-cgi démarrés après la mise à jour ?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path
Chaque processus php-cgi doit avoir une heure de démarrage postérieure à la mise à jour et pointer vers le nouveau chemin. Testez ensuite les sites. Supprimez l'ancien dossier PHP dès que le nouvel état fonctionne de façon stable, afin qu'il ne soit pas réintégré par mégarde.
De nouveaux fichiers dans le dossier PHP ne suffisent pas tant que d'anciens processus php-cgi tournent. Ce n'est qu'après le recyclage des pools ou un redémarrage d'IIS que le correctif est effectif.
Mesures transitoires dans le php.ini
Si une installation ne peut pas être mise à jour immédiatement, php.net recommande des mesures transitoires sans protection complète. Sous IIS, définissez les valeurs dans le php.ini central de l'installation concernée. Les fichiers .user.ini et ini_set() ne suffisent pas, selon php.net.
; php.ini de l'installation concernée
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Avec une fonction d'envoi de fichiers, php.net indique post_max_size = 32M. Sur PHP 8.5, fatal_error_backtraces=0 s'y ajoute. Pour que les sites ne modifient pas les valeurs via leurs propres fichiers .user.ini, on peut laisser user_ini.filename vide dans le php.ini central ; vérifiez auparavant si des applications en dépendent. Recyclez ensuite les pools. Le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement les serveurs web du réseau lorsque la mise à jour n'est pas possible immédiatement. D'autres paramètres sont expliqués dans Configurer php.ini de façon sécurisée.
Après la mise à jour
Un correctif ne supprime pas les logiciels malveillants introduits auparavant. Conservez les journaux IIS à partir du 20 octobre 2026, recherchez dans les répertoires web de nouveaux fichiers de script et vérifiez les tâches planifiées et les comptes utilisateurs locaux à la recherche d'éléments inconnus. Si le serveur fonctionne dans un domaine, un coup d'œil aux connexions en fait également partie.
Soyez en outre attentif aux droits des identités des pools d'applications. Si un pool tourne avec un compte disposant de droits d'écriture sur tout le répertoire web, voire de droits administratifs, un attaquant peut faire nettement plus de dégâts après une intrusion réussie. Il est judicieux d'utiliser une identité propre et restreinte par pool, avec des droits d'écriture uniquement là où l'application en a réellement besoin, par exemple dans le dossier d'envoi ou de cache. Dans ces dossiers, IIS ne devrait exécuter aucun fichier PHP ; cela se règle via les associations de handlers du dossier concerné. Vérifiez aussi si d'anciens fichiers de test et d'installation, comme des sorties phpinfo, se trouvent dans le répertoire web, et supprimez-les.
Comment PHP SOS aide-t-il concrètement ?
- Nous trouvons toutes les installations de PHP sur vos serveurs Windows, y compris les copies dans les applications métier.
- Via le service de correctifs PHP, nous remplaçons PHP, recyclons les pools et documentons la version et les heures de processus.
- Pour les anciennes versions, nous clarifions avec vous et l'éditeur de l'application la voie vers la migration vers une version de PHP prise en charge.
- Nous examinons les serveurs à la recherche de traces d'une attaque et sauvegardons les journaux.
Questions fréquentes
De quelle variante de PHP ai-je besoin pour IIS ?
Pour IIS avec FastCGI, on utilise généralement la variante Non-Thread-Safe (NTS). Lors de la mise à jour, veillez à choisir à nouveau la même variante et la même architecture, afin que les extensions restent compatibles.
Suffit-il de décompresser le nouveau dossier PHP ?
Non. IIS garde actifs les processus php-cgi.exe pendant un certain temps. Recyclez les pools d'applications ou redémarrez IIS et vérifiez qu'aucun ancien processus ne tourne plus.
Puis-je exploiter plusieurs versions de PHP sur un même IIS ?
Oui, via plusieurs entrées FastCGI et des associations de handlers par site. Cela augmente toutefois la charge de maintenance. Chaque installation nécessite sa propre mise à jour et son propre contrôle.
PHP sous Windows est-il concerné par PHP2Shell ?
Les failles se trouvent dans PHP lui-même. Sous IIS, PHP tourne en règle générale comme php-cgi, que le projet PHP compte expressément parmi les modes d'exécution concernés. Traitez donc les serveurs Windows avec la même urgence que les serveurs Linux.