Deux failles de sécurité critiques dans PHP, le langage de programmation derrière environ 69 % des sites web dont la technologie serveur est connue (W3Techs), ont mis une grande partie du web en alerte le 21 octobre 2026. Les failles sont référencées CVE-2026-109618 et CVE-2026-109619, et les chercheurs les ont surnommées PHP2Shell. L’équipe de sécurité de PHP les note toutes deux 9,2 sur 10 sur l’échelle de gravité CVSS v4.0, et l’équipe de cybersécurité de l’Union européenne CERT-EU indique que ce score correspond à un risque d’exécution de code à distance sans aucune authentification. En clair, un attaquant pourrait exécuter son propre code sur un serveur web vulnérable.
Cet article s’adresse à ceux qui se soucient de l’endroit où finissent leurs données personnelles : les professionnels qui se connectent chaque jour à des portails clients et des services en ligne, les dirigeants de petites entreprises dont le site ou la boutique tourne peut-être sous PHP, et toute personne qui a vu des sites familiers disparaître et s’est demandé si ses propres comptes étaient en danger. Vous ne pouvez pas corriger un serveur qui ne vous appartient pas, mais vous pouvez décider de l’ampleur des dégâts qu’une fuite ailleurs peut vous causer.
Vous trouverez ci-dessous ce qu’est PHP2Shell, pourquoi certaines organisations ont choisi de mettre leurs sites hors ligne, ce qui est confirmé et ce qui ne l’est pas, et une courte liste d’actions qui réduisent réellement votre exposition.
Qu’est-ce que PHP2Shell ?
PHP2Shell est le surnom de deux vulnérabilités dans l’interpréteur PHP lui-même, le logiciel qui tourne sur un serveur web et transforme le code PHP en pages que vous voyez. Ce détail compte. Les failles ne se trouvent pas dans un plugin ou une application, mais dans la couche sous WordPress, Drupal, Joomla, Magento, Laravel et d’innombrables sites sur mesure. Selon la société de sécurité Patchstack, toute application reposant sur une version vulnérable de PHP est exposée, quelle que soit la qualité de maintenance de l’application elle-même.
L’équipe de sécurité de PHP a annoncé le problème le 20 octobre 2026 et programmé une version de sécurité d’urgence pour le 21 octobre à 14h00 UTC (16h00 heure de Paris). Elle a aussi indiqué se réserver le droit de publier plus tôt si des détails devenaient publics ou si des attaques apparaissaient. Les deux se sont produits plus vite que prévu : des détails ont fuité avant la divulgation coordonnée, et selon Patchstack, la société de sécurité watchTowr a pu reproduire l’une des failles.
Ce qui est confirmé et ce qui ne l’est pas
Une grande partie de ce qui a circulé ce jour-là venait de fuites et des réseaux sociaux, il est donc utile de séparer les deux.
| Affirmation | Statut au 21 octobre 2026 |
|---|---|
| Deux vulnérabilités critiques, chacune notée 9,2 (CVSS v4.0) | Confirmé par l’équipe de sécurité de PHP |
| Version d’urgence programmée pour le 21 octobre à 14h00 UTC | Confirmé par l’équipe de sécurité de PHP |
| Risque d’exécution de code à distance sans authentification | Évaluation du CERT-EU sur la base du score de gravité |
| Attaque possible avec une seule requête web forgée | Indiqué par le Centre national de cybersécurité néerlandais (NCSC) |
| Toutes les versions de PHP depuis PHP 5 sont concernées | Indiqué par le NCSC néerlandais ; PHP publie les versions exactes avec la mise à jour |
| Attaques actives en cours | Contesté : Cloudflare et Patchstack signalent de premières attaques, le NCSC néerlandais n’avait pas encore observé d’exploitation active |
Un point est certain, quels que soient les détails. Le projet PHP ne prend en charge que les versions 8.2 et ultérieures, donc les serveurs encore sous PHP 8.1 ou plus ancien ne recevront pas de correctif officiel. Ces sites dépendent de leur hébergeur pour une solution de contournement ou une mise à niveau.
Pourquoi des sites web sont passés hors ligne
Mettre un site hors ligne paraît radical, mais cela découle directement des recommandations officielles. Le National Cyber Security Centre britannique a demandé aux organisations de se préparer à mettre à jour immédiatement et, si ce n’était pas possible, d’envisager de mettre les systèmes concernés hors ligne jusqu’à correction. Le CERT-EU a conseillé d’isoler les applications PHP exposées à internet qui ne pouvaient pas être corrigées à temps. Le NCSC néerlandais a déclaré que tout système PHP accessible depuis l’internet public devait être présumé vulnérable jusqu’à sa mise à jour.
Le résultat a été visible dans toute l’Europe. Aux Pays-Bas, le service national d’identification DigiD et le portail citoyen MijnOverheid sont passés hors ligne par précaution, de même que le site du Parlement néerlandais, le site d’information RTL et le site tech Tweakers. Le NCSC néerlandais a également retiré son propre site. Cloudflare a indiqué avoir vu les premières tentatives d’attaque à 07h43 UTC, tôt dans la matinée européenne, et a déployé des règles de pare-feu pour tous ses clients, y compris l’offre gratuite. Cloudflare a lui-même décrit ces règles comme un palliatif, pas un correctif.
Pour vous en tant qu’utilisateur, un site hors ligne est la bonne issue. Cela signifie que l’organisation a préféré cesser de servir des pages plutôt que risquer de livrer vos données à un attaquant.
Ce que PHP2Shell signifie pour vos données personnelles
PHP tourne sur des serveurs web, pas sur votre iPhone ou votre ordinateur portable. Il n’y a rien à télécharger ni aucune application à mettre à jour sur vos propres appareils à cause de PHP2Shell. Le risque se situe du côté des sites et services sur lesquels vous avez des comptes : si l’un d’eux est compromis avant d’être corrigé, un attaquant pourrait accéder à tout ce que ce serveur stocke, comme des noms, des adresses e-mail, des historiques de commandes ou des empreintes de mots de passe.
C’est pourquoi la question utile n’est pas « suis-je infecté ? » mais « combien me coûterait une fuite sur un site ? ». Trois éléments en décident :
- Si vous réutilisez des mots de passe. Un mot de passe fuité d’un petit site devient une clé pour chaque compte où vous avez utilisé le même.
- Comment vos comptes sont protégés au-delà du mot de passe. L’authentification à deux facteurs avec une application d’authentification arrête la plupart des attaquants qui n’ont que votre mot de passe.
- Combien vous avez communiqué au départ. Une commande en invité ou un profil minimal laisse moins à voler qu’un compte complet avec votre adresse, votre date de naissance et vos cartes enregistrées.
Les fuites ont aussi tendance à apparaître plus tard que la vulnérabilité qui les a causées. En vertu du RGPD, les entreprises doivent informer les personnes concernées en cas de risque élevé. Si un service que vous utilisez a été touché, une notification peut donc arriver dans les semaines suivant le correctif plutôt que le jour même.
Cinq actions à faire dès aujourd’hui
Aucune de ces actions ne demande de connaissances techniques, et ensemble elles prennent moins d’une demi-heure.
- Ignorez tout ce qui vous demande de « mettre à jour PHP ». Les grandes actualités de sécurité sont immanquablement suivies de phishing. Les e-mails ou SMS qui vous pressent de cliquer sur un lien, d’installer un correctif ou de vérifier votre compte à cause de la faille PHP sont des arnaques. PHP n’est pas quelque chose que vous installez en tant que consommateur.
- Changez d’abord les mots de passe réutilisés. Commencez par votre compte e-mail, car c’est là qu’atterrit la réinitialisation du mot de passe de presque tout le reste. Un gestionnaire de mots de passe rend les mots de passe uniques praticables.
- Déplacez l’authentification à deux facteurs hors des SMS quand vous le pouvez. Une application d’authentification ou une clé d’accès est plus solide qu’un code par SMS, exposé aux attaques par SIM swap.
- Surveillez votre boîte mail et vos relevés pendant les prochaines semaines. Guettez les notifications de fuite, les e-mails de réinitialisation inattendus et les petits débits inconnus sur votre carte.
- Si vous gérez un site web, posez une question à votre hébergeur aujourd’hui. « Sous quelle version de PHP tourne mon site, et quand le correctif est-il appliqué ? » En hébergement infogéré, c’est généralement pris en charge pour vous, mais les sites sous PHP 8.1 ou plus ancien ont besoin d’une mise à niveau.
Pour information : la boutique Spy-Fy fonctionne sur Shopify, qui n’est pas bâti sur PHP, donc votre compte Spy-Fy et vos commandes ne sont pas exposés à PHP2Shell.
La place de la confidentialité physique
PHP2Shell rappelle une chose facile à oublier. Une fois que vos données se trouvent sur le serveur de quelqu’un d’autre, leur sécurité dépend de la rapidité avec laquelle il applique les correctifs. Vous n’avez aucun contrôle là-dessus. Ce que vous contrôlez, c’est ce que vos propres appareils capturent au départ.
Une faille serveur ne se corrige pas avec une coque de téléphone, et nous ne prétendrons pas le contraire. Mais la même logique s’applique à l’autre bout de la chaîne : moins vos appareils enregistrent, moins il y a à fuir, que ce soit via un service compromis, une application piratée ou un logiciel qui vous observe à travers votre téléphone. Une caméra physiquement couverte n’enregistre rien, quel que soit le serveur ou l’application qui cède ensuite. C’est l’idée derrière les coques privacy avec cache-caméra intégré de Spy-Fy.
En bref
PHP2Shell est une paire de failles critiques dans le langage qui fait tourner environ deux tiers du web, notées 9,2 sur 10, avec un correctif d’urgence programmé le 21 octobre 2026 à 14h00 UTC. De nombreuses organisations ont mis leurs sites hors ligne par précaution, ce qui est le choix responsable. Vous n’avez rien à installer, mais vous devriez utiliser des mots de passe uniques, passer votre second facteur sur une application, ignorer tout message au sujet d’une « mise à jour de PHP » et surveiller les notifications de fuite dans les semaines à venir. Protégez ce que vous pouvez contrôler, en commençant par ce que votre propre caméra peut voir, avec les coques privacy pour iPhone avec cache-caméra coulissant de Spy-Fy.
