Une faille PHP est un bug dans le langage qui fait tourner la majorité des sites web, dont ceux construits avec WordPress, Drupal ou Joomla. Les plus graves permettent à un pirate de prendre le contrôle d’un serveur à distance. En octobre 2026, deux failles critiques baptisées PHP2Shell ont poussé des administrations entières à couper leurs sites par précaution. La protection tient en une règle simple : faire tourner une version de PHP encore maintenue et appliquer chaque correctif dès sa sortie.
PHP, un langage présent partout
PHP génère les pages d’environ 70 % des sites dont la technologie serveur est connue. Blogs, boutiques en ligne, sites d’associations ou portails administratifs : la plupart des sites WordPress, le CMS le plus utilisé au monde, reposent sur lui.
Cette omniprésence fait de chaque faille un enjeu massif. Un bug dans PHP ne touche pas un site isolé, mais des millions de serveurs à la fois. Les pirates le savent : dès qu’une faille est publiée, des robots scannent internet à la recherche des serveurs qui n’ont pas encore installé le correctif.
PHP2Shell : la faille qui a coupé des sites publics
Le cas d’octobre 2026 illustre bien le danger. Deux failles, référencées CVE-2026-109618 et CVE-2026-109619 et notées 9,2 sur 10, permettaient d’exécuter des commandes sur un serveur sans aucun mot de passe. Des détails ont fuité en ligne le 20 octobre, avant la publication officielle. PHP a sorti ses correctifs en urgence le 21 octobre, pour les versions 8.2 à 8.5.
En France, le ministère de l’Intérieur a placé ses sites exposés en maintenance préventive à la demande de l’ANSSI. Les sites des préfectures, impots.gouv.fr et Météo-France sont restés inaccessibles pendant des heures. Le soir même, le compte ameli et le site de la CAF passaient à leur tour en maintenance. Ces coupures ne venaient pas d’une attaque, mais d’une mise hors ligne volontaire le temps d’installer les correctifs.
Pour les internautes, le résultat ressemblait pourtant à une panne géante. Les signalements ont afflué sur les plateformes de suivi, comme bugalert.fr, où les fiches des services publics concernés ont enregistré des pics de témoignages de connexion impossible.
Les principaux types de failles PHP
Toutes les failles ne se valent pas. L’exécution de code à distance arrive en tête des dangers : le pirate envoie une requête piégée et fait tourner ses propres programmes sur le serveur. Il vole alors des données, installe un logiciel malveillant ou se sert de la machine pour d’autres attaques.
Les injections SQL, souvent liées au code d’un site plutôt qu’à PHP lui-même, permettent de lire ou de modifier la base de données. Avec une faille d’inclusion de fichiers, le serveur charge un fichier choisi par le pirate.
D’autres bugs provoquent un déni de service : le serveur sature et le site devient inaccessible, sans vol de données. Les failles de fuite de mémoire exposent enfin des informations sensibles, comme des mots de passe stockés temporairement.
Votre version de PHP est-elle encore maintenue ?
Une faille découverte dans une version en fin de vie ne sera jamais corrigée. Au 7 novembre 2026, seules quatre branches reçoivent encore des correctifs de sécurité, selon la page officielle des versions supportées : PHP 8.2, 8.3, 8.4 et 8.5.
PHP 8.0 et 8.1 sont en fin de vie. Un site qui tourne encore dessus reste exposé à toutes les failles futures, PHP2Shell compris. La branche 8.2 arrive aussi à échéance : son support de sécurité s’arrête le 31 décembre 2026. Une migration vers PHP 8.4 ou 8.5 offre plusieurs années de tranquillité.
La version utilisée apparaît dans le tableau de bord de l’hébergeur. Sur WordPress, l’outil « Santé du site », dans le menu Outils, l’affiche aussi et signale une version trop ancienne.
Comment protéger votre site
La mise à jour reste la première protection. Les hébergeurs mutualisés appliquent souvent les correctifs eux-mêmes, mais pas toujours le jour même : un message au support permet de le vérifier. Sur un serveur privé ou un VPS, l’installation revient à l’administrateur, suivie d’un redémarrage des services web.
Le changement de version majeure demande plus de précautions. Une copie de sauvegarde du site, puis un test sur un environnement de préproduction, évitent les mauvaises surprises : certaines extensions WordPress anciennes ne fonctionnent plus avec les versions récentes de PHP.
Un pare-feu applicatif ajoute une couche de défense. Pendant l’épisode PHP2Shell, Cloudflare a déployé des règles de protection pour tous ses clients environ neuf heures avant la divulgation publique, ce qui a protégé une grande partie du web le temps des mises à jour.
Les extensions, thèmes et CMS doivent aussi rester à jour. Une faille dans un module WordPress mal entretenu ouvre une porte aussi large qu’une faille dans PHP.
Ce que voient les internautes pendant une faille
Pour un visiteur, une faille PHP se manifeste rarement de façon directe. Il constate surtout ses conséquences : site en maintenance, page blanche, erreur 500 ou 503, connexion impossible à un espace client. Lors de l’épisode d’octobre 2026, beaucoup ont cru à une panne générale d’internet alors qu’il s’agissait de coupures préventives.
Le bon réflexe consiste à vérifier si le problème touche d’autres personnes avant de modifier ses mots de passe ou de réinstaller une application. Une maintenance de sécurité se termine en général en quelques heures. Les messages qui profitent de ces épisodes pour réclamer vos identifiants relèvent en revanche de l’hameçonnage : aucun service ne vous demande vos codes par mail pour « sécuriser » votre compte après une faille.
FAQ
Un site WordPress est-il concerné par les failles PHP ?
Oui. WordPress fonctionne avec PHP : une faille dans le langage touche tous les sites qui tournent sur une version non corrigée, quel que soit le thème ou les extensions installés.
Comment savoir si mon hébergeur a appliqué le correctif ?
Le tableau de bord indique la version exacte de PHP. Pour PHP2Shell, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 intègrent le correctif. Un numéro inférieur signale un serveur encore exposé.