Retour au blog

Cybersécurité

Une faille de sécurité critique expose des millions de sites web : la mise à jour à faire cette semaine

22 octobre 20267 min de lecturePar Alpha Oumar Sow

Deux failles critiques dans PHP, le moteur de WordPress et de 70 % des sites web, permettent d'en prendre le contrôle. Qui est concerné, et quoi faire.

Le mercredi 21 octobre, en fin d'après-midi, les responsables d'un logiciel présent sur la majorité des sites web ont publié une mise à jour de sécurité très attendue. Deux failles critiques permettent à un inconnu de prendre le contrôle d'un site, sans mot de passe et sans intervention de son propriétaire. Un outil prêt à l'emploi circule déjà. Si votre entreprise a un site, une boutique en ligne ou un intranet, elle est probablement concernée.

Ce qui s'est passé le 21 octobre

PHP est le langage de programmation qui fait fonctionner la majorité des sites web. Il n'est pas visible pour le visiteur : il tourne sur la machine qui héberge le site et assemble les pages avant de les envoyer au navigateur. Wiz Research avance que 70 % des sites web l'utilisent. W3Techs, qui mesure les technologies employées par les sites, compte 69,3 % des sites dont le langage côté serveur est connu.

Le 20 octobre, l'équipe de PHP a prévenu qu'une mise à jour critique arriverait le lendemain. Elle corrige deux failles, répertoriées sous les identifiants CVE-2026-109618 et CVE-2026-109619. Un identifiant CVE est un numéro public qui permet de suivre une faille et de vérifier si un correctif existe. Les deux sont notées 9,2 sur 10 sur l'échelle de gravité utilisée par les professionnels.

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toutes les versions antérieures, à partir de PHP 5.4, sont vulnérables. Le projet PHP ne publie pas de version corrigée pour 8.1 et les versions plus anciennes. Il a toutefois mis en ligne des correctifs minimaux pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent eux-mêmes. Les distributions Linux et les hébergeurs peuvent aussi proposer une version corrigée.

Le même jour, des sites gouvernementaux, en Europe et ailleurs, ont été mis hors ligne par précaution, rapporte Reuters. Unit 42, l'équipe de recherche de Palo Alto Networks, indique qu'au moins un gouvernement européen a pris cette décision.

Pourquoi votre site est concerné même sans code maison

On croit souvent qu'une faille vient d'un module ajouté, d'un thème graphique ou d'une extension installée par le prestataire. Ici, le défaut se trouve dans le moteur lui-même. WordPress, Drupal, Joomla, WooCommerce, Magento et Shopware reposent tous sur PHP. Une faille dans le moteur les traverse tous, même si leur propre code est irréprochable.

Une extension défaillante, c'est une fenêtre mal fermée. Ici, c'est le mur porteur qui est fissuré.

Wiz Research a démontré une prise de contrôle sans mot de passe sur les versions les plus récentes de WordPress, Drupal et Joomla, à partir des images officielles de ces logiciels. Autrement dit, un site à jour peut être vulnérable tant que PHP ne l'est pas.

La question n'est donc pas « ai-je installé un module douteux ? » mais « quelle version de PHP fait tourner mon site, et qui la gère ? ». Pour beaucoup de PME, la réponse se trouve chez l'hébergeur, pas dans l'équipe interne.

Ce qu'un attaquant peut réellement faire

Les deux failles permettent à une personne non authentifiée d'exécuter ses propres instructions sur la machine qui héberge le site. Concrètement, elle peut modifier le contenu du site, y injecter une page de phishing, lire des données stockées ou utiliser la machine pour attaquer d'autres systèmes.

Elles permettent aussi de lire des zones de mémoire qui ne devraient pas être accessibles. Ces zones peuvent contenir des mots de passe, des clés d'accès à des services, des jetons de connexion ou des certificats. C'est ce que les chercheurs appellent une fuite de mémoire.

Un outil nommé php2shell a été montré avant la publication du correctif. Il exécute la chaîne d'attaque en une seule opération. Wiz a confirmé qu'il fonctionnait contre WordPress, Drupal et Joomla. Rapid7 signale que d'autres équipes tentent de le reproduire et qu'une version publique est attendue. Sansec, spécialiste des boutiques en ligne, anticipe des attaques massives dans les quinze minutes suivant la publication du correctif. Ce n'est pas une preuve qu'elles ont eu lieu, mais le risque est jugé assez élevé pour que le FBI publie une alerte.

Le FBI, la police fédérale américaine, recommande de recenser les installations PHP, de corriger en priorité les systèmes accessibles depuis internet et de surveiller l'apparition de commandes système ou de téléchargements inhabituels.

L'IA a rendu cette faille visible en une semaine

Le défaut existait depuis plus de dix ans. Il n'avait jamais été exploité de manière fiable, parce que la chaîne d'étapes nécessaire était très complexe. Wiz Research l'a trouvé le 19 août 2026, en utilisant trois outils d'IA : son propre système Wiz Atlas, Gemini 4 Argon de Google et GPT-5.6 Sol d'OpenAI.

