Le 21 octobre 2026, la fondation PHP a publié deux correctifs de sécurité en urgence. Les failles qu’ils referment ont reçu un surnom, PHP2Shell, et une caractéristique qui explique l’affolement du secteur : elles permettent de prendre la main sur un serveur à distance, sans aucun mot de passe.
PHP fait tourner la grande majorité des sites web de la planète, WordPress en tête. D’où les titres de presse sur « 70 % des sites menacés ». Le chiffre est spectaculaire, mais il ne dit rien de votre situation à vous.
Vous trouverez plus bas un encadré où coller l’adresse de votre site : nous lisons sa page d’accueil comme le ferait un navigateur, et nous vous disons ce que son serveur révèle. C’est gratuit, immédiat, et cela ne teste aucune faille.
Cet article répond à la seule question qui compte quand on dirige une entreprise et qu’on n’est pas informaticien : mon site est-il concerné, et si oui, qu’est-ce que je fais, dans quel ordre.
1. Ce qui s’est passé, en clair
Deux failles, des correctifs sortis en urgence, et une alerte officielle de l’ANSSI le jour même.
L’éditeur de PHP avait prévu de publier ses correctifs le 22 octobre. Des informations ayant fuité en ligne le 20, le calendrier a été avancé : les versions corrigées sont sorties le 21 octobre 2026. Le même jour, le CERT-FR, le centre d’alerte rattaché à l’ANSSI, a publié l’alerte CERTFR-2026-ALE-014, intitulée « Multiples vulnérabilités dans PHP ».
Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619, et sont notées 9,2 sur 10 sur l’échelle de gravité. L’éditeur les décrit comme permettant « l’exécution de code arbitraire à distance » : autrement dit, faire exécuter au serveur des instructions choisies par un attaquant, sans avoir à s’identifier.
Ce qui rend l’affaire sérieuse, au-delà de la note de gravité : des tentatives d’exploitation ont été observées avant même la publication des correctifs. Le délai habituel entre la découverte d’une faille et son exploitation de masse s’est réduit à presque rien.
Pourquoi « 70 % des sites »
PHP n’est pas un logiciel que l’on installe soi-même. C’est le moteur qui exécute le code de la plupart des sites dynamiques : WordPress, PrestaShop, Drupal, Joomla, et une grande part des sites développés sur mesure. Quand le moteur a une faille, tout ce qui roule avec en hérite. Le pourcentage cité par la presse reflète la part de PHP sur le web, pas un décompte de sites piratés.
2. Votre site est-il concerné ? La vérification en deux minutes
La question n’est pas de savoir si votre site est récent, mais s’il s’exécute avec PHP, et dans quelle version.
Votre site s’exécute-t-il avec PHP ?
Collez l’adresse de votre site. Nous lisons sa page d’accueil comme le ferait un navigateur, et nous vous disons ce que le serveur révèle. Aucun test d’intrusion.
| Votre site | Concerné ? | Ce que cela implique |
|---|---|---|
| WordPress, PrestaShop, Drupal, Joomla | Oui, par construction | Le serveur doit tourner sur une version de PHP corrigée. À faire confirmer par écrit. |
| Site sur mesure en PHP, souvent chez un hébergeur mutualisé | Oui | Même vérification, même urgence. |
| Site statique ou site livré sans moteur PHP | Non | Aucun interpréteur PHP n’exécute vos pages : cette faille n’a rien à attaquer. |
| Créateur de site en ligne (Wix, Squarespace, Shopify) | Non, cela leur incombe | La mise à jour relève de la plateforme. Vous pouvez néanmoins demander confirmation. |
Le test que vous pouvez faire vous-même
- 1.Ouvrez votre site dans un navigateur, faites un clic droit puis « Inspecter », et allez dans l’onglet « Réseau ».
- 2.Rechargez la page, puis cliquez sur la première ligne de la liste, celle qui correspond à votre page.
- 3.Lisez les en-têtes de réponse. Si vous y voyez une ligne x-powered-by: PHP/…, votre site s’exécute bien avec PHP, et le numéro affiché est la branche à faire vérifier.
- 4.Si cette ligne est absente, cela ne prouve pas l’absence de PHP : beaucoup d’hébergeurs la masquent volontairement. D’autres indices suffisent : des adresses de pages terminant par .php, ou une page de connexion du type /wp-admin.
3. Vous êtes concerné : quoi faire, dans cet ordre
Cinq étapes, de la plus urgente à la plus tardive. L’ordre compte.
- 1.Obtenir le numéro de version exact de PHP, et pas seulement la branche : 8.3.36, pas « 8.3 ». Les premières versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. En dessous de ces numéros, dans la même branche, le site est vulnérable.
- 2.Faire appliquer la mise à jour. Chez la plupart des hébergeurs mutualisés, l’opération se fait au niveau du serveur, par l’hébergeur, et elle a souvent déjà été faite dans les heures qui ont suivi l’alerte. Faites-le confirmer, avec une date et une heure.
- 3.Si votre site tourne encore en PHP 7.x, 8.0 ou 8.1 : il n’existe pas de correctif officiel, ces versions ne sont plus suivies par l’éditeur. La seule issue est la migration vers une version maintenue. C’est un chantier à planifier immédiatement, pas au prochain trimestre.
- 4.En attendant la mise à jour, le CERT-FR publie deux contournements : désactiver la fonction session.upload_progress dans la configuration, et bloquer ou surveiller les requêtes dont l’en-tête Content-Type vaut « multipart », au niveau d’un pare-feu applicatif. Le CERT-FR précise qu’il ne les qualifie pas et qu’ils ne réduisent la surface d’attaque que pour l’une des deux failles.
- 5.Vérifier qu’il ne s’est rien passé. Dates de modification des fichiers, comptes administrateurs que personne ne reconnaît, fichiers déposés récemment, et journaux d’accès des 20, 21 et 22 octobre. Une mise à jour ne referme pas une porte déjà ouverte avant elle.
4. La question exacte à poser à votre prestataire
Copiez ce message, envoyez-le, et jugez la réponse.
✉️ Message prêt à envoyer
Au sujet des deux failles PHP du 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619, alerte CERTFR-2026-ALE-014), pouvez-vous me confirmer par écrit :
1. le numéro de version exact de PHP qui exécute mon site aujourd’hui ;
2. la date et l’heure auxquelles le correctif a été appliqué ;
3. si vous avez vérifié l’absence de compromission entre le 20 et le 22 octobre 2026.
Merci de votre retour.
Une réponse précise en quelques heures est un bon signe : cela veut dire que la personne savait déjà, et qu’elle a agi. Un silence de plusieurs jours, ou un « ne vous inquiétez pas, tout est à jour » sans numéro de version ni date, n’est pas une réponse.
5. Pourquoi les sites que nous gérons ne sont pas concernés
Ce n’est pas de la chance, c’est une conséquence directe du choix d’architecture. Et c’est vérifiable par n’importe qui, y compris par vous.
Les sites que nous créons et hébergeons ne s’exécutent pas avec PHP. Leurs pages sont livrées déjà construites, depuis un réseau de diffusion mondial, et le peu de traitement serveur dont elles ont besoin (envoi d’un formulaire, paiement en ligne) tourne en JavaScript et TypeScript, dans un environnement d’exécution distinct. Il n’y a pas d’interpréteur PHP dans la chaîne, donc rien à mettre à jour en urgence.
Nous avons quand même fait la vérification, le 22 octobre, plutôt que de nous en remettre à ce que nous croyions savoir : relevé des en-têtes de réponse de chacun des domaines que nous hébergeons, inventaire des projets en ligne, et recherche de tout fichier PHP dans nos dossiers de code. Résultat : aucun moteur PHP, aucun cookie de session PHP, aucun fichier PHP. Un seul site est apparu comme exposé au cours de cette revue, et il n’est pas hébergé par nous : nous avons prévenu l’entreprise concernée.
Ce que nous ne prétendons pas
Ne pas être concerné par cette faille ne veut pas dire être à l’abri de tout, et nous ne l’écrirons pas. Aucun prestataire sérieux ne peut promettre un site sans aucune vulnérabilité : un site a d’autres surfaces exposées, ses formulaires, ses accès d’administration, ses clés d’interface, ses dépendances. Nous auditons les nôtres régulièrement, et nous y trouvons des choses à corriger, comme tout le monde.
Ce que nous affirmons est plus étroit, et donc plus solide : cette famille de failles, qui vient du moteur PHP, ne peut pas atteindre un site qui n’exécute pas de PHP. C’est le principe de la réduction de surface d’attaque, qui vaut mieux que de courir derrière les correctifs. Un site sans moteur dynamique exposé, sans base de données en frontal et sans interface d’administration publique offre très peu de prise à une attaque automatisée.
6. La vraie leçon : vous héritez de briques que vous n’avez pas choisies
Les sites touchés n’ont commis aucune faute. C’est précisément ce qui doit faire réfléchir.
Aucun des sites exposés cette semaine n’a été négligent. Leurs propriétaires n’ont rien oublié de mettre à jour. Ils ont hérité d’une faille dans un composant qu’ils n’ont jamais choisi, dont ils ignoraient probablement l’existence, et qu’ils n’avaient aucun moyen de corriger eux-mêmes.
C’est toute la différence entre être vigilant et être exposé. La vigilance ne sert à rien quand le problème se situe trois couches sous votre site. Ce qui compte vraiment, c’est combien de couches vous avez sous les pieds, et qui est de garde quand une alerte tombe un mercredi à midi.
Questions fréquentes
Faut-il couper mon site par précaution ?▼
Pour la grande majorité des TPE et PME, non. Les organisations qui ont suspendu des services en ligne protégeaient des systèmes internes reliés à leur site, avec des données sensibles en jeu. Pour un site vitrine, la priorité est la mise à jour, pas la fermeture. La question se pose autrement si votre site traite des données sensibles et que vous n’obtenez aucune réponse de votre hébergeur.
Mon site est chez un hébergeur mutualisé. Ai-je quelque chose à faire ?▼
La mise à jour de PHP relève de l’hébergeur, et les grands hébergeurs ont annoncé avoir traité leurs serveurs dès le 21 octobre. Votre travail est double : le faire confirmer par écrit, et vérifier quelle branche de PHP votre hébergement utilise réellement, car c’est souvent vous qui la choisissez dans votre espace client. Un hébergement laissé sur une branche ancienne ne bénéficie pas forcément du correctif.
WordPress est-il responsable de cette faille ?▼
Non. La faille est dans PHP, le moteur sur lequel WordPress s’exécute. Un WordPress parfaitement à jour posé sur un PHP non corrigé était exposé. À l’inverse, mettre à jour WordPress et ses extensions ne protège pas de cette faille : c’est la version de PHP qui doit changer.
Comment savoir si mon site a déjà été piraté ?▼
Les signes à chercher : pages modifiées ou défigurées, redirections inattendues vers des sites tiers, comptes administrateurs inconnus, fichiers déposés récemment que personne ne reconnaît, hausse inexpliquée du trafic sortant, ou avertissement de sécurité dans Google Search Console. En cas de doute, faites examiner les journaux d’accès du serveur sur la période du 20 au 22 octobre 2026.
Et si les données de mes clients ont fuité ?▼
L’article 33 du RGPD prévoit la notification de la violation à la CNIL dans les 72 heures suivant sa prise de connaissance, et l’article 34 l’information des personnes concernées lorsque le risque pour elles est élevé. Un dépôt de plainte est également possible. Compte tenu des délais et des enjeux, faites-vous accompagner par un conseil dès le doute.
Un site sans PHP, est-ce un site moins puissant ?▼
Pour un site de présentation, un catalogue, une prise de rendez-vous ou un formulaire de contact, non : les traitements existent toujours, ils tournent simplement ailleurs, dans un environnement isolé et mis à jour par son éditeur. Pour une boutique à fort volume avec un back-office très riche, le choix se discute au cas par cas, et PHP correctement tenu à jour reste une option défendable.
Comment connaître la version de PHP utilisée par mon site ?▼
Trois méthodes, de la plus simple à la plus fiable. L’encadré en haut de cette page la lit pour vous quand le serveur l’annonce. L’espace client de votre hébergement l’affiche presque toujours, souvent dans une rubrique « version PHP » que vous pouvez d’ailleurs y changer vous-même. Enfin, la seule réponse qui fait foi est celle de votre hébergeur par écrit, parce que l’en-tête public ne donne que la branche, par exemple 8.3, et jamais le numéro complet comme 8.3.36.
Comment savoir si mon site est fait avec WordPress ?▼
Si l’adresse de votre espace d’administration se termine par /wp-admin ou /wp-login.php, c’est WordPress. L’encadré de vérification de cette page le détecte également, en reconnaissant dans le code de votre page d’accueil des signatures propres à WordPress comme wp-content. À savoir : WordPress fonctionne avec PHP, donc tout site WordPress est concerné par la question de la version de PHP.
Conclusion
PHP2Shell n’est pas une alerte de plus dans un flux d’actualités. C’est un rappel brutal que la sécurité d’un site ne se décide pas le jour de l’incident, mais le jour où l’on choisit sur quoi il repose.
Si votre site tourne en PHP, vous avez une seule chose à faire aujourd’hui : obtenir par écrit le numéro de version exact en service et la date d’application du correctif. Si personne ne vous répond, vous venez d’apprendre quelque chose d’important sur votre prestataire.
Et si vous ne savez pas du tout sur quoi votre site repose, c’est peut-être l’information la plus utile de cet article.
Un site qui n’avait rien à mettre à jour le 21 octobre
Nous créons des sites sans moteur PHP, livrés depuis un réseau de diffusion mondial, et nous les tenons à jour pour vous. 0 € de création, puis à partir de 29 € HT/mois, sans engagement de durée.
Voir l’offre de création de site
