Ce qui s'est passé

Le 17 juillet 2026, le projet WordPress a publié en urgence les versions 7.0.2, 6.9.5 et 6.8.6, corrigeant ce qu'il décrit comme une faille critique et une faille de sévérité élevée. Prises séparément, ces deux vulnérabilités — référencées CVE-2026-63030 et CVE-2026-60137 — ne sont pas catastrophiques. Enchaînées, elles permettent à un visiteur anonyme d'exécuter du code sur le serveur qui héberge le site. Sans compte, sans mot de passe, sans extension particulière installée. Celle qui rend l'enchaînement possible, la CVE-2026-63030, a été signalée par Adam Kues, d'Assetnote — la branche recherche offensive de la société britannique Searchlight Cyber —, qui a baptisé la chaîne wp2shell ; l'injection SQL vient d'une autre équipe de chercheurs.

La suite a été rapide. Des exploits publics ont circulé dans les heures suivant la publication du correctif. Le 20 juillet, le CERT-FR — le centre gouvernemental français de veille et de réponse aux attaques informatiques — a ouvert une alerte en indiquant avoir « connaissance d'une preuve de concept publique » et anticiper « des tentatives d'exploitations en masse ». Le 21 juillet, l'agence américaine de cybersécurité (CISA) a inscrit les deux failles à son catalogue des vulnérabilités activement exploitées, ce qui n'est pas une prévision mais un constat. Sur des sites déjà compromis, les équipes de Wiz ont relevé l'installation de portes dérobées en PHP et de fausses extensions. La création d'un compte administrateur est du reste une étape de l'attaque elle-même : plusieurs éditeurs de sécurité en ont dénombré des dizaines dans leurs pots de miel.

Sur les versions concernées, il faut être précis. L'injection SQL touche les branches 6.8.x antérieures à 6.8.6, 6.9.x antérieures à 6.9.5 et 7.0.x antérieures à 7.0.2. Mais la chaîne complète, celle qui mène à l'exécution de code sans authentification, exige la seconde faille : elle ne concerne que les versions 6.9 et suivantes. Les versions antérieures à 6.8 ne sont pas affectées. Compte tenu de la gravité, le projet WordPress a forcé la mise à jour automatique sur les installations concernées qui l'acceptent.

« Je n'ai qu'un site vitrine »

C'est la réaction la plus fréquente, et c'est là que le raisonnement se trompe de cible. Un attaquant qui prend la main sur un site vitrine ne s'intéresse ni à vos photos de chantier ni à votre page « Qui sommes-nous ». Il s'intéresse au serveur, et il en fait trois usages.

Le premier : héberger des pages de hameçonnage sous votre nom de domaine. Une fausse page de connexion bancaire servie depuis l'adresse d'une entreprise locale connue passe la plupart des filtres de réputation — jusqu'à ce que le domaine finisse sur les listes noires, avec vous dessus. Le deuxième : envoyer du courrier indésirable en masse depuis votre serveur. Le jour où votre domaine est classé comme émetteur de spam, ce sont vos devis et vos factures qui arrivent dans les indésirables de vos clients. Le troisième : servir de point d'appui. La base de données du site contient les messages de votre formulaire de contact, donc souvent des noms, des adresses mail, des numéros de téléphone — des données personnelles. Si leur fuite présente un risque pour les personnes concernées, elle doit être notifiée à la CNIL dans les 72 heures suivant sa découverte, et dans tous les cas consignée dans votre registre des violations.

Le site vitrine n'est pas un dépliant. C'est un serveur allumé en permanence, joignable par n'importe qui sur la planète, sur lequel tourne du code que vous n'avez pas écrit.

Le vrai problème n'est pas WordPress

WordPress fait tourner une part considérable du web, il est bien maintenu, et son équipe a réagi vite et proprement sur ce dossier. Une faille de cette nature aurait pu toucher n'importe quel outil comparable.

Le problème, dans la plupart des PME que nous rencontrons, est ailleurs : personne ne possède le site. Il a été fait il y a trois ou quatre ans, par une agence, un indépendant ou un proche. L'hébergement est payé par prélèvement automatique sur une carte qui a changé depuis. Personne ne sait quelle version tourne, personne ne reçoit les alertes de sécurité, et la seule personne qui avait les accès n'est plus dans l'entreprise. Tant que le site s'affiche, tout va bien. Le jour d'une alerte comme celle-ci, il n'y a personne pour agir — et souvent, même personne pour savoir s'il faut agir.

C'est exactement le mécanisme que nous décrivions à propos de la vague de failles SharePoint : le correctif existe, il est gratuit, il est publié le jour même, et il n'est pas appliqué parce que personne n'a la responsabilité de l'appliquer. La sécurité d'une PME se joue rarement sur la technique. Elle se joue sur la question « qui s'en occupe ? ».

La mise à jour automatique ne dit pas où vous en êtes

