PHP2Shell : le jour où une partie du web s'est mise en pause

Le matin du 21 octobre, le centre national de cybersécurité des Pays-Bas a éteint son propre site. C'était une précaution, et il n'a pas été le seul à la prendre.

Dans les heures qui ont suivi, la liste s'est allongée. DigiD, le portail d'identification des citoyens néerlandais, la Chambre des représentants, le port de Rotterdam, la fédération néerlandaise de football, de nombreux hôpitaux. Puis des services publics finlandais, des sites fédéraux allemands, le ministère belge des Affaires étrangères, plusieurs services de Wikimedia. En France, le ministère de l'Intérieur a confirmé dans un communiqué, cité par Reuters, avoir mis « temporairement hors ligne » les sites des préfectures, à la demande de l'ANSSI, selon franceinfo. Vers 20 heures, ceux que nous avons consultés étaient encore en maintenance.

La cause n'était pas une vague de piratages. C'était une fuite. Deux failles graves dans PHP, le langage qui fait tourner environ les trois quarts des sites dont on connaît la technologie, venaient d'être révélées avant que leur correctif soit prêt. Pendant plusieurs heures, des millions de serveurs ont été exposés à une attaque dont la recette circulait déjà.

Voici le récit de cette journée, pourquoi le problème se trouvait sous les sites plutôt que dans les sites, et les vérifications à faire si vous avez un site WordPress ou un outil en PHP.

D'ordinaire, une faille suit un parcours rodé. Un chercheur la signale discrètement aux développeurs, qui préparent un correctif. Le jour venu, la faille et sa réparation sont annoncées ensemble, et chacun peut mettre à jour avant que les attaquants s'organisent. On appelle cela une divulgation coordonnée.

Cette fois, l'ordre s'est inversé. Le 20 octobre, des détails ont fuité avant la date prévue, et l'équipe de PHP a annoncé une version de sécurité d'urgence pour le lendemain. Dans la nuit, l'archive qui avait fuité est apparue sur VirusTotal, un service d'analyse de fichiers suspects très utilisé par les spécialistes. Au matin, d'après le média spécialisé Techzine, une démonstration de l'attaque circulait sur Hacker News, un forum très lu par les développeurs.

Défenseurs et attaquants avaient désormais la même information. Restait à savoir qui irait le plus vite.

Les heures sont données en heure de Paris, d'après les chronologies publiées par Patchstack, une société spécialisée dans la sécurité de WordPress, et par le site Clubic.

Une précision importante : les signaux sur l'exploitation réelle étaient contradictoires. Patchstack observait surtout, en milieu d'après-midi, des tentatives de « sondage », sans preuve d'intrusion. Dans la journée, le ministre néerlandais Van Weel disait n'avoir « aucun signal » d'abus (NOS) ; le centre belge de cybersécurité n'avait enregistré aucune attaque. La société de sécurité watchTowr classait les failles comme exploitées, sur la foi de tentatives observées, sans nommer de victime.

Au soir du 21 octobre, aucune intrusion n'avait été confirmée publiquement. Ce qui est établi, c'est l'exposition, et le choix de nombreux organismes de ne pas prendre le risque.

D'abord, PHP. C'est un langage de programmation, l'un des plus répandus du web. Quand vous ouvrez une page, PHP est souvent le programme qui, sur le serveur, la fabrique à la volée : il lit votre demande, va chercher le contenu et renvoie la page à votre navigateur. WordPress, l'outil qui sert à créer une grande partie des sites vitrines, est écrit en PHP. Drupal, Joomla, Magento et Laravel aussi.

Les deux failles portent les numéros CVE-2026-109618 et CVE-2026-109619. Un numéro CVE est l'identifiant public attribué à chaque faille connue, pour que tout le monde parle de la même chose. L'équipe de PHP les a notées 9,2 sur 10 sur l'échelle CVSS, la grille de gravité du secteur : c'est la catégorie « critique ». Leur surnom, « PHP2Shell », résume le danger. Un « shell », c'est la ligne de commande d'un serveur, l'endroit d'où l'on peut tout lui faire faire.

