Mettre à jour PHP sous Windows

En bref : sous Windows, vous mettez PHP à jour à la main : télécharger la version corrigée sur php.net, choisir la même variante (Thread Safe ou Non Thread Safe) et la même architecture, vérifier le téléchargement par SHA-256, reprendre php.ini et les extensions, changer le chemin et redémarrer tous les processus PHP. La mise à jour est particulièrement urgente si Apache sous Windows charge PHP comme module, car l'équipe PHP classe ce mode d'exécution au plus haut niveau pour PHP2Shell.

Où PHP se cache partout sur les machines Windows

Les serveurs Windows avec PHP sont plus fréquents que beaucoup ne le pensent. Rarement il s'agit du grand site web, souvent d'intranets, d'applications métier ou d'outils que quelqu'un a mis en place il y a des années. L'exploitation sous IIS est décrite en détail sur la page Sécuriser PHP sous Windows et IIS. Cet article traite de la mise à jour elle-même et des cas en dehors d'IIS.

Les lieux typiques sont Apache pour Windows avec PHP comme module, les paquets pour développeurs comme XAMPP, WampServer ou Laragon qui ont atterri sur un serveur, des copies propres de PHP dans des applications métier et des scripts PHP dans des tâches planifiées. Les commandes PowerShell suivantes ne font que lire et aident à trouver :

# Trouver tous les php.exe sur le lecteur C: (un peu long sur les grands lecteurs)
Get-ChildItem -Path C:\ -Filter php.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime

# Quel php.exe se trouve dans le chemin de recherche ?
where.exe php

# Processus PHP et Apache en cours avec chemin et heure de démarrage
Get-Process php*, httpd -ErrorAction SilentlyContinue | Select-Object Name, Id, StartTime, Path

# Version et configuration chargée d'une installation (chemin à titre d'exemple)
& "C:\PHP\8.4\php.exe" -v
& "C:\PHP\8.4\php.exe" --ini

Important : si PHP tourne comme module Apache, il n'y a pas de processus PHP propre. PHP se trouve alors dans le processus httpd.exe. Qui ne cherche que des processus php-cgi passe à côté de ces installations.

On oublie aussi facilement les tâches planifiées qui appellent des scripts PHP, par exemple pour des imports, des rapports ou des rapprochements de données. Elles utilisent souvent un php.exe propre, plus ancien. Pour PHP2Shell, elles sont considérées comme moins exposées, car la ligne de commande ne fait pas partie, selon les indications actuelles de php.net, des modes d'exécution concernés ; lors du remplacement, elles doivent néanmoins pointer vers le nouveau chemin, sinon l'ancienne installation reste en usage et n'est jamais supprimée.

# Tâches planifiées qui appellent PHP
Get-ScheduledTask | Where-Object { $_.Actions.Execute -match 'php' } |
  Select-Object TaskName, TaskPath, @{n='Programm';e={$_.Actions.Execute}}

Les postes de développeurs sont un sujet à part. XAMPP et les paquets similaires démarrent Apache avec PHP comme module et sont souvent accessibles dans tout le réseau de l'entreprise. Là aussi, PHP doit être mis à jour, et le serveur web ne devrait écouter que sur la machine locale.

Thread Safe ou Non Thread Safe : la bonne variante

php.net propose chaque version Windows en plusieurs variantes. Pour le remplacement, la même variante et la même architecture qu'auparavant s'appliquent, sinon le serveur web ou les extensions ne se chargent pas.

Pour PHP 8.5, php.net listait lors de la consultation du 25/10/2026 la version 8.5.12 du 21/10/2026, sous forme d'archive ZIP dans les quatre combinaisons. Les autres branches prises en charge, vous les sélectionnez sur la même page. Sont corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour 8.1 et antérieur, il n'existe plus de mises à jour officielles.

Mise à jour de PHP sous Windows : vérifier le téléchargement et remplacer proprement

