En bref : si votre site tourne sous WordPress 6.9 ou 7.0, mettez-le à jour aujourd'hui. Une faille du cœur de WordPress permet de prendre le contrôle du site sans mot de passe, et elle est déjà exploitée sur le web.
Le 17 juillet 2026, l'équipe WordPress a publié une mise à jour de sécurité en urgence. Elle corrige une faille surnommée wp2shell, référencée sous les identifiants CVE-2026-63030 et CVE-2026-60137. Particularité : le problème est dans le cœur de WordPress, pas dans une extension. Autrement dit, un site à jour de toutes ses extensions pouvait quand même être vulnérable. Des exploitations réelles ont été observées dans les heures qui ont suivi l'annonce. Voici ce qu'une PME doit comprendre et faire, sans jargon.
Ce qui s'est passé, en une minute
WordPress fait tourner une part énorme du web, y compris beaucoup de sites de PME suisses. Deux défauts ont été trouvés dans son code par un chercheur en sécurité, et le danger vient de leur combinaison. Le premier laisse un visiteur non identifié atteindre une porte technique du site qui aurait dû lui rester fermée. Le second permet, une fois cette porte franchie, d'injecter des commandes dans la base de données du site.
Mis bout à bout, ces deux défauts permettent à un attaquant de prendre le contrôle complet d'un site vulnérable. Pas besoin de mot de passe, pas besoin de compte, pas besoin d'une extension particulière. Une seule requête envoyée depuis internet suffit. C'est ce qu'on appelle une exécution de code à distance non authentifiée, la catégorie de faille la plus grave qui existe pour un site web.
Votre site est-il concerné ?
Tout dépend de votre numéro de version. Les branches 6.9 et 7.0 sont exposées à la chaîne complète, la plus dangereuse. Les versions 6.8.x sont touchées uniquement par l'injection SQL, ce qui reste sérieux car cela permet le vol de données. Vérifiez votre version dans le tableau de bord WordPress, puis comparez avec ce tableau.
| Votre version WordPress | Risque | Version à installer |
|---|---|---|
| 6.8.0 à 6.8.5 | Injection SQL (vol de données) | 6.8.6 |
| 6.9.0 à 6.9.4 | Chaîne complète, prise de contrôle du site | 6.9.5 |
| 7.0.0 à 7.0.1 | Chaîne complète, prise de contrôle du site | 7.0.2 |
| 6.8.6 / 6.9.5 / 7.0.2 et versions plus récentes | Corrigé, rien à faire | Aucune action |
Si vous tournez sur une version antérieure à 6.8, vous accumulez de toute façon des mois de correctifs manqués. Mettez à jour sans attendre, après avoir sauvegardé le site.
Pourquoi cette faille sort du lot
La plupart des failles WordPress dont on entend parler viennent d'extensions tierces : un plugin de formulaire, un constructeur de page, un outil de réservation mal codé. Ici, c'est différent. Le défaut est dans le cœur du logiciel, celui que tout le monde installe par défaut. C'est rare, et c'est précisément ce qui rend l'affaire sérieuse.
Trois éléments s'additionnent. La faille ne demande aucune authentification, donc n'importe qui sur internet peut tenter sa chance. Elle s'exploite en une requête, donc les attaques peuvent être automatisées à grande échelle. Et des programmes d'exploitation ont été rendus publics très vite, ce qui met l'outil entre les mains de n'importe quel acteur malveillant, pas seulement de spécialistes. Quand ces trois conditions sont réunies, le temps entre "faille annoncée" et "site attaqué" se compte en heures.
Que faire maintenant, dans l'ordre
Mettre à jour, tout de suite
Dans le tableau de bord, allez dans Tableau de bord puis Mises à jour et installez la version corrigée qui correspond à votre branche (6.8.6, 6.9.5 ou 7.0.2). Sauvegardez d'abord, puis vérifiez le nouveau numéro de version une fois la mise à jour faite. Ne partez pas du principe qu'une mise à jour automatique s'en est chargée.
Si vous ne pouvez pas patcher dans l'heure
Certains sites sur mesure ou lourdement personnalisés ne peuvent pas être mis à jour en un clic sans risque de casse. Dans ce cas, faites bloquer l'accès à l'endpoint concerné (/wp-json/batch/v1) au niveau du serveur ou d'un pare-feu applicatif, et restreignez l'API REST aux utilisateurs connectés. À considérer comme un pansement : ça vous fait gagner du temps, ça ne remplace pas la mise à jour.
Vérifier que vous n'êtes pas déjà touché
La mise à jour bouche le trou, mais elle ne répare pas un site déjà piraté. Passez en revue les signaux de compromission ci-dessous avant de considérer l'affaire close.
Comment savoir si vous avez déjà été piraté
Un attaquant qui prend le contrôle d'un site laisse souvent des traces pour garder son accès, même après une mise à jour. Voici les signes à contrôler, tous visibles depuis votre administration ou votre hébergeur :
- Des comptes administrateurs que vous ne reconnaissez pas dans la liste des utilisateurs.
- Des extensions ou thèmes installés que personne dans l'équipe n'a ajoutés.
- Des articles ou pages publiés à votre insu, souvent du spam ou des liens douteux.
- Des fichiers récemment modifiés à des endroits inhabituels, par exemple des fichiers de code dans le dossier des médias téléversés.
- Une alerte de Google Search Console signalant un "contenu piraté", ou votre site marqué comme dangereux par le navigateur.
Si vous constatez l'un de ces signaux, ne vous contentez pas de mettre à jour. Une porte dérobée déjà installée survit au correctif. Il faut alors isoler le site, restaurer une sauvegarde antérieure à l'intrusion, changer l'ensemble des mots de passe et régénérer les clés de sécurité. Si vous n'êtes pas certain de bien faire, confiez cette partie à quelqu'un dont c'est le métier. Un nettoyage incomplet laisse la porte ouverte.
La vraie leçon pour une PME
Le point à retenir n'est pas "WordPress, c'est mauvais". WordPress reste un outil solide qui fait tourner des millions de sites, et une faille du cœur comme celle-ci est rare. Le vrai enseignement est ailleurs : un site qui interroge une base de données et exécute du code à chaque visite a un coût de maintenance invisible mais bien réel. Quelqu'un doit surveiller les annonces de sécurité et appliquer les correctifs vite, en heures, pas en mois. Si personne ne s'en occupe chez vous, vous êtes exposé sans le savoir.
C'est aussi une des raisons pour lesquelles nous construisons la plupart de nos sites vitrines sur une base statique (Astro). Un site généré en pages statiques n'interroge pas de base de données à chaque visite et n'exécute pas de code serveur côté public : cette catégorie précise d'attaque n'a tout simplement pas de surface où frapper. Ce n'est pas magique, c'est un choix d'architecture avec ses propres contreparties, et nous en parlons en détail dans notre comparatif WordPress ou site sur mesure. Pour les projets qui ont de bonnes raisons d'être sous WordPress, l'important est simplement que la maintenance soit tenue par quelqu'un.
FAQ
Comment savoir quelle version de WordPress j'utilise ?
Connectez-vous au tableau de bord d'administration : le numéro de version s'affiche en bas à droite de l'écran, et dans Outils puis Santé du site. Ne vous fiez pas au code source de la page publique, il peut être masqué. C'est le numéro exact qui détermine si vous êtes exposé.
La mise à jour automatique m'a-t-elle protégé ?
WordPress.org a forcé une mise à jour automatique sur une partie des installations supportées. Mais si vous aviez désactivé les mises à jour automatiques, si votre hébergeur les bloque, ou si vous tournez sur une version qui n'est plus maintenue, vous n'êtes pas couvert. Vérifiez le numéro à la main.
Bloquer l'endpoint suffit-il ?
Non. Bloquer l'accès à /wp-json/batch/v1 est une mesure temporaire, le temps de mettre à jour. Le seul correctif permanent est d'installer la version corrigée (6.8.6, 6.9.5 ou 7.0.2 selon votre branche).
Mon site est peut-être déjà piraté, que faire ?
Mettre à jour ne suffit pas si une porte dérobée est déjà installée : elle reste active après le correctif. Isolez le site, cherchez les comptes et extensions inconnus, restaurez une sauvegarde antérieure à l'intrusion, puis changez tous les mots de passe et les clés de sécurité. En cas de doute, faites appel à un professionnel.
Je n'ai pas de site WordPress, suis-je concerné ?
Non. Cette faille touche le cœur de WordPress (versions 6.8 à 7.0). Un site en Astro, Next.js ou Shopify n'est pas concerné par ces CVE. Chaque technologie a néanmoins ses propres correctifs à suivre.
On peut vérifier votre site à votre place
Si vous n'êtes pas sûr de votre version, de vos sauvegardes ou de l'état réel de votre site, on regarde pour vous : version, correctif appliqué, traces de compromission, et ce qu'il faut faire ensuite. Sans engagement.
Faire vérifier mon siteCet article s'appuie sur les publications officielles autour de la faille wp2shell (CVE-2026-63030 et CVE-2026-60137), corrigée dans WordPress 6.8.6, 6.9.5 et 7.0.2 :