Le terme technique est « exécution de code à distance ». Il veut dire qu'un inconnu, depuis n'importe où, peut envoyer au serveur une requête piégée qui lui fait exécuter ses propres commandes, comme s'il était assis devant la machine. Ici, aucun compte n'est nécessaire, aucun mot de passe : il suffit que le serveur réponde en PHP.

Une fois cette porte ouverte, les possibilités sont nombreuses : faux formulaire de paiement, envoi de courrier indésirable, fichiers chiffrés contre rançon. Les failles permettent aussi de lire une partie de la mémoire du serveur, où passent des mots de passe, des jetons de connexion ou des clés d'API. Une clé d'API, c'est le code qui permet à un site de se connecter à un autre service, comme un moyen de paiement.

C'est le cœur de cette histoire. La plupart des failles dont on entend parler touchent une extension WordPress ou un thème. On met à jour, et c'est réglé.

Cette fois, la faille se trouvait un étage plus bas. Imaginez un immeuble. WordPress, votre thème et vos extensions sont l'appartement : vous les choisissez, vous les entretenez, vous en avez les clés. PHP, c'est la structure du bâtiment, les murs porteurs et les canalisations. Vous pouviez avoir repeint, changé les serrures et posé une alarme : si les fondations avaient un défaut, l'appartement le plus soigné était exposé comme les autres.

Concrètement, vous pouviez avoir tout mis à jour le matin même : si le serveur tournait sur une version vulnérable de PHP, la porte restait ouverte. Et pour la plupart des petites entreprises, la version de PHP ne se règle pas dans le tableau de bord du site. Elle dépend de l'hébergeur.

Le réflexe de beaucoup a été d'activer le mode maintenance de WordPress, cette page « Site en maintenance, revenez plus tard » qui remplace le site pour les visiteurs. Il ne protège pas contre cette faille, pour une question d'ordre. Quand une requête arrive, c'est PHP qui la lit en premier. C'est seulement ensuite que WordPress, lui-même écrit en PHP, décide d'afficher la page de maintenance. L'attaque se joue dans ce premier instant.

C'est comme accrocher un panneau « Fermé » sur la porte de la boutique alors que le défaut se trouve dans la serrure de l'entrée de l'immeuble. Le panneau rassure, il n'arrête personne. Seules deux mesures protègent réellement : mettre à jour PHP sur le serveur, ou empêcher les requêtes de l'atteindre, par un filtrage en amont ou une coupure pure et simple.

Plusieurs grands acteurs ont déployé des protections dans la matinée : Cloudflare pour tous ses clients, OVHcloud, SiteGround. La plupart passent par un WAF, pour « Web Application Firewall », ou pare-feu applicatif : un filtre placé devant le site, qui examine chaque requête et bloque celles qui ressemblent à une attaque connue.

Ce jour-là, c'était précieux. Mais un pare-feu applicatif reconnaît des formes d'attaque, il ne répare pas le défaut : face à une variante qu'il ignore, le serveur reste vulnérable. C'est le sens de la recommandation du CERT-EU, l'équipe de réponse aux incidents des institutions européennes, et du centre de cybersécurité britannique : isoler ou couper les sites PHP exposés qu'on ne peut pas corriger immédiatement. En France, le CERT-FR recommande, pour les versions qui ne sont plus maintenues, d'isoler les serveurs puis de migrer.

La taille du problème est difficile à mesurer, et les chiffres publiés le 21 octobre doivent être lus avec prudence.

