PHP2Shell : la faille PHP qui a exposé 7 sites sur 10 et pourquoi les alertes se multiplient 

Le 20 octobre au matin, un message publié sur le forum Hacker News annonce la divulgation imminente de deux failles critiques dans PHP. Il est retiré dans la foulée, mais trop tard : les captures d’écran circulent déjà. Quelques heures plus tard, l’équipe de PHP avance la sortie de ses correctifs au lendemain, un jour plus tôt que prévu. C’est le genre de course contre la montre qui se joue en coulisses et dont le grand public n’entend presque jamais parler.

Pourtant, cette fois, ça vous concerne, même si vous n’avez jamais écrit une ligne de code. Je vous explique ce qui s’est passé, ce que ça change pour vous selon que vous êtes simple internaute ou propriétaire d’un site, et pourquoi les alertes de ce genre vont continuer à tomber.

PHP, c’est quoi et pourquoi vous l’utilisez sans le savoir

PHP est un langage de programmation qui tourne sur les serveurs, ces ordinateurs qui hébergent les sites web. Quand vous ouvrez une page, PHP fabrique à la volée ce que vous voyez : l’article, votre panier, la liste de vos commandes. Vous ne le voyez jamais, un peu comme le moteur sous le capot d’une voiture.

Et ce moteur est partout. Selon le service de mesure W3Techs, PHP fait tourner 69,3 % des sites web dont on connaît la technologie côté serveur. WordPress, qui propulse une énorme part des blogs, des sites vitrines et des boutiques en ligne, repose entièrement sur lui. Si vous avez déjà créé un site avec WordPress, vous utilisez PHP, que vous le sachiez ou non.

Ce qui s’est passé : la chronologie

L’affaire a démarré bien avant la fuite. Voici les dates, telles que les ont reconstituées l’entreprise de sécurité Sansec et le magazine Help Net Security :

1. 1er août 2026 : les chercheurs de la société Calif découvrent plusieurs façons d’exécuter du code à distance dans PHP.
2. 11 août : Calif signale la première faille à l’équipe de PHP, dans le cadre d’une divulgation coordonnée (le chercheur prévient l’éditeur en privé et attend le correctif avant de publier).
3. 24 août : les chercheurs de Wiz signalent à leur tour les mêmes failles.
4. 17 octobre : le réseau de pièges d’Amazon, conçu pour attirer les pirates, enregistre une tentative d’exploitation, quatre jours avant la publication officielle.
5. 20 octobre : les détails fuitent publiquement.
6. 21 octobre : PHP publie les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Le détail du 17 octobre mérite qu’on s’y arrête. Quelqu’un tentait déjà d’exploiter la faille alors qu’elle était encore secrète. Personne ne sait comment cette personne en a eu connaissance.

Pourquoi c’est si grave : la faille est dans le moteur, pas dans le site

D’habitude, les failles que je vous signale touchent un logiciel précis : une extension WordPress, un navigateur, un système d’exploitation. Ici, c’est le moteur commun qui est en cause. Concrètement, un site parfaitement entretenu, avec un WordPress à jour et des extensions sûres, restait vulnérable, simplement parce qu’il tournait sur PHP.

Les deux failles permettent une exécution de code à distance (remote code execution, ou RCE, en anglais). C’est le pire scénario : un pirate fait tourner son propre programme sur le serveur, sans compte ni mot de passe. Il peut alors voler les données des clients, piéger les pages ou installer une porte dérobée pour revenir plus tard. Le nom PHP2Shell dit exactement ça : de PHP au shell, la ligne de commande du serveur.

Les chercheurs ne se sont pas contentés de la théorie. Calif a démontré une prise de contrôle sans mot de passe sur WordPress 7.1.2 et sur la plateforme de boutiques Magento, parmi une dizaine d’applications. Wiz a fait de même sur WordPress, Drupal et Joomla. Et selon Sansec, le code fautif date de PHP 5.4, sorti en 2012. Ça fait quatorze ans que ce trou existait sans que personne ne le voie.

Soyons clairs sur ce qu’on sait et ce qu’on ne sait pas. L’avis officiel de PHP classe ces failles comme critiques, mais d’exploitation complexe : il faut des conditions précises côté serveur. Au soir du 21 octobre, la société Huntress n’avait observé aucune attaque chez ses clients. Cloudflare a de son côté signalé des attaques précoces, et Sansec s’attend à une exploitation massive maintenant que tout est public. Bref, rien ne prouve à ce jour une vague d’attaques, mais personne de sérieux ne parierait dessus.

Vous êtes simple internaute : qu’est-ce que ça change pour vous ?

Bonne nouvelle : vous n’avez rien à installer. PHP ne tourne pas sur votre PC, votre Mac ou votre téléphone. Ce sont les sites que vous visitez qui doivent se mettre à jour, et la balle est dans le camp de leurs propriétaires et de leurs hébergeurs.

Le risque pour vous est indirect. Un site piraté peut voir fuiter les données de ses clients, ou servir à piéger ses visiteurs, par exemple avec un faux formulaire de paiement. C’est le même mécanisme que celui que j’ai décrit dans mon article sur les fuites de données qui viennent d’un sous-traitant : vous n’avez commis aucune faute, et vous en subissez quand même les conséquences.

Trois réflexes limitent les dégâts :

• Un mot de passe différent par site, idéalement rangé dans un gestionnaire de mots de passe, pour qu’une fuite chez un marchand ne vous ouvre pas tous vos comptes.
• Méfiance envers les mails et SMS qui vous parlent d’une commande ou d’un compte dans les semaines qui suivent une alerte de ce genre.
• Surveillance de vos relevés bancaires si vous achetez sur de petites boutiques en ligne.