Le 20 août, l'équipe confirmait une prise de contrôle sur Drupal. Le 21, sur WordPress. Elle a prévenu l'équipe PHP le 24 août. PHP a reconnu le problème le 21 septembre et publié le correctif le 21 octobre.

« Un seul chercheur a accompli en une semaine ce qui aurait demandé des mois à une équipe de classe mondiale », résument les chercheurs de Wiz. La formulation vient de l'entreprise, ce n'est pas une mesure indépendante. Elle décrit cependant un changement concret : l'IA abaisse le coût de la découverte et de l'exploitation.

Cette arme est à double tranchant. Les mêmes modèles qui aident à trouver et corriger une faille peuvent aider à l'exploiter. La question pour une entreprise n'est donc plus « faut-il craindre l'IA ? », mais « combien de temps mon système reste-t-il sans correctif ? ».

La marche à suivre, dans l'ordre

  1. Identifier la version de PHP. Demandez à votre hébergeur ou à votre prestataire quelle version fait tourner chaque site. Un même domaine peut en cacher plusieurs : vitrine, boutique, blog, intranet.
  1. Mettre à jour vers une version corrigée. Les versions sûres sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si vous gérez un serveur vous-même, appliquez la mise à jour de votre distribution Linux, qui peut contenir le correctif. Si vous êtes chez un hébergeur, vérifiez qu'il l'a fait et demandez-lui une confirmation écrite.
  1. Traiter les versions 8.1 et antérieures. Le projet PHP ne fournit pas de version complète pour ces branches. Il existe des correctifs minimaux pour 7.4, 8.0 et 8.1, mais ils supposent de compiler le logiciel soi-même. Pour une PME, la voie réaliste est de migrer vers une version maintenue. Si la migration prend du temps, isolez le site derrière un filtre de protection ou retirez-le d'internet.
  1. Redémarrer les processus. Un correctif installé mais non chargé ne protège pas. Les serveurs web doivent redémarrer leurs processus pour prendre la nouvelle version. Demandez explicitement ce redémarrage.
  1. Vérifier les signes de compromission. Consultez les journaux du serveur web. Cherchez des demandes inhabituelles, des téléchargements de fichiers ou des processus qui lancent des commandes système. Si un doute existe, changez les mots de passe et les clés d'accès stockés sur la machine.
  1. Appliquer les protections temporaires en attendant. Deux réglages réduisent le risque : désactiver le suivi de progression des envois de fichiers et retirer la limite de mémoire par requête. Ils ne remplacent pas le correctif. Un pare-feu applicatif peut bloquer certaines attaques connues, mais il ne ferme pas la faille.
  1. Ne pas attendre. Le correctif est disponible. Chaque jour sans mise à jour est un jour où un outil public peut suffire.

Trois erreurs à ne pas commettre

La première est de croire que la mise à jour de WordPress suffit. WordPress n'est pas responsable de cette faille. Le correctif doit être appliqué à PHP, en dessous de WordPress.

La deuxième est de se fier à la sauvegarde. Une sauvegarde permet de restaurer un site après un dégât. Elle n'empêche pas un attaquant de lire des données ou d'utiliser la machine pendant des semaines.

La troisième est de penser que l'on est trop petit pour être visé. Les attaques automatisées ne choisissent pas leurs cibles à la main. Elles scannent des adresses et testent l'outil. Un site de PME est une cible valable, précisément parce qu'il est souvent moins surveillé.

Ce qu'il faut retenir

  • Deux failles critiques dans PHP, notées 9,2 sur 10, permettent de prendre le contrôle d'un site sans mot de passe.
  • Toutes les versions depuis PHP 5.4 sont concernées ; les correctifs existent pour 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
  • WordPress, Drupal, Joomla et les boutiques en ligne sont concernés même lorsqu'ils sont à jour : le défaut est dans le moteur, pas dans les extensions.
  • Les versions 8.1 et antérieures n'ont pas de version corrigée complète : il faut migrer ou isoler le site.
  • Un outil public nommé php2shell circule ; les autorités américaines et européennes recommandent une mise à jour immédiate.
  • La priorité est de connaître la version de PHP de chaque site et de faire confirmer la mise à jour par l'hébergeur.

Références

  1. [1] Wiz Research, « PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet », 21 octobre 2026
  2. [2] PHP, « Security advisory: Critical remote code execution vulnerabilities, update now », 21 octobre 2026
  3. [3] Google Cloud, « Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 », 22 octobre 2026
  4. [4] Rapid7, « CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP », 21 octobre 2026
  5. [5] Unit 42 (Palo Alto Networks), « Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 », 21 octobre 2026
  6. [6] CERT-EU, « Critical Vulnerabilities in PHP », avis de sécurité 2026-018, 21 octobre 2026
  7. [7] Reuters, « Government websites go dark after AI-discovered flaw sparks security scramble », 21 octobre 2026
  8. [8] Sansec, « Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619 », 21 octobre 2026
  9. [9] DigitalOcean, « Critical PHP RCE Vulnerabilities: Patch Now », 21 octobre 2026

Alpha Oumar Sow

Gufaca — ingénierie logicielle et IA

Profil LinkedIn

Prêt à passer à l’action ?

Réservez une séance de diagnostic de 45 minutes et repartez avec une feuille de route claire.

Réserver un diagnostic