1. Télécharger la version corrigée : depuis la page de téléchargement Windows sur php.net, selon la variante et l'architecture.
2. Comparer la somme de contrôle : php.net indique pour chaque archive une valeur SHA-256. Si elle diffère, n'utilisez pas le fichier.
3. Décompresser dans un nouveau dossier : par exemple C:\PHP\8.4.27, afin que l'ancien état soit conservé comme voie de retour.
4. Reprendre la configuration : copier l'ancien php.ini et le comparer avec le nouveau php.ini-production.
5. Vérifier les extensions : les fichiers DLL supplémentaires de fournisseurs tiers doivent correspondre à la version, à la variante et à l'architecture.
6. Changer le chemin : dans l'entrée FastCGI, dans la ligne LoadModule d'Apache ou dans la variable d'environnement PATH.
7. Redémarrer et vérifier : redémarrer le service du serveur web et les tâches planifiées, puis contrôler la version et les heures de démarrage.

# Calculer le SHA-256 du fichier téléchargé et le comparer avec php.net
Get-FileHash .\php-8.5.12-nts-Win32-vs17-x64.zip -Algorithm SHA256

# Après le changement : extensions chargées et version de la nouvelle installation
& "C:\PHP\8.5.12\php.exe" -m
& "C:\PHP\8.5.12\php.exe" -v

Si PHP ne démarre pas après le changement ou signale une DLL manquante, il manque souvent la Visual C++ Redistributable dans la bonne architecture, ou une extension ne correspond pas à la nouvelle version. L'erreur se montre le plus vite si vous appelez php.exe -v directement en ligne de commande avant de basculer le serveur web. Ce que font les différentes entrées de php.ini, Le php.ini expliqué l'explique.

Apache sous Windows : prendre le mode module au sérieux

De nombreuses installations Windows plus anciennes intègrent PHP directement dans Apache par une ligne LoadModule. C'est techniquement la même chose que mod_php sous Linux. L'équipe PHP classe précisément là le risque de PHP2Shell au plus haut niveau, parce qu'un exploit y a été démontré avant même que le code de l'application ne s'exécute. Le contexte figure sous Pourquoi mod_php est particulièrement exposé.

Quels modules un Apache charge, httpd.exe -M le montre dans le dossier bin de l'installation ; la commande ne fait que lire. Si un module PHP y figure, la mise à jour est prioritaire. À moyen terme, le passage à PHP via FastCGI avec un build NTS vaut la peine, pour que PHP tourne dans des processus propres. Cela exige un test, car la configuration et les droits changent.

Après la mise à jour : contrôle et traces

Consignez pour chaque installation le chemin, la version, la variante et la date du changement. Ne supprimez les anciens dossiers PHP que lorsque le nouvel état tourne de façon stable, puis supprimez-les réellement, afin qu'ils ne soient pas réintégrés par inadvertance.

Une mise à jour ne supprime aucun logiciel malveillant. Si un serveur Windows était accessible depuis Internet les jours précédant le correctif, vérifiez dans les répertoires web les nouveaux fichiers de script, dans les tâches planifiées et les comptes locaux tout ce qui est inconnu, et sauvegardez les journaux du serveur web à partir du 20 octobre. Comment reconnaître une intrusion, Suis-je déjà compromis ? le décrit.

Comment PHP SOS aide-t-il concrètement ?

• Trouver toutes les installations : nous recherchons PHP sur vos systèmes Windows, y compris dans les modules Apache, les paquets pour développeurs et les applications métier.
• Remplacer et prouver : via le service de correctifs PHP, nous passons à la version corrigée, vérifions les sommes de contrôle et documentons la version et le démarrage des processus.
• Améliorer le mode d'exécution : là où PHP tourne comme module Apache, nous planifions et testons le passage à FastCGI.
• Vérifier les traces : nous sauvegardons les journaux et examinons les systèmes à la recherche d'indices d'une attaque.

Questions fréquentes

Sources

• php.net : télécharger PHP pour Windows
• PHP : versions prises en charge
• Apache HTTP Server : documentation