Un serveur exposé n'est ni piraté, ni forcément vulnérable : c'est une machine qui répond en PHP sur Internet, et une partie a été corrigée dans la journée. Environ 1,1 million d'entre elles affichent publiquement leur version de PHP. Parmi elles, près de 758 000 tournaient sur une version en fin de vie, de PHP 5.4 à PHP 8.1, contre environ 272 000 sur une version encore suivie. VirusTotal y a repéré environ 538 000 sites WordPress, 141 000 applications Laravel et 107 000 installations de Nextcloud, un outil de partage de fichiers.

Chaque version de PHP est entretenue quelques années, puis plus rien : l'équipe du projet ne publie plus de correctif, même pour une faille critique. On dit que la version est « en fin de vie ».

Les nouvelles versions du 21 octobre concernent PHP 8.2, 8.3, 8.4 et 8.5. L'équipe de PHP a toutefois fait une exception limitée : des correctifs minimaux, en code source, pour PHP 7.4, 8.0 et 8.1, utiles seulement à ceux qui compilent PHP eux-mêmes. Pour PHP 7.3 et plus ancien, rien. Pour la plupart des sites, la voie durable est de changer de version, en vérifiant que le thème et les extensions suivent.

Ce jour-là, beaucoup de dirigeants se sont posé une question légitime, mais incomplète : « Mon site est-il à jour ? » La question utile était autre : « Qui maîtrise chaque maillon, et à quelle vitesse peut-il réagir ? »

Un site, et plus encore un outil de gestion en ligne, est une chaîne de briques empilées. Le serveur appartient souvent à un hébergeur, qui installe et met à jour PHP. WordPress est mis à jour par vous ou par votre agence. Chaque extension dépend de son propre éditeur, le thème d'un autre. Le 21 octobre, la sécurité d'un site dépendait du maillon le plus lent de cette chaîne, et ce maillon était rarement celui que son propriétaire contrôlait.

L'exemple d'o2switch, rapporté par Clubic, montre bien cette dépendance. L'hébergeur a réagi tôt, avec une mesure provisoire dès 8 heures du matin. Mais en fin d'après-midi, ses fichiers PHP n'avaient pas encore été remplacés par la version corrigée, et il promettait à 17 h 30 un déploiement « dans les meilleurs délais ». Mettre à jour des serveurs partagés par des milliers de sites prend du temps. Pendant ce temps, ses clients ne pouvaient qu'attendre.

La question vaut aussi pour les outils en ligne qui gèrent vos devis et vos factures. Beaucoup sont construits en PHP, un choix courant et éprouvé, que n'importe quel navigateur laisse voir. Deux cas sont à distinguer.

Le premier, c'est l'application elle-même, là où vivent les devis et les factures. Au 21 octobre 2026, les pages de connexion de Sellsy, d'Axonaut et d'Evoliz renvoyaient un cookie PHPSESSID, le nom de session par défaut de PHP. Ces applications faisaient donc partie du périmètre exposé jusqu'à la mise à jour de leurs serveurs.

