PHP2Shell est le nom donné à deux failles critiques découvertes dans PHP, le langage qui fait tourner environ 70 % des sites web, dont tous les sites WordPress. Elles permettent à un inconnu de prendre la main sur le serveur d'un site sans mot de passe et sans que personne clique sur quoi que ce soit. Les correctifs sont sortis en urgence le 21 octobre 2026, après une fuite. Un site qui s'affiche normalement peut très bien être touché. Les faits ci-dessous ont été vérifiés le 23 octobre 2026.
PHP2Shell en deux minutes
- Quoi. Deux failles (CVE-2026-109618 et CVE-2026-109619) dans PHP lui-même, notées 9,2 sur 10 par l'équipe de PHP et 10 sur 10 par la société de sécurité watchTowr. Elles permettent d'exécuter du code à distance, c'est-à-dire de faire faire au serveur ce que veut l'attaquant. Elles peuvent aussi laisser lire la mémoire du serveur, où passent des mots de passe et des clés d'accès.
- Quand. Les détails ont fuité le 20 octobre 2026, deux jours avant la date de publication prévue. PHP a publié ses correctifs le 21 octobre.
- Qui. Tout serveur qui utilise PHP pour afficher des pages web, des versions 5.4 (2012) à 8.5. WordPress, Joomla, Drupal, PrestaShop, Magento et les sites Laravel ou Symfony tournent sur PHP.
- Que faire. Passer en PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, puis redémarrer PHP. L'équipe de PHP est claire : il n'existe pas de protection complète, mettre à jour est le seul choix sûr.
Comment on en est arrivé là
La faille la plus ancienne vient d'un code présent depuis PHP 5.4, sorti en 2012. Selon la synthèse publiée depuis, un développeur de PHP avait repéré l'un des deux bugs dès 2024, lors d'un audit. Il n'a pas été corrigé : l'équipe ne s'accordait pas sur la bonne correction, et personne ne savait l'exploiter. Le sujet est passé au second plan.
En août 2026, deux équipes de chercheurs le retrouvent chacune de leur côté, chez Calif et chez Wiz, en s'aidant de modèles d'intelligence artificielle capables de passer au crible de grandes quantités de code ancien. C'est le changement de fond de ces derniers mois : l'IA accélère la découverte des failles. Elle aide les défenseurs, et elle aide tout autant ceux qui attaquent.
La publication devait être coordonnée pour le 22 octobre, avec des correctifs prêts. Le 20, des détails circulent sur Hacker News et sur X, et une vidéo de démonstration est publiée par erreur. PHP avance sa version corrective au lendemain. Amazon a depuis retrouvé une tentative d'exploitation datée du 17 octobre, et watchTowr a observé des attaques réelles dès le jour des correctifs.
Il faut ajouter une donnée rarement connue : PHP, utilisé par une majorité des sites du monde, est maintenu par une petite équipe. La PHP Foundation compte treize salariés et vit de dons. Un code très ancien, une diffusion énorme, une équipe réduite et des outils qui trouvent les failles plus vite : tous les ingrédients étaient réunis.
La réaction a été à la hauteur. L'agence américaine NSA a recommandé de couper les sites qui ne pouvaient pas être mis à jour tout de suite. Plusieurs administrations européennes ont mis des sites hors ligne par précaution, dont le portail du gouvernement néerlandais et les sites du ministère français de l'Intérieur.
« Mon site fonctionne » : pourquoi ça ne prouve rien
C'est la phrase qu'on entend le plus, et elle est vraie : le site s'affiche, les formulaires partent, les clients appellent. Elle ne dit pourtant rien de sa sécurité, pour quatre raisons.
- La faille est sous le capot. PHP2Shell touche le moteur qui fabrique les pages, pas les pages elles-mêmes. Une voiture aux freins usés roule très bien, jusqu'au jour où il faut freiner.
- L'attaque ne demande rien. Pas de compte, pas de mot de passe, pas de clic d'un employé. Des robots balaient internet en continu et essaient la faille sur tous les serveurs qui répondent. Ils ne choisissent pas leur cible : la taille de votre entreprise ne vous protège pas.
- Une attaque réussie ne se voit pas. Un pirate qui prend la main sur un serveur a tout intérêt à rester discret. Il installe une porte dérobée pour revenir plus tard, envoie du spam depuis votre serveur, redirige vos visiteurs mobiles vers des arnaques ou copie les données de vos formulaires. On le découvre souvent quand Google affiche un avertissement à côté du site, ou quand l'hébergeur coupe le compte.
- Les données sont en jeu. La mémoire du serveur contient les accès à la base de données et les clés qui relient le site à vos outils (paiement, emailing, CRM). Une fuite de données personnelles doit être notifiée à l'Autorité de protection des données dans les 72 heures, au titre du RGPD.
Un dernier point : une mise à jour ferme la porte, elle ne fait pas sortir quelqu'un qui serait déjà entré. Un site resté exposé plusieurs jours mérite une vérification en plus du correctif.
Qui est concerné
Tout site dont les pages sont fabriquées par PHP : WordPress, Joomla, Drupal, PrestaShop, Magento, les sites sur mesure en Laravel ou Symfony, mais aussi les panneaux d'administration d'hébergement comme cPanel ou Plesk. Le niveau de risque dépend de la façon dont PHP est installé (les serveurs Apache avec PHP intégré sont les plus exposés), mais aucune installation qui sert des pages web n'est épargnée. La situation dépend surtout de la version :
| Version de PHP | Situation au 23/10/2026 | Que faire |
|---|---|---|
| 8.2, 8.3, 8.4, 8.5 | Correctif officiel publié le 21 octobre | Mettre à jour (8.2.35, 8.3.36, 8.4.27 ou 8.5.12) et redémarrer PHP. La 8.2 n'est plus maintenue après le 31 décembre 2026 : prévoir la suite. |
| 7.4, 8.0, 8.1 | Plus maintenues : pas de version officielle, seulement un correctif fourni sous forme de code à recompiler | Vérifier auprès de l'hébergeur que le correctif a été appliqué. Sinon, migrer vers une version maintenue. |
| 7.3 et plus ancien, dont PHP 5 | Aucun correctif | Migrer, ou couper l'accès public au site en attendant. |
Les deux dernières lignes pèsent lourd. Selon W3Techs (août 2026), plus d'un site PHP sur trois tourne encore en PHP 7 ou en PHP 5, et une bonne partie des sites en PHP 8 sont restés en 8.0 ou 8.1. Ce sont des millions de sites sans mise à jour officielle.
Les sites construits sur des plateformes hébergées comme Wix, Squarespace, Webflow ou Shopify n'ont rien à faire : la plateforme gère elle-même ses serveurs. Les sites statiques et les sites construits avec d'autres langages, comme Python, ne sont pas touchés par cette faille-là.
Pourquoi mettre PHP à jour peut casser un site
Si la mise à jour est la seule solution, pourquoi tant de sites sont-ils restés sur de vieilles versions ? Parce que changer de version de PHP peut casser le site, et qu'on repousse donc le moment de le faire.
- Chaque grande version fait le ménage. PHP 7 a supprimé les anciennes fonctions d'accès aux bases de données, PHP 8 en a retiré d'autres et est devenu plus strict : ce qui provoquait un simple avertissement provoque désormais une erreur, et l'erreur donne une page blanche.
- Le site n'est pas seul. Le thème, les extensions et les librairies doivent tous suivre. Une extension abandonnée par son auteur en 2019 ne sera jamais rendue compatible : il faut la remplacer, et parfois refaire ce qu'elle faisait.
- L'effet escalier. Monter d'une version par an est une petite intervention. Passer de PHP 7.4 à 8.4 d'un coup, c'est franchir cinq marches à la fois, chacune avec ses changements : l'intervention devient un chantier, parfois une refonte.
Beaucoup de sites restés en PHP 7 ne l'ont pas été par négligence. La mise à jour représentait un budget que personne n'avait prévu, alors on a attendu. C'est la dette technique : un coût repoussé qui grossit avec le temps. PHP2Shell transforme ce coût repoussé en urgence.
L'iceberg de la maintenance
Ce que vous voyez de votre site n'en est que la pointe. Sous la surface, cinq couches ont chacune leur propre calendrier de mises à jour et de failles.
- Le serveur et son système : Linux, le serveur web, la base de données.
- Le langage : PHP, Python, JavaScript. C'est là que se trouve PHP2Shell.
- Le framework ou le CMS : WordPress, Drupal, Laravel, Django, Wagtail.
- Les extensions et librairies : plugins, thèmes, modules, paquets. Pour WordPress, c'est là que naissent l'immense majorité des failles.
- Votre code : ce qui a été écrit pour votre site, et qui doit s'adapter quand les couches du dessous changent.
Une faille dans n'importe laquelle de ces couches expose tout le site. Et les couches dépendent les unes des autres : changer la version du langage oblige le CMS, les extensions et votre code à suivre. C'est pour ça qu'une mise à jour de PHP peut toucher au code du site. Entretenir un site, c'est faire avancer les cinq couches ensemble, par petits pas, plutôt que de laisser l'écart se creuser.
Et Python, Django, Wagtail ?
PHP2Shell ne concerne que PHP. Un site construit en Python, avec Django ou Wagtail, n'est pas touché par cette faille. Il n'est pas immunisé pour autant : Django et Wagtail publient eux aussi des avis de sécurité, plusieurs fois par an (voir Wagtail est-il sécurisé ?).
Ce qui change, c'est la lisibilité du calendrier. Chaque version de Python reçoit des correctifs pendant environ cinq ans. Django publie une version à support long tous les deux ans : la 5.2 est corrigée jusqu'en avril 2028, alors que les versions 5.0 et 5.1 ne le sont déjà plus. Wagtail suit le même principe : la 7.4 LTS est maintenue jusqu'au 2 novembre 2027, les versions intermédiaires environ six mois (voir quelle version de Wagtail choisir).
Ces dates sont publiques et connues des années à l'avance, ce qui permet de planifier les montées de version au lieu de les subir. Mais la règle reste la même que pour PHP : un site Django 5.0 en 2026 ne reçoit plus aucun correctif, exactement comme un site en PHP 7.4. Le langage ne protège pas un site ; ce sont ses mises à jour qui le protègent.
Sans mise à jour, personne n'est à l'abri
Aucun langage, aucun CMS, aucun prestataire n'échappe aux failles. La seule question qui compte est le délai entre la publication d'un correctif et son application sur votre site. Avec un entretien suivi, ce délai se compte en heures ou en jours. Sans entretien, il est infini.
Cinq questions à poser à votre prestataire ou à votre hébergeur cette semaine :
- Quelle version de PHP (ou de Python, de Django) fait tourner mon site, et jusqu'à quand est-elle maintenue ?
- Le correctif PHP2Shell a-t-il été appliqué, et PHP a-t-il été redémarré ?
- Qui surveille les avis de sécurité, et en combien de temps les correctifs sont-ils posés ?
- Quand le CMS, le thème et les extensions ont-ils été mis à jour pour la dernière fois ?
- Existe-t-il une sauvegarde récente, stockée ailleurs que sur le serveur, et a-t-elle déjà été restaurée pour test ?
Si personne ne sait répondre, votre site n'a pas d'entretien. Un budget annuel modeste coûte moins cher qu'une intervention en urgence, et beaucoup moins qu'un site piraté. Si vous voulez faire le point sur le vôtre, prenez quinze minutes avec nous.
Sources
- Annonce de sécurité de PHP, 21 octobre 2026
- FAQ PHP2Shell de watchTowr
- Analyse de Qualys
- Chronologie sur Wikipedia
- Usage de PHP et de ses versions, W3Techs
- Versions maintenues de Django et calendrier des versions de Wagtail