WordPress a forcé les mises à jour, et c'est une excellente nouvelle : la majorité des sites sont passés en 7.0.2 ou 6.9.5 sans que personne ne lève le petit doigt. Mais s'en remettre à ce mécanisme revient à ne pas savoir où l'on en est.

La mise à jour forcée ne s'applique qu'aux installations qui l'acceptent — et beaucoup ne l'acceptent pas : des agences la désactivent pour éviter qu'une mise à jour ne casse un thème sur mesure, et certains hébergeurs la reprennent à leur compte, avec leur propre calendrier. Elle ne couvre pas non plus les extensions et les thèmes, qui restent la porte d'entrée la plus courante sur les sites WordPress. Autrement dit : la mise à jour automatique est un bon filet de sécurité, ce n'est pas une réponse à la question « mon site est-il à jour ? ». La seule réponse valable est une réponse vérifiée.

Corriger n'est pas nettoyer

Nous l'écrivions déjà à propos de SharePoint : un correctif ferme la fenêtre, il n'expulse pas celui qui est déjà entré. C'est le point le plus souvent manqué, et il compte davantage que le reste. Si votre site est resté vulnérable pendant la fenêtre d'exploitation — c'est-à-dire du 17 juillet jusqu'à sa mise à jour effective — alors le correctif ferme la porte, mais il ne fait pas sortir ce qui est déjà entré. Une porte dérobée déposée avant la mise à jour continue de fonctionner après.

Ce qu'il faut regarder, dans l'ordre : la liste des comptes administrateurs (un compte que personne ne reconnaît est un signal sans ambiguïté), la liste des extensions installées, les fichiers modifiés récemment dans le dossier wp-content, et les tâches planifiées du site. En cas de doute sérieux, la voie la plus sûre n'est pas le nettoyage manuel — on en oublie toujours un morceau — mais la restauration d'une sauvegarde antérieure au 17 juillet, suivie immédiatement de la mise à jour. Encore faut-il disposer d'une sauvegarde suffisamment ancienne : la durée de rétention varie fortement d'un hébergeur à l'autre — d'une semaine à trois mois selon les offres —, et c'est typiquement ce qu'on découvre le jour où on en a besoin. C'est le genre de situation où la règle de sauvegarde 3-2-1 cesse d'être une théorie.

Cinq vérifications à faire cette semaine

Aucune ne demande de compétence technique particulière, et toutes tiennent en une matinée.

Réduire l'enjeu plutôt que courir après les correctifs

Il y a une question de fond derrière cet épisode : un site vitrine a-t-il besoin d'exécuter du code à chaque visite ? Dans beaucoup de cas, non. Des pages construites une fois puis servies telles quelles, sans base de données ni traitement côté serveur, n'offrent tout simplement pas de prise à ce type de faille — il n'y a rien à exécuter, donc rien à corriger dans l'urgence.

C'est le choix que nous avons fait pour ce site : il tournait sous WordPress jusqu'en juillet 2026, il est aujourd'hui entièrement statique. Nous ne le présentons pas comme une réponse universelle. Un site avec une boutique, un espace client, un moteur de réservation ou une équipe qui publie chaque semaine a besoin d'un vrai système de gestion de contenu ; dans ce cas la bonne réponse n'est pas de changer de technologie, c'est un contrat de maintenance avec quelqu'un dont c'est le travail de suivre les alertes. Mais pour une PME dont le site présente une activité et recueille des demandes de contact, la question mérite d'être posée une fois, sérieusement. Nous en parlons volontiers dans le cadre de nos projets web.

Notre lecture

La faille wp2shell ne sera pas la dernière faille critique de l'été, et le prochain outil concerné ne sera probablement pas WordPress. Retenir de cet épisode qu'il faut se méfier d'un logiciel en particulier, c'est passer à côté.

Ce qu'il révèle, c'est qu'entre le moment où un correctif est publié et le moment où il est appliqué, il y a une organisation — ou il n'y en a pas. Les entreprises qui ont mis à jour dans la journée ne sont pas celles qui avaient le meilleur outillage : ce sont celles qui savaient qui appelait qui. Si vous ne pouvez pas répondre aujourd'hui à la question « qui met à jour notre site, et quand ? », la prochaine alerte se passera exactement comme celle-ci. Si vous le pouvez, elle sera une formalité de vingt minutes.

Sources : avis de sécurité WordPress 7.0.2 du 17 juillet 2026 (wordpress.org) ; alerte CERTFR-2026-ALE-007 du CERT-FR, publiée le 20 juillet et mise à jour le 22 juillet ; catalogue des vulnérabilités activement exploitées de la CISA, ajout des deux CVE le 21 juillet ; fiches NVD des CVE-2026-63030 et CVE-2026-60137. La divulgation initiale émane de Searchlight Cyber, et les observations de compromission de Wiz : ce sont des sociétés de cybersécurité, donc parties prenantes du sujet. Nous n'avons pas repris les scores de gravité chiffrés, sur lesquels les sources publiques divergent.