Le second, c'est le site vitrine. Au 21 octobre 2026, ceux d'EBP, d'Indy, de Henrri, de Zervant et d'Evoliz fonctionnaient sous WordPress (visible dans le code source de leur page d'accueil). Une vitrine tourne en général à part, sans les données des clients. Dolibarr, logiciel libre écrit en PHP, dépend de celui qui l'installe.

Cela ne veut pas dire que ces logiciels ont été piratés, ni qu'ils sont vulnérables aujourd'hui : leurs équipes ont très probablement mis à jour leurs serveurs dans la journée. Cela veut dire que, ce jour-là, leur protection dépendait, comme pour tout le monde, de la vitesse d'un maillon que leurs clients ne voient pas.

On le dit sobrement, parce que des services publics étaient hors ligne et que des équipes ont passé leur journée à éteindre des incendies. Meolya ne repose pas sur PHP, et il tourne sur nos propres serveurs. Le 21 octobre, nous n'avons rien eu à couper. Pas de mode maintenance, pas de mise à jour en urgence, aucune interruption pour nos utilisateurs. Notre chaîne de facturation électronique a elle aussi été épargnée par cette faille.

Cela ne rend pas Meolya inattaquable. Aucun logiciel ne l'est, et d'autres failles toucheront un jour d'autres briques, y compris celles que nous utilisons. La différence tient à la chaîne : le code, les serveurs et les choix techniques sont entre nos mains. Le jour où une brique que nous utilisons est touchée, c'est nous qui déployons le correctif sur nos serveurs, dès qu'il existe, sans attendre qu'un hébergeur mutualisé, un éditeur d'extension et un éditeur de thème fassent chacun leur part.

Si vous avez un site WordPress, une boutique en ligne ou un outil installé chez un hébergeur, voici les vérifications à faire cette semaine. Aucune ne demande de compétence technique.

Dans WordPress, ouvrez Outils, puis Santé du site, onglet Infos, rubrique Serveur : la version de PHP y est indiquée. Sinon, votre hébergeur ou votre agence vous la donnera. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, ou plus récentes dans la même branche.

Une question écrite suffit : « Mon site tourne-t-il sur une version de PHP corrigée contre les failles CVE-2026-109618 et CVE-2026-109619, et depuis quand ? » Si la réponse tarde ou reste vague, c'est déjà une information utile.

Il masque le site, il ne le protège pas. Si votre site ne peut pas être corrigé tout de suite, demandez à votre hébergeur de le mettre hors ligne, ou au minimum vérifiez qu'un pare-feu applicatif est actif devant lui.

Il n'y aura pas de nouvelle version officielle pour ces branches. Demandez le passage à une version suivie, en vérifiant que votre thème et vos extensions sont compatibles. C'est l'occasion de supprimer les extensions qui ne servent plus.

Les failles permettaient de lire la mémoire du serveur. Si votre site est resté exposé avant d'être corrigé, renouvelez par prudence les mots de passe d'administration et les clés de connexion aux services tiers, comme le paiement en ligne. Votre prestataire saura lesquelles sont concernées.

Pour vos outils de gestion en ligne : étaient-ils concernés, qu'ont-ils fait ? Un éditeur qui connaît sa chaîne vous répondra simplement.

À l'heure où nous écrivons, le 21 octobre ressemble davantage à une journée de coupures volontaires qu'à une vague de piratages, et c'est plutôt une bonne nouvelle : beaucoup d'organismes ont préféré débrancher plutôt que parier. La leçon dépasse PHP. Le jour où une brique très répandue tombe, il ne suffit pas d'être à jour. Il faut savoir qui tient chaque maillon de vos outils, et à quelle vitesse il peut agir.

• Projet PHP, avis de sécurité du 21 octobre (officiel, en anglais)
• Projet PHP, annonce du 20 octobre (officiel)
• CERT-FR, alerte CERTFR-2026-ALE-014
• Reuters, les préfectures hors ligne (via Boursorama)
• Actu17, déclaration du ministère de l'Intérieur
• Reuters, les sites mis hors ligne le 21 octobre (via Global Banking & Finance, en anglais)
• VirusTotal, mesure de l'exposition des serveurs PHP (en anglais)
• Patchstack, alerte, chronologie et versions corrigées (en anglais)
• Clubic, votre hébergeur protège-t-il vraiment votre site ?
• Techzine, pourquoi PHP2Shell concerne toutes les entreprises (en anglais)
• Idetik, pourquoi le mode maintenance ne protège pas
• NOS, suivi en direct (en néerlandais)
• watchTowr, fiche PHP2Shell (en anglais)

Faits connus au 21 octobre 2026 à 20 heures, heure de Paris. Cet article relate une actualité en cours : les chiffres, la chronologie et la liste des sites coupés peuvent encore évoluer. Il ne remplace pas un diagnostic de sécurité ; pour votre site, rapprochez-vous de votre hébergeur ou de votre prestataire.