Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques, désignées CVE-2026-109618 et CVE-2026-109619, et regroupées sous le nom PHP2Shell. Elles peuvent permettre l’exécution de code à distance sans authentification sur des installations PHP vulnérables. Pour une PME, la question n’est donc pas seulement de savoir si WordPress est à jour : il faut identifier la version de PHP réellement utilisée par le site, confirmer l’application du correctif par l’hébergeur et vérifier que les fonctions importantes restent opérationnelles après l’intervention. Le projet PHP recommande une mise à jour immédiate des installations concernées. L’avis de sécurité officiel de PHP précise les versions corrigées et les mesures à prendre.
PHP2Shell : pourquoi votre site WordPress est concerné
Une faille dans l’environnement, pas dans un plugin WordPress
PHP est le langage exécuté côté serveur par WordPress et par de nombreux autres logiciels web. Une vulnérabilité dans le moteur PHP peut donc concerner un site même si son cœur WordPress, ses extensions et son thème sont à jour. Mettre WordPress à jour reste indispensable, mais cela ne remplace pas la correction de PHP : ce sont deux composants distincts, souvent administrés par des personnes ou des prestataires différents.
Les vulnérabilités PHP2Shell concernent le traitement de requêtes web par PHP. Selon l’avis officiel, les installations exposées incluent différentes configurations, comme PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Cela ne signifie pas que chaque site a été compromis. Cela signifie qu’il faut vérifier le runtime qui reçoit les requêtes du site et appliquer le paquet corrigé adapté à l’hébergement.
Les versions corrigées annoncées le 21 octobre
Le 21 octobre 2026, PHP a indiqué que les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent les deux vulnérabilités. Pour PHP 8.1 et les versions antérieures, le projet ne publie plus de mises à jour générales ; certains fournisseurs Linux ou éditeurs de distributions peuvent néanmoins fournir des correctifs rétroportés. Dans ce cas, demandez au prestataire de confirmer explicitement que le correctif correspondant aux deux CVE est installé. Un numéro de version inférieur ne suffit pas, à lui seul, à prouver qu’un paquet fournisseur est vulnérable ou corrigé : les distributions peuvent intégrer des correctifs sans reprendre le numéro amont attendu.
Le site PHP a également signalé des reconstructions de paquets Windows publiées le 26 octobre, avec un suffixe « -1 », pour corriger une vulnérabilité distincte dans Brotli. Ce point concerne les installations Windows utilisant ces paquets ; il ne faut pas le confondre avec les correctifs PHP2Shell du 21 octobre. Pour un hébergement administré, demandez au fournisseur quel paquet s’applique à votre infrastructure et vérifiez ses avis de sécurité.
Vérifier quelle version de PHP exécute réellement le site
Commencer par le panneau de l’hébergeur
Connectez-vous à l’espace client de l’hébergement et cherchez une rubrique comme « PHP », « Configuration PHP », « Gestionnaire MultiPHP » ou « Version du runtime ». Notez la version et, si l’interface les affiche, le mode d’exécution, la version associée au domaine et la date de dernière modification. Sur un compte hébergeant plusieurs sites ou sous-domaines, contrôlez chaque installation : un domaine peut utiliser une configuration différente d’un autre.
Dans WordPress, la page « Outils > Santé du site > Informations > Serveur » peut aider à consulter l’environnement déclaré au site. Elle constitue un indice pratique, mais ne remplace pas une confirmation de l’hébergeur sur le paquet PHP installé et les correctifs de sécurité. La version en ligne de commande, lorsqu’elle est disponible, peut également différer de celle utilisée par le serveur web. Ne vous fiez donc pas uniquement à la commande php -v exécutée dans un terminal : demandez quelle version sert effectivement les requêtes du domaine concerné.
Ne pas publier un fichier d’information PHP
Évitez de déposer un fichier public contenant phpinfo() pour vérifier la configuration. Une page de diagnostic accessible sur Internet peut exposer des détails techniques dont vous n’avez pas besoin pour cette vérification. Utilisez le tableau de bord de l’hébergeur, les informations de santé de WordPress ou une vérification effectuée par votre prestataire. Si un fichier temporaire a été créé par un technicien, demandez qu’il soit supprimé dès que le contrôle est terminé.
Organiser la mise à jour avec votre hébergeur ou votre agence
Poser des questions précises et obtenir une confirmation écrite
Si vous ne gérez pas le serveur vous-même, contactez l’hébergeur, l’agence ou le responsable informatique sans attendre. Une demande vague comme « Est-ce que mon site est sécurisé ? » risque de recevoir une réponse générale. Indiquez le nom de domaine, la date de l’alerte et les identifiants des vulnérabilités. Demandez une réponse sur le correctif réellement déployé, et pas seulement sur la disponibilité d’une mise à jour.
- Quelle version ou quel paquet PHP sert actuellement les requêtes de mon site ?
- Le correctif pour CVE-2026-109618 et CVE-2026-109619 est-il installé sur l’environnement concerné ?
- S’agit-il d’une mise à jour amont ou d’un correctif rétroporté par le fournisseur ?
- Le changement nécessite-t-il une interruption, un redémarrage de PHP-FPM ou une adaptation de configuration ?
- Quel est le plan de retour arrière si une extension ou une fonctionnalité rencontre un problème ?
- Qui vérifiera le fonctionnement du site et me transmettra le résultat ?
Le niveau de responsabilité dépend du contrat : certains hébergeurs gèrent le système et PHP, tandis que d’autres laissent cette tâche au client ou à son agence. Clarifiez qui intervient, qui teste et qui vous informe. En cas d’urgence, convenez d’un créneau d’intervention rapide plutôt que de reporter la correction à la prochaine maintenance ordinaire.
Préparer un changement sans le retarder inutilement
Avant une montée de version, demandez une sauvegarde récente des fichiers et de la base de données, ainsi qu’une confirmation qu’elle est restaurable. Si l’hébergement propose un environnement de préproduction, l’agence peut y tester le changement en premier. Toutefois, la préparation ne doit pas devenir un prétexte à laisser durablement une version vulnérable en production : si le test ou la compatibilité prend du temps, demandez au prestataire une mesure temporaire de réduction de l’exposition et un calendrier précis pour installer le correctif. Les mesures provisoires ne remplacent pas la mise à jour, comme le rappelle PHP.
La compatibilité mérite une vérification ciblée, surtout si le site utilise un thème ancien, des extensions personnalisées, des tâches planifiées ou une boutique en ligne. L’objectif n’est pas de profiter de l’alerte pour effectuer une refonte générale, mais d’identifier rapidement les dépendances qui pourraient bloquer une mise à jour nécessaire. Pour les équipes qui administrent elles-mêmes leur site, la formation WordPress d’Enovatic peut aider à mieux comprendre la gestion courante du site ; l’intervention sur le serveur doit toutefois rester confiée à une personne compétente si vous n’en avez pas la maîtrise.
Tester le site après l’application du correctif
Suivre un parcours de contrôle adapté à votre activité
Après la mise à jour, vérifiez les parcours qui génèrent des demandes ou du chiffre d’affaires. Une page d’accueil qui s’affiche ne suffit pas : le changement peut révéler une incompatibilité dans une extension, une tâche d’arrière-plan ou un formulaire. Faites les contrôles depuis un navigateur privé et, si possible, sur ordinateur et mobile.
- Ouvrez la page d’accueil, quelques pages importantes et une page de contenu représentative.
- Testez les formulaires de contact et vérifiez que les messages arrivent bien à la bonne adresse.
- Si le site vend en ligne, contrôlez le panier, la validation de commande et le parcours de paiement sans effectuer de transaction réelle non autorisée.
- Connectez-vous à l’administration WordPress et vérifiez que les opérations courantes restent possibles.
- Contrôlez les médias, les imports ou les téléversements utilisés par votre activité, ainsi que les tâches planifiées essentielles.
- Demandez à l’agence ou à l’hébergeur de surveiller les journaux d’erreurs et de confirmer le redémarrage des processus PHP concernés, le cas échéant.
Si vous constatez une erreur, notez l’heure, l’adresse de la page et les étapes permettant de la reproduire, puis transmettez ces informations au prestataire. Évitez de désactiver au hasard des extensions ou de modifier des paramètres serveur : cela peut compliquer le diagnostic et créer de nouveaux risques. Une mise à jour technique n’est terminée que lorsque le correctif est confirmé et que les fonctions essentielles ont été contrôlées.
Une mise à jour ne prouve pas qu’il n’y a pas eu d’incident
Installer la version corrigée réduit le risque lié aux vulnérabilités, mais ne démontre pas qu’aucune exploitation antérieure n’a eu lieu. Si le site utilisait une version vulnérable avant l’intervention, demandez à l’hébergeur ou à l’agence s’il est pertinent d’examiner les journaux d’accès, les comptes administrateurs, les fichiers récemment modifiés et les alertes de sécurité disponibles. Cette vérification doit être proportionnée et menée par un professionnel, surtout si le site traite des commandes ou des données personnelles. Si un signe de compromission apparaît, faites traiter le cas comme un incident de sécurité plutôt que comme un simple problème d’affichage.
Encadré pratique : votre checklist PHP2Shell
À faire maintenant : 1) relever le domaine et la version PHP affichée par l’hébergement ; 2) demander si le correctif des CVE-2026-109618 et CVE-2026-109619 est installé ; 3) obtenir la confirmation du paquet corrigé ou du correctif rétroporté ; 4) prévoir une sauvegarde et un plan de retour arrière ; 5) tester les parcours essentiels après intervention ; 6) demander un contrôle des signes d’incident si le site était exposé avant le correctif.
Consignez la date de la vérification, la personne responsable et la réponse du prestataire. Cette trace facilite le suivi entre l’entreprise, l’agence et l’hébergeur, et évite de refaire les mêmes vérifications sans savoir ce qui a été appliqué. Pour vos prochains contrôles, vous pouvez également consulter les services web d’Enovatic ou nous présenter votre situation via la page de contact.
Questions fréquentes
Mon WordPress est à jour : suis-je protégé contre PHP2Shell ?
Pas nécessairement. La mise à jour de WordPress ne met pas automatiquement à jour le moteur PHP de l’hébergement. Vérifiez séparément la version ou le paquet PHP utilisé pour votre domaine et demandez confirmation du correctif correspondant aux deux CVE.
Mon hébergeur indique une version PHP plus ancienne que celles annoncées : est-ce forcément vulnérable ?
Non. Certains fournisseurs peuvent rétroporter un correctif dans un paquet sans adopter le numéro de version amont publié par PHP. Demandez une confirmation explicite du fournisseur ou de l’hébergeur concernant CVE-2026-109618 et CVE-2026-109619. Ne concluez pas à la sécurité sur la seule base d’un numéro affiché.
Qui doit effectuer la mise à jour : l’agence ou l’hébergeur ?
Cela dépend de l’offre d’hébergement et du contrat de maintenance. L’hébergeur peut gérer l’environnement serveur, tandis que l’agence s’occupe de WordPress et des tests applicatifs. Demandez qui déploie le correctif, qui vérifie la version réellement active et qui teste le site.
Dois-je changer de version majeure de PHP pour appliquer le correctif ?
Pas automatiquement. Les versions correctives publiées le 21 octobre concernent plusieurs branches PHP prises en charge. Le prestataire doit déterminer la branche compatible avec le site et appliquer une version corrigée ou un correctif fournisseur approprié. Une migration majeure peut nécessiter des tests de compatibilité supplémentaires.
Conclusion : transformer l’alerte en vérification concrète
PHP2Shell rappelle que la sécurité d’un site repose sur plusieurs couches : WordPress, ses extensions, le code du site et l’environnement d’hébergement. Pour agir efficacement, identifiez la version PHP réellement utilisée, demandez à la personne responsable une confirmation du correctif PHP2Shell et testez les fonctions essentielles après l’intervention. Ne confondez pas mise à jour du CMS et mise à jour du serveur, et ne considérez pas les mesures temporaires comme un remplacement du correctif.
Vous ne savez pas qui gère PHP pour votre site, ou vous souhaitez organiser un contrôle avec votre agence ? Contactez Enovatic pour faire le point sur votre site et définir les vérifications adaptées à votre situation.
Sources
- www.php.net — https://www.php.net/
- enovatic.be — https://enovatic.be/services/
- enovatic.be — https://enovatic.be/blog/formation/formation-wordpress/
- enovatic.be — https://enovatic.be/contact/
Besoin d’un accompagnement sur mesure ?
Nos experts en design, développement web et référencement accompagnent les entreprises belges au quotidien. Découvrez nos services de création de site web, nos formations professionnelles et nos réalisations.
Contactez-nous pour un devis gratuit.
Photo d'illustration : Jefferson Santos sur Unsplash.
