# WP2Shell : faille de sécurité WordPress critique dans la version 7.0, ce qui s’est passé et ce que vous devez faire maintenant > URL: https://4eck-media.de/fr/blog/wp2shell-faille-de-securite-wordpress-critique-dans-la-version-7-0-ce-qui-sest-passe-et-ce-que-vous-devez-faire-maintenant/ > Language: fr > Description: Il y a des moments sur le web où la différence entre « nous avons entendu dire qu’une mise à jour est disponible » et « nous avons réellement installé la mise à jour, vérifié son … --- Il y a des moments sur le web où la différence entre « nous avons entendu dire qu’une mise à jour est disponible » et « nous avons réellement installé la mise à jour, vérifié son application et contrôlé les journaux » décide de la réputation, du chiffre d’affaires et de la confiance. Juillet 2026 a été l’un de ces moments. WordPress alimente la majeure partie du web ouvert. Lorsqu’une vulnérabilité apparaît dans le cœur du système, et non dans une extension marginale, et qu’elle peut être exploitée sans connexion ni accès administrateur particulier, il ne s’agit pas d’alarmisme. Il s’agit de métier : comprendre, prioriser, corriger, prouver. ![Logo WordPress avec cadenas : symbole de la faille de sécurité WP2Shell et du renforcement du cœur de WordPress](https://4eck-media.de/wp-content/uploads/2026/08/4eck-security-wordpress.avif) *Faille de sécurité WordPress critique en juillet 2026 : WP2Shell (CVE-2026-60137 et CVE-2026-63030)* **La vulnérabilité WordPress connue sous le nom de WP2Shell est une chaîne d’attaque qui peut entraîner l’exécution de code malveillant sans authentification sur les versions concernées.** C’est précisément notre quotidien chez 4eck Media. Depuis 2010, nous concevons et exploitons des systèmes WordPress et WooCommerce avec la même exigence technique, des sites corporate multilingues aux architectures de boutiques et multisites les plus complexes. Et parce que nous exploitons nous-mêmes TutKit.com, une plateforme pouvant accueillir jusqu’à 20 000 utilisateurs par jour, nous connaissons la sécurité non pas par les brochures, mais par l’exploitation. Pour des exigences e-commerce comparables, notre [agence WooCommerce](https://4eck-media.de/fr/competences/faire-creer-une-boutique-woocommerce-avec-une-agence-woocommerce-specialisee/) met en place des processus robustes plutôt que des solutions d’extension à court terme. ## WP2Shell en bref : pourquoi la mise à jour de sécurité vers WordPress 7.0.2 est si importante Le 17 juillet 2026, l’équipe sécurité de WordPress a publié WordPress 7.0.2, une version de sécurité qui corrige *une vulnérabilité critique* et *une vulnérabilité élevée*. Des correctifs rétroportés ont été livrés en parallèle pour les branches concernées : - 7.0.x → mise à jour vers `7.0.2` - 6.9.x → mise à jour vers `6.9.5` - 6.8.x → mise à jour vers `6.8.6` (injection SQL) ![Faille de sécurité WP2Shell dans WordPress 7.0 : version de sécurité 7.0.2 et mesures immédiates en bref](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-wordpress-7-security-emergency.avif "WP2Shell et WordPress 7.0.2 : état de la sécurité en juillet 2026") La désignation publique de cette chaîne d’attaque est WP2Shell. Elle repose sur deux identifiants CVE qui sont nettement plus dangereux ensemble que séparément : - CVE-2026-60137 (élevée) : injection SQL facilitée ; une entrée spécialement conçue peut manipuler les requêtes de base de données. Affecte WordPress à partir de la version 6.8. Signalée notamment par TF1T, dtro et haongo. - CVE-2026-63030 (critique) : exécution de code à distance non authentifiée par confusion de routes dans le point de terminaison batch de l’API REST. Affecte WordPress à partir de la version 6.9. Signalée par Adam Kues (Assetnote / Searchlight Cyber). WordPress a jugé la situation suffisamment grave pour activer des mises à jour automatiques forcées pour les installations concernées. Ce n’est pas un avertissement de routine : c’est la ceinture de sécurité lors d’un freinage d’urgence. Pourtant, une mise à jour automatique ne signifie pas automatiquement « terminé ». Toute personne qui héberge sérieusement *vérifie*. WP2Shell : ce que vous devez faire maintenant - Installez au minimum WordPress 6.8.6, 6.9.5 ou 7.0.2. - Vérifiez la version réellement exécutée plutôt que de vous fier uniquement à la mise à jour automatique. - Contrôlez les administrateurs, extensions, fichiers du cœur, tâches cron et journaux à la recherche d’anomalies. - N’utilisez une WAF que comme couche de protection temporaire jusqu’au correctif. - En cas de soupçon, renouvelez tous les mots de passe, clés et sessions actives. Il est important de le comprendre d’emblée : aucun pirate ne vient sur votre site en se disant qu’il va peut-être essayer une attaque. Tout se déroule de façon automatisée, via des robots qui parcourent le web comme des moteurs de recherche et ciblent exactement les points accessibles. Ils créent alors de nouveaux administrateurs, changent les mots de passe des administrateurs existants, installent des extensions ou des logiciels malveillants, publient par milliers des pages de spam, par exemple de casino, etc. ## Comment fonctionne techniquement la faille de sécurité WP2Shell De nombreuses publications de sécurité se limitent à « critique, veuillez mettre à jour ». C’est insuffisant lorsqu’en tant que décideur ou responsable informatique, vous devez évaluer si votre site, votre boutique ou votre réseau multisite est réellement sécurisé. Regardons donc sous le capot. ### CVE-2026-60137 : injection SQL via WP_Query La première vulnérabilité concerne la manière dont WordPress traite les entrées dans certains paramètres de requête, notamment autour de `author__not_in` et de chemins `WP_Query` associés. Un attaquant peut façonner une entrée spécialement conçue de sorte que la requête SQL générée ne se contente plus de demander des données, mais soit manipulée. Une injection SQL dans le cœur d’un CMS est problématique pour deux raisons : d’une part, elle se situe profondément dans le traitement des requêtes et est donc largement accessible. D’autre part, elle constitue souvent la *clé* d’étapes ultérieures : extraction de données, manipulation de sessions ou, comme ici, préparation d’une exécution de code. ### CVE-2026-63030 : la confusion de routes du batch REST API mène à une exécution de code à distance La seconde faille concerne le point de terminaison batch de l’API REST (`/wp-json/batch/v1` ou le mécanisme batch correspondant). Une confusion de routes désynchronise méthode, validation et contrôle d’autorisation : une requête peut être « déguisée » pour contourner les vérifications et accéder en interne à des chemins qui ne devraient jamais être accessibles anonymement. Point décisif : dans le scénario décrit, l’exécution de code à distance critique ne nécessite aucune authentification. Pas de mot de passe administrateur volé. Pas de phishing. Pas de compte rédacteur compromis. Une courte séquence de requêtes HTTP non authentifiées, conçue avec habileté, peut entraîner l’exécution de code malveillant sur des systèmes vulnérables sans contre-mesures adaptées, notamment selon la configuration du cache d’objets. C’est précisément la combinaison de l’injection SQL et de la confusion de routes du batch qui fait de WP2Shell davantage qu’une « simple injection SQL ». Il s’agit d’une chaîne d’attaque qui peut fonctionner sur une installation standard : le cœur de WordPress, sans extensions exotiques et sans accès préalable. ![Chaîne d’attaque de la faille WP2Shell : d’une requête batch REST anonyme à l’injection SQL puis à l’exécution de code à distance](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-attack-chain-code-execution.avif "Comment fonctionne la chaîne d’attaque WP2Shell") ## Chaîne d’attaque WP2Shell : comment deux vulnérabilités peuvent prendre le contrôle de WordPress En pratique, les chercheurs en sécurité observent généralement deux schémas d’exploitation : 1. Accès initial : la chaîne d’attaque associe la confusion de routes du batch REST à l’injection SQL dans une courte séquence de requêtes non authentifiées. Il ne s’agit pas d’une unique « requête magique ». 2. Prise de contrôle et persistance : la chaîne décrite publiquement peut détourner temporairement des autorisations administratives, créer un nouvel administrateur puis téléverser une extension de porte dérobée. Des web shells, tâches cron manipulées ou autres mécanismes de persistance deviennent ensuite possibles. Après la publication et l’apparition de preuves de concept, la probabilité d’exploitation a nettement augmenté. Des universités, hébergeurs et entreprises de sécurité ont expressément averti qu’une exploitation à grande échelle était probable en raison de la faible complexité de l’attaque. Important pour les décideurs : une WAF (pare-feu d’application web) peut réduire la pression des attaques. Cloudflare et d’autres ont déployé des règles. **Une WAF ne remplace pas une mise à jour de sécurité WordPress.** Se limiter à la protection en périphérie tout en laissant le cœur ouvert revient à jouer avec son propre domaine. ## Versions WordPress concernées : qui doit passer à 7.0.2, 6.9.5 ou 6.8.6 Toutes les versions de WordPress ne sont pas touchées de la même manière. L’injection SQL concerne les versions à partir de 6.8, la chaîne complète d’exécution de code à distance les versions à partir de 6.9. Pour la branche 7.0, celle de nombreux projets récemment relancés, voici la situation : | Branche | Injection SQL (CVE-2026-60137) | Chaîne RCE (CVE-2026-63030) | Correctif | | --- | --- | --- | --- | | 6.8.0 – 6.8.5 | concernée | non | 6.8.6 | | 6.9.0 – 6.9.4 | concernée | concernée | 6.9.5 | | 7.0.0 – 7.0.1 | concernée | concernée | 7.0.2 | | < 6.8 | non concernée par cette chaîne* | à maintenir à jour malgré tout | | **WordPress 7.0.0 et 7.0.1 doivent être mis à jour au minimum vers WordPress 7.0.2.** ![Versions WordPress concernées et mises à jour sûres contre la faille de sécurité WP2Shell](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-affected-wordpress-versions.avif "Matrice des versions WP2Shell : WordPress 6.8.6, 6.9.5 et 7.0.2") *Les versions plus anciennes ne sont pas concernées par *cette* chaîne, mais cela ne les rend pas « sûres ». Les cœurs, extensions et piles PHP obsolètes constituent leur propre univers de risques. Notre [agence WordPress](https://4eck-media.de/fr/competences/agence-wordpress-des-sites-web-qui-travaillent-pour-votre-entreprise/) met en œuvre des exigences comparables sous forme de solutions évolutives, sûres et faciles à administrer au quotidien. ## Pourquoi aucun client de 4eck Media n’a été touché : maintenance WordPress plutôt que chance Soyons clairs : la chance n’est pas une stratégie. Si aucun de nos projets clients suivis n’a été compromis par WP2Shell, c’est grâce à un système, non au hasard. En pratique, ce système fonctionne ainsi : - Maintenance active du cœur et des extensions : les versions de sécurité sont priorisées, testées et installées, et non repoussées « à un prochain sprint ». - Vérification plutôt que supposition : nous contrôlons la version WordPress réellement exécutée dans le tableau de bord, dans le fichier `wp-includes/version.php` et via notre monitoring. Une mise à jour automatique seule ne nous suffit pas comme preuve. - Renforcement technique : en-têtes de sécurité, droits de fichiers restrictifs, séparation nette entre préproduction et production, protection ciblée des points de terminaison sensibles, journalisation et, lorsque cela est pertinent, couches WAF/CDN. - Expérience d’exploitation de notre propre plateforme : ce que nous recommandons à nos clients, nous l’exploitons nous-mêmes depuis 2002/2010 avec TutKit.com, PSD-Tutorials et des dizaines de projets d’agence. Chez nous, la sécurité n’est pas un audit PDF unique qui finit dans un tiroir. Elle fait partie de la conception, du développement, de la checklist de mise en ligne et de l’accompagnement continu. C’est pourquoi nous pouvons affirmer aujourd’hui que nos clients n’ont pas été touchés par cet incident. ## Exploiter WordPress en toute sécurité Ces articles montrent comment des logiciels à jour, des contrôles de sécurité systématiques, des sauvegardes fiables et une configuration rigoureuse réduisent de manière mesurable le risque lié aux vulnérabilités WordPress et aux pannes. [![Image de couverture de la checklist de lancement de site web avec presse-papiers, ballon de football et points de contrôle après la mise en ligne](https://4eck-media.de/wp-content/uploads/2026/07/website-launch-checkliste-nach-go-live-cover.avif "Checklist de lancement de site web : étapes importantes après la mise en ligne")](https://4eck-media.de/fr/blog/checklist-de-lancement-de-site-web-ce-qui-distingue-la-qualite-du-travail-bacle-apres-la-mise-en-ligne/ "Checklist de lancement de site web : ce qui distingue la qualité du travail bâclé après la mise en ligne") [Checklist de lancement de site web : ce qui distingue la qualité du travail bâclé après la mise en ligne](https://4eck-media.de/fr/blog/checklist-de-lancement-de-site-web-ce-qui-distingue-la-qualite-du-travail-bacle-apres-la-mise-en-ligne/) Matthias Petri [![Ordinateur portable affichant un contrôle de site web pour la performance, le SEO, la sécurité et l’accessibilité, ainsi que les logos des dix outils de test](https://4eck-media.de/wp-content/uploads/2026/07/website-pruefen-die-10-tools-mit-denen-wir-jede-website-testen-vor-und-nach-dem-go-live.avif "Vérifier un site web : 10 outils avant et après la mise en ligne")](https://4eck-media.de/fr/blog/verifier-un-site-web-les-10-outils-avec-lesquels-nous-testons-chaque-site-avant-et-apres-la-mise-en-ligne/ "Vérifier un site web : les 10 outils avec lesquels nous testons chaque site, avant et après la mise en ligne") [Vérifier un site web : les 10 outils avec lesquels nous testons chaque site, avant et après la mise en ligne](https://4eck-media.de/fr/blog/verifier-un-site-web-les-10-outils-avec-lesquels-nous-testons-chaque-site-avant-et-apres-la-mise-en-ligne/) Matthias Petri [![Image de titre de la checklist de site web avant le go-live avec les domaines de contrôle technique, contenus, mobile, performance et qualité](https://4eck-media.de/wp-content/uploads/2026/07/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif "Checklist de site web avant le go-live : la qualité plutôt que le bricolage")](https://4eck-media.de/fr/blog/checklist-de-site-web-avant-le-go-live-ce-que-nous-verifions-avant-quun-site-puisse-etre-mis-en-ligne/ "Checklist de site web avant le go-live : ce que nous vérifions avant qu’un site puisse être mis en ligne") [Checklist de site web avant le go-live : ce que nous vérifions avant qu’un site puisse être mis en ligne](https://4eck-media.de/fr/blog/checklist-de-site-web-avant-le-go-live-ce-que-nous-verifions-avant-quun-site-puisse-etre-mis-en-ligne/) Matthias Petri [![JavaScript SEO : les défis pour les développeurs web et les SEO managers](https://4eck-media.de/wp-content/uploads/2025/10/javascript-seo-herausforderungen-720x480.avif "JavaScript SEO : les défis pour les développeurs web et les SEO managers")](https://4eck-media.de/fr/blog/javascript-seo-les-defis-pour-les-developpeurs-web-et-les-seo-managers/ "JavaScript SEO : les défis pour les développeurs web et les SEO managers") [JavaScript SEO : les défis pour les développeurs web et les SEO managers](https://4eck-media.de/fr/blog/javascript-seo-les-defis-pour-les-developpeurs-web-et-les-seo-managers/) Matthias Petri ## Corriger la faille de sécurité WordPress : les six étapes indispensables maintenant Que vous assuriez vous-même l’hébergement, travailliez avec un freelance ou une agence : l’ordre suivant est celui qui fonctionne dans la réponse aux incidents et dans une maintenance rigoureuse. ### Étape 1 : vérifier de manière fiable la version de WordPress Connectez-vous au back-office WordPress et vérifiez la version dans *Tableau de bord → Mises à jour* ou en bas du pied de page de l’administration. En complément : - Fichier `wp-includes/version.php`, champ `$wp_version` - Panneau d’hébergement / WP-CLI : `wp core version` - Utiliser les vérificateurs externes uniquement comme indice, jamais comme seule source de vérité Versions cibles : 7.0.2+, 6.9.5+ ou 6.8.6+ selon la branche. Toute version inférieure reste exposée. ### Étape 2 : installer la mise à jour de sécurité WordPress de manière contrôlée Dans l’idéal : préproduction → test de bon fonctionnement (connexion, paiement, formulaires, flux personnalisés critiques) → production → nouvelle vérification de la version. S’il n’existe pas de préproduction et que la faille est critique : corrigez en production puis testez intensivement. Pour les vulnérabilités de sécurité critiques, « nous attendons le prochain sprint de contenu » est l’option la plus coûteuse. ### Étape 3 : mesures de protection temporaires jusqu’au correctif - Bloquer le point de terminaison REST batch au niveau du proxy inverse / de la WAF (`/wp-json/batch` et ses variantes) - Restreindre les accès anonymes à l’API REST là où l’activité le permet - Maintenir actives les règles gérées du CDN/de la WAF - Après le correctif, assouplir à nouveau les mesures afin que les intégrations légitimes (headless, applications mobiles, automatisations) ne soient pas interrompues ### Étape 4 : vérifier si WordPress a été compromis L’application réussie d’un correctif ne répare pas automatiquement une compromission déjà survenue. Vérifiez notamment : - Comptes administrateur inconnus et rôles modifiés - Nouvelles extensions inconnues, extensions must-use et drop-ins - Fichiers du cœur modifiés (contrôle d’intégrité / fichiers du cœur récents) - Tâches cron suspectes, redirections, `.htaccess`, fichiers PHP dans les répertoires d’importation - Journaux d’accès autour de la période de divulgation (API batch, charge POST inhabituelle) ![Six étapes après WP2Shell : vérifier la version WordPress, corriger, analyser, isoler, restaurer et surveiller](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-incident-response-checklist.avif "Checklist de réponse à incident WP2Shell") En présence d’indicateurs de compromission concrets : isolez, préservez les éléments utiles à l’analyse forensique et rétablissez proprement à partir d’une sauvegarde fiable, avec correctif et renouvellement des mots de passe, plutôt que de « supprimer quelque chose et espérer ». ### Étape 5 : renouveler mots de passe, clés et sessions Mots de passe des administrateurs et éditeurs, mots de passe d’application, FTP/SFTP, hébergement, base de données, secrets CI/CD, SMTP, clés de paiement et d’API. Invalidez les sessions. Imposez la double authentification lorsque c’est possible. ### Étape 6 : mettre durablement en place le monitoring et la maintenance WordPress Le meilleur moment pour conclure un contrat de maintenance était avant l’incident. Le deuxième meilleur moment est maintenant. Les contrôles de disponibilité ne constituent pas à eux seuls un programme de sécurité. Il vous faut une politique de mise à jour, une stratégie de sauvegarde avec test de restauration, de la journalisation, des alertes et une personne qui sait quoi faire à 9 h 12 après une version d’urgence. ## Renforcer WordPress : comment garder le prochain incident de sécurité sous contrôle WP2Shell est un incident du cœur. La prochaine faille critique peut se trouver dans une extension, un thème, la pile serveur ou une copie de préproduction mal configurée et publiquement indexable. C’est pourquoi 4eck Media applique un standard minimum de renforcement : - Moindre privilège : aussi peu de comptes administrateur que possible, rôles séparés, aucun mot de passe partagé. - Hygiène des extensions : uniquement celles qui sont nécessaires, activement maintenues et régulièrement auditées. Toute extension abandonnée constitue une surface d’attaque. - En-têtes de sécurité et transport : HSTS, CSP lorsque c’est possible, attributs de cookie sécurisés, TLS uniquement. - Des sauvegardes réellement restaurables : versionnées, hors site et testées en restauration, et non pas seulement « quelque part dans le panneau d’hébergement ». - Préproduction ≠ production sur le réseau : authentification, robots, identifiants séparés, aucune copie contenant de vraies données clients sans protection. - Penser ensemble performance et sécurité : PageSpeed et les Core Web Vitals ne s’opposent pas au renforcement ; les cimetières d’extensions gonflés nuisent aux deux. ![Concept de sécurité WordPress avec renforcement, authentification à deux facteurs, WAF, sauvegardes et monitoring centralisé](https://4eck-media.de/wp-content/uploads/2026/08/wordpress-security-baseline-hardening.avif "Renforcer durablement WordPress contre les failles de sécurité critiques") ## Vous suspectez WP2Shell ? Faites vérifier, nettoyer et sécuriser WordPress Toutes les entreprises ne disposent pas d’une équipe sécurité interne. Et tout « accompagnement WordPress » ne vérifie pas réellement la version après une version d’urgence. Si vous ne savez pas si votre installation utilisait 7.0.0 / 7.0.1 ou une autre version vulnérable, si la mise à jour automatique est désactivée, si les journaux semblent inhabituels ou si le back-office vous paraît « différent », le moment est venu de recourir à une aide professionnelle, pas à l’espoir. 4eck Media accompagne les entreprises précisément dans ces situations : - Contrôle immédiat : version, état du correctif et indicateurs évidents de compromission - Installation contrôlée des versions de sécurité, avec tests de bon fonctionnement - Première évaluation forensique et restauration nettoyée en cas d’incident - Renforcement, harmonisation WAF/CDN, procédures de sauvegarde et de mise à jour - Maintenance continue pour WordPress, WooCommerce, Multisite et configurations multilingues Nous sommes l’agence technique de Waren (Müritz), spécialisée dans le développement WordPress professionnel, WooCommerce, PageSpeed, l’accessibilité, le SEO et le GEO. Plus de 350 projets clients depuis 2010. Et en matière de sécurité, nous appliquons le même critère qu’en matière de performance : mesurable, vérifiable, exploité, pas simplement affirmé. Nos propres clients n’ont pas été touchés par WP2Shell. Si vous l’avez été, ou si vous avez besoin de la preuve que ce n’est pas votre cas, contactez-nous. Nous corrigeons la faille, remettons l’installation en état et organisons l’exploitation afin que le prochain vendredi de sécurité ne devienne pas une urgence pour vous. *Sources et avertissement : cet article s’appuie notamment sur la version de sécurité officielle WordPress 7.0.2 (17/07/2026), les avis relatifs à CVE-2026-60137 et CVE-2026-63030 (WP2Shell), des analyses de Searchlight Cyber / Assetnote, Cloudflare et Rapid7, ainsi que des alertes de sécurité universitaires et d’hébergeurs. Cet article ne remplace pas une analyse forensique individuelle. En cas d’incident concret : isolez le système et faites appel à des spécialistes.* ## Questions fréquentes sur la faille de sécurité WP2Shell Qu’est-ce que WP2Shell ? WP2Shell est le nom d’une chaîne d’attaque critique dans le cœur de WordPress. Elle associe CVE-2026-60137 (injection SQL) et CVE-2026-63030 (confusion de routes du batch REST API), de sorte que du code malveillant peut être exécuté sans authentification sur des installations vulnérables. Quelles versions de WordPress sont concernées par WP2Shell ? La chaîne complète concerne WordPress 6.9.0 à 6.9.4 ainsi que 7.0.0 à 7.0.1. WordPress 6.8.0 à 6.8.5 est concerné par l’injection SQL, mais pas par la chaîne RCE complète. WordPress 7.1 Beta 1 était également concerné. Quelles mises à jour WordPress corrigent la faille de sécurité ? Selon la branche, installez au minimum WordPress 6.8.6, 6.9.5 ou 7.0.2. Pour la branche de test 7.1, Beta 2 ou une version ultérieure est nécessaire. Vérifiez ensuite activement dans le back-office et via WP-CLI que la version cible est réellement exécutée. WP2Shell peut-il être exploité sans connexion ou extension non sécurisée ? Oui. WP2Shell concerne le cœur de WordPress et ne nécessite ni extension spécifique ni compte préalablement volé. Même des installations standard apparemment légères peuvent donc être menacées. Une mise à jour WordPress automatique suffit-elle ? Non. Les mises à jour automatiques peuvent échouer ou ne pas s’appliquer à certaines instances. Vérifiez la version dans le tableau de bord et avec wp core version. En outre, un correctif actuel ne prouve pas que le site n’a pas déjà été compromis avant la mise à jour. Un pare-feu d’application web protège-t-il totalement contre WP2Shell ? Non. Une WAF peut temporairement bloquer des schémas d’attaque connus et réduire la pression des attaques, mais elle ne remplace ni la mise à jour de sécurité WordPress ni le contrôle ultérieur d’une éventuelle compromission. Comment reconnaître une éventuelle compromission WordPress ? Vérifiez les administrateurs inconnus, les nouvelles extensions et extensions MU, les fichiers du cœur modifiés, les fichiers PHP dans les répertoires d’importation, les tâches cron suspectes, les redirections, l’activité REST et wp-login ainsi que les connexions sortantes inhabituelles. Que faire si mon site WordPress a été compromis ? Isolez le système, sauvegardez les journaux et éléments de preuve, puis restaurez le site depuis une sauvegarde fiable ou reconstruisez-le proprement. Installez les mises à jour de sécurité, renouvelez mots de passe, clés et sessions et surveillez étroitement l’instance assainie.