Vous avez un site ou un blog : ce qu’il faut faire maintenant

Ici, le piège est simple : mettre à jour WordPress ne corrige rien. WordPress tourne sur PHP, il ne le contient pas. Mon guide pour bien faire la mise à jour de WordPress reste utile, mais la version de PHP dépend de votre hébergeur.

Première étape : regardez la version. Dans l’administration de WordPress, ouvrez Outils, puis Santé du site, onglet Informations, rubrique Serveur. Vous y lisez la version de PHP. Si elle est inférieure à 8.2, vous êtes sur une version que le projet PHP ne corrige plus officiellement : c’est le moment de passer à une version récente depuis le panneau de votre hébergeur.

Deuxième étape : demandez confirmation à votre hébergeur. Et c’est là que ça se corse. Les grands hébergeurs installent souvent des correctifs sans changer le numéro de version affiché. J’en ai fait l’expérience sur mon propre hébergement le 22 octobre : PHP y affiche toujours 8.3.35, la version d’avant le correctif, mais le programme a été recompilé le 21 octobre et o2switch, mon hébergeur, a communiqué sur le sujet.

Un ticket au support règlera la question en cinq minutes.

Au passage, si votre site passe par Cloudflare, sachez que le service a déployé dès le 21 octobre des règles de pare-feu applicatif (WAF, Web Application Firewall en anglais) contre les vecteurs d’attaque connus, y compris pour l’offre gratuite. Ça freine les attaques, mais ça ne remplace pas le correctif. Le projet PHP est formel : seule la mise à jour protège complètement.

Si vous avez des doutes sur une intrusion déjà réalisée, cherchez les signes classiques d’un site compromis : un compte administrateur que vous ne connaissez pas, des fichiers modifiés récemment sans raison, des tâches planifiées inconnues. Sur ce dernier point, mon article sur WP-Cron et les tâches planifiées de WordPress vous montre où regarder.

Pourquoi les failles se multiplient-elles autant ?

Si vous avez l’impression que les alertes de sécurité tombent plus souvent qu’avant, vous avez raison. Les chiffres donnent le vertige. Selon une analyse du groupe de renseignement sur les menaces de Google (GTIG), publiée le 30 septembre 2026, le nombre de failles publiées par mois est passé de 5 045 en janvier 2026 à 10 740 en août, un record. Le 13 octobre, Microsoft a corrigé 1 411 failles en un seul Patch Tuesday, son lot mensuel de correctifs, du jamais vu. Et l’organisme FIRST prévoit désormais environ 66 000 failles recensées sur l’année.

Le premier responsable porte un nom : l’intelligence artificielle. Les modèles d’IA savent aujourd’hui lire du code et y repérer des erreurs à une vitesse qu’aucune équipe humaine ne peut tenir. PHP2Shell en est l’illustration parfaite. Calif a retrouvé ces failles en repassant ses anciens travaux dans le cadre de Patch the Planet, une initiative lancée par OpenAI en juin 2026 avec la société Trail of Bits pour faire chasser les failles des logiciels libres par l’IA, sous contrôle humain. OpenAI figure d’ailleurs parmi les découvreurs crédités. Selon Wiz, exploiter ces failles exigeait jusqu’ici une chaîne d’étapes extrêmement complexe, et « les modèles d’IA de pointe ont considérablement abaissé cette barrière ».

Ce n’est pas un cas isolé. En juillet 2026, la faille wp2shell, qui touchait le cœur même de WordPress, avait été découverte par un chercheur qui s’appuyait sur un modèle d’OpenAI. Microsoft fait passer le code de Windows au crible par plus de cent agents IA, une démarche que je détaille dans mon article sur pourquoi Windows reçoit de plus en plus de mises à jour de sécurité. Ce que Microsoft fait pour Windows, tout le secteur le fait désormais pour le reste du logiciel.

Plus de failles, est-ce que les logiciels sont devenus pires ?

Non, et c’est le point qu’il faut retenir. Le nombre de failles mesure la capacité à les trouver, pas la qualité du code. Les quatorze ans de PHP2Shell le prouvent : le trou existait déjà en 2012, on ne savait juste pas le voir.

Il faut aussi relativiser les compteurs. Une partie de la hausse vient de l’automatisation des organismes qui attribuent les numéros de failles : le seul noyau Linux a produit environ 5 000 fiches entre janvier et août 2026, selon la même analyse de Google. Et surtout, l’immense majorité de ces failles ne sera jamais utilisée par un pirate : Google n’a constaté d’exploitation réelle que pour 0,23 % des failles publiées en 2026, soit environ une sur 431.

Le revers de la médaille, c’est que les pirates disposent des mêmes outils. Une IA qui aide à trouver une faille aide aussi à écrire l’attaque qui va avec. Mandiant, la branche de réponse aux incidents de Google, estimait en mars que ce délai était devenu négatif : en moyenne, les pirates exploitent une faille sept jours avant que son correctif soit disponible. Concrètement, le temps qui sépare l’alerte de l’attaque se raccourcit. C’est pour ça que repousser une mise à jour coûte plus cher qu’avant.

En pratique

Si vous avez un site, vérifiez aujourd’hui la version de PHP dans Santé du site et envoyez un message à votre hébergeur pour obtenir une confirmation écrite du correctif. Si vous êtes simple internaute, gardez des mots de passe différents partout et redoublez de prudence face aux messages qui parlent de vos commandes dans les semaines qui viennent. Dans les deux cas, installez vos mises à jour dans la semaine où elles sortent, pas dans le mois.

Ma reco si vous ne devez retenir qu’une chose : une avalanche de correctifs n’est pas le signe que tout s’effondre, c’est le signe qu’on répare plus vite. Ce qui est dangereux, c’est de laisser ces correctifs dormir.