Vérifier la version PHP de son site et les correctifs de l’hébergeur
Une version PHP affichée dans le panneau d’hébergement peut ne pas suffire pour conclure. Voici comment relever le bon moteur, vérifier les correctifs et obtenir une réponse précise de l’hébergeur. Guide vérifié le 22 octobre 2026.
Commencer par le domaine qui sert réellement le site
Notez l’adresse exacte à contrôler : domaine principal, sous-domaine ou copie de test. Ouvrez ensuite la configuration PHP associée à ce domaine dans votre panneau d’hébergement. Un compte peut héberger plusieurs sites avec des réglages différents. La valeur par défaut du compte n’est donc pas nécessairement celle de votre boutique.
Chez un hébergeur utilisant un sélecteur PHP, relevez ce qui est effectivement sélectionné pour le site et demandez le numéro complet si seul « 8.3 » ou « 8.4 » est visible. Conservez la date du relevé. Si une règle du serveur ou du domaine impose un autre moteur, faites vérifier sa priorité par le support. Évitez de changer la version globale d’un compte qui héberge plusieurs applications avant d’avoir établi cette correspondance.
Sur WordPress et WooCommerce : utiliser Santé du site
Dans WordPress, ouvrez Outils > Santé du site > Informations > Serveur pour relever le numéro complet de PHP. Ce relevé décrit le moteur du site ; le statut général de Santé du site ne remplace pas la confirmation des correctifs PHP2Shell par votre hébergeur. Consultez le guide PHP2Shell WordPress et WooCommerce pour les contrôles du site et du tunnel de commande.
PHP web et PHP du terminal peuvent être différents
La commande php -v décrit le binaire exécuté dans votre terminal. Elle est utile, mais elle ne prouve pas que les pages web utilisent ce même binaire. Les tâches planifiées peuvent elles aussi appeler un autre chemin. Un serveur peut ainsi présenter une version corrigée en ligne de commande et utiliser encore un paquet différent pour les requêtes du site.
La vérification décisive porte sur le moteur web : une information fournie par l’administration de l’application, un diagnostic authentifié existant ou un contrôle réalisé par l’hébergeur. Demandez aussi le mode d’exécution, par exemple PHP-FPM ou LiteSpeed. Si un diagnostic doit être ajouté, limitez-le aux informations nécessaires et protégez son accès. Une page publique phpinfo() expose beaucoup plus de détails qu’un simple numéro de version et ne doit pas devenir un outil permanent accessible à tous.
Interpréter une ancienne version et un correctif rétroporté
Un rétroportage consiste à appliquer une correction à un paquet existant sans migrer toute sa branche. Certains fournisseurs maintiennent ainsi leurs propres paquets. Le numéro générique du moteur ne suffit alors pas pour établir l’état de sécurité : il faut la référence exacte du paquet et le bulletin du fournisseur.
Ne déduisez pas qu’un site est sain parce que l’hébergeur propose encore une ancienne branche dans son menu. Ne déduisez pas non plus qu’il est forcément vulnérable si un bulletin confirme la correction des deux failles dans le paquet installé. La preuve recherchée relie trois éléments : votre serveur, le paquet qui exécute les requêtes web et la correction documentée. Un bulletin qui annonce la disponibilité d’un paquet ne prouve pas encore qu’il a été installé sur votre hébergement.
Le message précis à envoyer au support
Vous pouvez transmettre cette demande en remplaçant le domaine concerné :
Pouvez-vous confirmer la version complète et la référence du paquet PHP qui traite les requêtes web de mon domaine, ainsi que son mode d’exécution ? Ce paquet corrige-t-il CVE-2026-109618 et CVE-2026-109619, dites PHP2Shell ? Si la correction est rétroportée, merci de communiquer le bulletin correspondant et de confirmer que les processus web utilisent bien le paquet corrigé.
Gardez la réponse avec la date et les contrôles réalisés. Si le support confirme seulement que « PHP est à jour », demandez la précision sur ces deux identifiants. Cette traçabilité sera utile lors de la prochaine maintenance et évitera de refaire toute la recherche à partir d’un numéro partiel.
Après l’installation du correctif
-
Refaire le relevé sur le web
Contrôlez le moteur qui répond réellement sur le domaine après l’intervention. Si le fournisseur a rétroporté le correctif, conservez sa confirmation plutôt que de vous fier au numéro générique seul.
-
Tester les parcours qui génèrent du chiffre d’affaires
Vérifiez le panier, la connexion client, la livraison et le paiement avec le mode test adapté. Contrôlez aussi les imports, exports et synchronisations indispensables.
-
Vérifier les autres environnements exposés
Contrôlez séparément les préproductions et sous-domaines encore accessibles. Retirez ou restreignez les anciennes copies qui n’ont plus de raison d’être publiques.
-
Planifier la suite
Si un module bloque une branche PHP maintenue, faites auditer sa compatibilité et préparez son remplacement sur une copie de test. Une correction d’urgence ne dispense pas de maintenance régulière.
Comprendre l’alerte et préparer une migration
Le dossier PHP2Shell et versions PHP corrigées rassemble les informations de sécurité et les sources. Si votre boutique ne peut pas suivre les évolutions de PHP, consultez notre démarche de refonte PrestaShop après PHP2Shell. Vous pouvez aussi demander un accompagnement en hébergement infogéré ou en maintenance.
Sources vérifiées le 22 octobre 2026 : avis officiels PHP, calendrier des branches PHP maintenues et suivi des correctifs CloudLinux. La disponibilité annoncée par un éditeur doit toujours être distinguée de l’installation effective par votre hébergeur.
Questions fréquentes
La commande php -v suffit-elle à vérifier mon site ?
Dois-je publier une page phpinfo pour vérifier PHP ?
Un correctif rétroporté peut-il protéger une ancienne version ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.