Dans les coulisses d'un wp2shell : WordPress – Compromission et restauration

Deux sites d'WordPress , hébergés sur des comptes InMotion Hosting , ont été compromis en l'espace de deux heures en juillet 2026. L'un d'eux a été nettoyé quatre jours plus tard, puis réinfecté six jours après. Voici ce que nos équipes ont découvert: les couches de persistance mises en place par les attaquants après leur accès initial, les indicateurs spécifiques que tu peux vérifier dès aujourd'hui sur tes propres sites, et pourquoi la suppression des comptes d'administrateur malveillants ne met pas fin à la compromission.

La plupart des articles sur wp2shell se sont arrêtés à la porte d'entrée. C'est cette chaîne qui permet à un pirate de s'introduire. Ce qui compte vraiment pour tout responsable d'un site WordPress , c'est ce qui se passe dans les minutes et les jours qui suivent, et cette partie a été bien moins documentée.

Nos équipes ont enquêté sur deux incidents distincts touchant des clients début août 2026. Les deux sites ont été remis en état et sont de nouveau opérationnels. Les noms de comptes, domaines, identifiants de serveurs et chemins d'accès aux répertoires ont été supprimés ici. En revanche, les détails relatifs au comportement n'ont pas été supprimés, car ce sont justement ces éléments qui aident les autres propriétaires de sites à repérer le même problème sur leurs propres installations.

C'est la chaîne d'exploitation qui est le point d'entrée, pas l'incident

wp2shell fait référence à une chaîne de vulnérabilités du cœur d'WordPress CVE-2026-63030 et CVE-2026-60137, qui, combinées, permettent à un attaquant non authentifié d'exécuter du code à distance sur une installation standard d'WordPress . La première faille est un problème de confusion de route dans le point de terminaison REST batch. La seconde est une injection SQL dans WP_Query. Enchaînées, elles permettent à une requête HTTP anonyme de se terminer par un compte administrateur créé par un pirate, sans plugin, sans identifiants et sans intervention de ta part.

Les limites de version sont importantes pour le triage. L'analyse technique de Patchstack sur les notes de mise à jour indique que la faille d'injection SQL remonte à la version 6.8 d'WordPress , tandis que la confusion au niveau du gestionnaire de lots, qui transforme cette faille en une attaque non authentifiée et accessible à distance, n'a été introduite qu'à partir de la version 6.9. Un site sur la branche 6.8 présente bien la faille d'injection, mais on ne peut pas arriver à une exécution complète de code à distance par cette voie.

WordPress Les versions d'urgence 6.9.5, 7.0.2 et 6.8.6 ont été publiées le 17 juillet 2026 et les mises à jour automatiques forcées ont été activées. La CISA a ajouté cette vulnérabilité à son catalogue des vulnérabilités connues exploitées le 21 juillet. Des cas d'exploitation ont été signalés quelques heures seulement après la divulgation, et des dizaines de preuves de concept fonctionnelles ont circulé en l'espace de quelques jours.

Les deux sites qu’on a examinés ont été attaqués dans les 48 heures qui ont suivi l’application du correctif, depuis des réseaux sans lien entre eux, à environ deux heures d’intervalle. Cet écart mérite d’être souligné. Personne ne ciblait ces entreprises. Il s’agissait simplement d’un trafic de scan qui repérait tout ce qui n’avait pas encore été corrigé.

Aucune des deux enquêtes n’a pu prouver de manière concluante quelle faille d’autorisation exacte avait été exploitée lors de la première requête. Cette limite est structurelle plutôt que locale. Les fichiers journaux d’accès standard d’Apache et d’ NGINX enregistrent la ligne de requête, le code d’état et l’User-Agent, et aucun format de journal largement utilisé ne conserve le corps des requêtes, les en-têtes de cookies, les en-têtes d’autorisation ou les nonces REST. Or, ce sont précisément ces champs qui permettraient d’identifier le mécanisme, et ils ne sont conservés par aucun serveur utilisant une pile de journalisation classique.

Ce que les journaux ont conservé, et ce que nos équipes ont pu reconstituer à partir de ceux-ci, c'est la séquence des événements. Dans les deux cas, une rafale de requêtes POST a été envoyée vers la route REST « batch » de WordPress et a renvoyé un code HTTP 207, suivie en quelques secondes par la création d'un compte administrateur. Sur un site, les requêtes comportaient une chaîne User-Agent correspondant au nom publié de la chaîne d’exploits. Sur ce même site, aucun événement de connexion réussi n’a été enregistré pour le compte administrateur d’origine au moment où des actions ont été effectuées en son nom, ce qui correspond davantage à une exploitation sans authentification qu’à un mot de passe volé.

Les éléments de preuve concordent avec wp2shell. Ça ne suffit pas pour établir une attribution définitive, et on ne va pas s'avancer là-dessus. Affirmer qu'un CVE précis a causé une compromission spécifique, sans éléments de preuve au niveau des requêtes pour l'étayer, c'est comme ça que des causes profondes erronées finissent dans les rapports et que des mesures correctives inadaptées deviennent prioritaires.

La première charge utile s'est posée en moins d'une demi-minute

Sur le premier site, la séquence, reconstituée à partir des journaux d'accès et des enregistrements d'activité d'WordPress , s'est déroulée comme suit :

1. Une requête a été envoyée à la route REST « batch » et a renvoyé un code HTTP 207.
2. Deux secondes plus tard, une action a été enregistrée sous le compte administrateur d'origine du site, depuis l'adresse IP de l'attaquant, modifiant une entrée de publication interne inhabituelle.
3. Une seconde plus tard, ce même contexte a créé un nouveau compte administrateur dont le nom était conçu pour ressembler à celui d'un compte de service.
4. Huit secondes plus tard, le nouveau compte s'est connecté avec succès.
5. Onze secondes plus tard, il a téléchargé un fichier ZIP de plugin.
6. Trois secondes plus tard, le plugin était installé et activé.
7. Une seconde plus tard, l'attaquant a supprimé le fichier ZIP de la bibliothèque multimédia.

Du début à la fin, ça a pris environ 24 secondes. Le deuxième site a suivi le même schéma et a effectué la même séquence en environ 28 secondes.

Le plugin apparaissait dans le tableau de bord d'WordPress comme un utilitaire de sécurité avec un nom et un numéro de version qui semblaient crédibles. Le nom de son répertoire ressemblait à celui d'un plugin de performances légitime, avec un suffixe hexadécimal aléatoire ajouté à la fin. N'importe qui qui aurait parcouru rapidement la liste des plugins l'aurait ignoré.

Treize secondes après l'installation, le pirate a demandé directement le fichier PHP principal du plugin et l'a exécuté id && uname -a && hostname && pwd. Ça a renvoyé un code HTTP 200. À partir de là, le pirate a pu exécuter des commandes shell en tant qu'utilisateur du compte cPanel .

L'enquête met au jour la campagne du pirate informatique

Ce que l'attaquant a vérifié ensuite en dit plus long sur ses intentions que n'importe quel logiciel malveillant. C'est en lisant ces commandes dans l'ordre que notre équipe a pu déterminer l'objectif de cette campagne. En succession rapide, le webshell a été utilisé pour tester :

• L'emplacement et le type du binaire « sendmail » du système
• Que ce soit PHP’s mail() la fonction était disponible
• Que proc_open() était disponible
• Le contenu de la liste des fonctions désactivées de PHP
• Est-ce que le SMTP sortant sur le port 25 était accessible ?
• Résolution des enregistrements DNS et MX
• Que l'environnement de messagerie se comporte comme une configuration « trap », « discard » ou « blackhole »

C'est cette dernière vérification qui est intéressante. L'attaquant testait précisément si les e-mails sortants seraient bel et bien délivrés ou s'ils seraient discrètement bloqués par l'hébergeur. C'est de la reconnaissance pour mettre en place une infrastructure de spam. On n'a pas pu confirmer de campagne sortante réussie d'après les preuves qu'on a examinées, mais l'intention est claire.

Le deuxième site prenait une autre direction. Il hébergeait des chargeurs de cloaking SEO qui proposaient du contenu différent selon l'User-Agent, le référent, la langue, l'adresse IP, l'hôte et l'URI de la requête, avec la possibilité de réécrire robots.txt. C'est ce qu'on appelle l'« empoisonnement des résultats de recherche », qui est une méthode de monétisation distincte du relais de spam. Les sites WordPress piratés sont souvent détournés pour les redirections, les scripts injectés et la collecte d'identifiants visant les visiteurs, et pas seulement pour ce que l'attaquant veut récupérer sur le serveur lui-même.

La persistance a été conçue en neuf couches indépendantes

Quatre-vingt-dix secondes après avoir pris le contrôle de l'exécution des commandes, le pirate du premier site a créé une tâche cron qui s'exécutait toutes les cinq minutes. Son but était de restaurer un fichier de plugin malveillant à partir d'une copie de sauvegarde stockée dans le répertoire « uploads » si le fichier d'origine venait à disparaître.

C'était la première couche sur les neuf. Voici l'ensemble complet, retrouvé au cours de l'enquête :

• Des comptes administrateur créés par l'attaquant, plusieurs d'entre eux, à partir de différentes adresses IP au cours des jours suivants
• Des plugins standard malveillants, trois répertoires supplémentaires en plus de ceux d'origine, chacun contenant des webshells fonctionnels
• Un plugin incontournable, « Guardian », qui permet de récupérer des fichiers supprimés et qui ne peut pas être désactivé depuis le tableau de bord d'WordPress
• PHP copie dans le dossier « under » wp-content/uploads, dont les noms sont inspirés de ceux des fichiers de classes principales d'WordPress
• Des charges utiles encodées dans la table des options, stockées sous des noms qui imitent les variables temporaires légitimes de surveillance de l'état du site
• Blocs de chargement injectés dans wp-config.php, qui lisait ces options de base de données, décodait le code PHP stocké et enregistrait les fichiers exécutables sur le disque
• Des fichiers exécutables dans le répertoire temporaire CageFS du compte, au nombre de cinq
• Des tâches cron supplémentaires: cinq entrées distinctes de 30 minutes chacune pour effectuer des autotests et des vérifications de restauration
• Logique permettant de recréer le compte administrateur préféré de l'attaquant et de détruire les jetons de session des autres utilisateurs

Relis cette liste en pensant au nettoyage. Si tu supprimes le plugin, la tâche cron reste. Si tu supprimes la tâche cron, les données de la base restent. Si tu supprimes les données de la base, il reste le wp-config.php un programme de chargement qui le recréerait. Si tu supprimes le compte administrateur, le webshell qui l'a créé reste en place.

Seules deux de ces neuf couches se trouvent dans des endroits où un antivirus classique va chercher. Pour trouver les autres, il a fallu analyser la logique de la charge utile décodée et la recouper avec le crontab et la table des options.

Le deuxième site a ajouté une variante qu'il faut connaître : un plugin incontournable, déguisé en composant de limitation des connexions, qui s'est accroché à wp_authenticate, récupérait le nom d'utilisateur et le mot de passe en clair à chaque tentative de connexion, déterminait son adresse de destination via un smart contract de la blockchain plutôt que via un domaine codé en dur, et transmettait ces identifiants à un point de terminaison distant. Il se retirait également de la liste des plugins obligatoires pour ne pas apparaître dans le tableau de bord.

Tous les mots de passe saisis dans ce formulaire de connexion pendant que le fichier était actif ont été compromis. Pas hachés. Pas devinés. Lues en clair.

Les six jours entre la guérison et la réinfection

Le 20 juillet, une activité provenant d'une autre adresse IP a supprimé tous les comptes administrateur créés par les pirates sur le premier site. Les quatre. Le noyau d'WordPress a été mis à jour avec une version corrigée le jour même.

On dirait que le nettoyage a bien marché. Les comptes pirates ont disparu, la faille de sécurité a été corrigée et le site fonctionne à nouveau normalement.

Le webshell d'origine n'a jamais été supprimé.

Le 26 juillet, une adresse IP qui n’était jamais apparue auparavant a demandé ce fichier de plugin qui existait encore. L’attaquant s’en est servi pour écrire un script PHP temporaire qui a chargé l’environnement WordPress , repéré le webshell existant, l’a copié dans le répertoire « uploads », a créé un plugin « guardian » indispensable, a vérifié si le compte administrateur préféré de l’attaquant existait toujours, l’a recréé, a détruit les jetons de session des autres utilisateurs, puis s’est supprimé tout seul.

WordPress Le résultat a été enregistré comme une inscription d'un nouvel utilisateur. Ce n'était pas une inscription. C'était PHP qui tournait avec tous les privilèges de l'application, et qui faisait exactement ce que le code du site lui-même est autorisé à faire.

Le site a été entièrement remis en état. La mise à jour de Core effectuée le 20 juillet a comblé la faille que l'attaquant avait exploitée le 18 juillet, mais qu'il avait d'ailleurs déjà cessé d'utiliser à ce moment-là.

Les sauvegardes avaient déjà été compromises

La restauration à partir d'une sauvegarde, c'est la réaction instinctive qu'on a quand on se fait pirater. Les deux enquêtes ont montré que cette réaction aurait été un échec.

Un compte contenait un fichier de porte dérobée qui provenait d’un ancien hébergeur. Il se trouvait dans une sauvegarde de migration importée dans le compte, avec des horodatages de modification datant d’août 2025, ainsi que dans une deuxième copie au niveau du compte datant d’octobre 2025. Ce logiciel malveillant est antérieur d’environ onze mois à l’historique du compte sur notre infrastructure, et il a été découvert parce que l’enquête a porté sur les arborescences de sauvegardes importées plutôt que sur la seule racine des documents en ligne.

Les éléments dont on dispose ne permettent pas de prouver que la campagne de juillet 2026 ait réutilisé cet ancien point d'ancrage, et on n'a pas supposé que c'était le cas. Ce qu'ils établissent, en revanche, c'est que l'archive de sauvegarde n'était pas propre, et qu'elle ne l'était déjà plus avant même que le site ne soit mis en ligne.

Les données de restauration du plugin de maintenance de ce même compte contenaient un répertoire de plugin au nom aléatoire qui renfermait du code datant de la période de l'attaque. Ces données de restauration ne pouvaient pas servir de source de restauration propre. C'est en vérifiant l'arborescence de restauration, plutôt qu'en s'y fiant aveuglément, qu'on a pu repérer ça.

Les points de restauration enregistrent tout ce qui se trouvait sur le site à ce moment-là, y compris ce qui s'y cachait déjà. Restaurer le site à une date antérieure à la compromission avérée revient à deviner quand celle-ci a commencé, et dans ces deux cas précis, cette supposition aurait été erronée.

Les mises à jour automatiques n'ont pas été installées sur l'un de ces sites

WordPress.org a imposé des mises à jour automatiques pour cette version, une mesure réservée aux failles les plus graves. 28 heures plus tard, le premier site tournait toujours sur une version vulnérable.

Pendant l'intervention, notre équipe a repéré un plugin de gestion des mises à jour configuré pour bloquer les mises à jour du cœur, des plugins et des thèmes, et l'a désactivé. Cette configuration pourrait expliquer pourquoi la mise à jour d'urgence n'a pas été installée, même si les journaux de mise à jour n'étaient pas assez clairs pour l'affirmer avec certitude.

Pour les agences, c’est là la conclusion la plus utile sur le plan opérationnel de toute cette enquête. Le blocage des mises à jour est un choix normal et justifiable sur un site où une version de Core a déjà perturbé le processus de paiement. C’est aussi une décision qui exclut discrètement le site des mises à jour de sécurité d’urgence, et personne ne revient jamais là-dessus. Si ta pile de maintenance comprend un gestionnaire de mises à jour, quelqu’un doit se charger de déterminer ce qui se passe quand WordPress publie une mise à jour de sécurité obligatoire.

Comment vérifier si tes propres sites présentent ces indicateurs

Les chemins indiqués ci-dessous sont relatifs à la racine de tes documents WordPress . Aucun d'entre eux ne nécessite d'accès au serveur au-delà de ce qu'offre un compte cPanel ou SFTP standard. Les noms de fichiers des campagnes changent régulièrement ; considère donc ces modèles comme plus permanents que n'importe quel nom de fichier spécifique.

Noms des répertoires de plugins et de thèmes

Ces deux comptes comportaient des répertoires respectant ces conventions de nommage sous wp-content/plugins:

Motif	À quoi ça ressemble ?
wp2shell_*	8 caractères hexadécimaux ajoutés, correspondant au nom public de la chaîne d'exploitation
wp2up_*, nx_up_*, h2ok_up_*	Outils d'envoi de fichiers autonomes, 8 caractères hexadécimaux ajoutés à la fin
galex_*	Ensembles de webshells, avec 8 caractères hexadécimaux ajoutés à la fin
Un nom plausible suivi d'un suffixe hexadécimal	Un slug de plugin qui a l'air légitime, avec une chaîne hexadécimale aléatoire à la fin

C'est ce dernier stratagème-là qui arrive à passer inaperçu lors d'un examen rapide. Un plugin malveillant utilisait un slug ressemblant à celui d'un outil de diffusion de contenu et s'affichait dans le tableau de bord sous le nom de « Security Headers Manager 2.1.4 », avec un numéro de version. Des répertoires de thèmes aux noms aléatoires étaient utilisés de la même manière.

Les plugins incontournables

Fichiers dans wp-content/mu-plugins Ils n'apparaissent pas dans la liste habituelle des plugins et ne peuvent pas être désactivés depuis le tableau de bord. Parmi les fichiers malveillants détectés, on trouvait un voleur d'identifiants dont le nom imitait celui d'un composant de limitation des connexions, un « Recovery Guardian » dont le nom imitait celui d'un utilitaire de réparation de site, ainsi que deux petits fichiers PHP qui chargeaient une charge utile compressée depuis un fichier associé .gz archives.

Ouvre ce répertoire et passe en revue tous les fichiers qu'il contient, un par un. Sur la plupart des sites, la liste devrait être courte, voire vide.

Des fichiers déguisés en classes principales d'WordPress

Les fichiers d'aide ont été enregistrés dans les répertoires des plugins en utilisant des noms inspirés des conventions du noyau :

• class-wp-rest-compat-*.php
• class-wp-http-compat-*.php
• class-wp-cache-helper-*.php
• class-wp-widget-core-*.php

Les chargeurs cachés utilisaient un point en tête, suivi de douze caractères hexadécimaux et d'un .php extension. Les fichiers correspondant à ces modèles ne font pas partie de WordPress et n'ont rien à faire dans un répertoire de plugins. Un polyglotte JPEG et PHP nommé 1.php était aussi présent sur un compte, avec une porte dérobée plus ancienne appelée wp-mytrack.php qui crée un compte administrateur quand tu le lances.

Indicateurs de base de données

Des charges utiles malveillantes étaient stockées dans la table des options sous des noms conçus pour se glisser à côté des entrées légitimes concernant l'état de santé du site, en utilisant le préfixe _site_transient_health_ suivi de 8 caractères hexadécimaux. Le préfixe de ta table sera différent de celui par défaut. Le plugin « WordPress » crée de véritables variables temporaires liées à la santé du site ; tu dois donc effectuer la correspondance sur la chaîne hexadécimale finale plutôt que sur le préfixe seul.

Indicateurs de configuration

Blocs intitulés WP_Core_Integrity ont été injectés dans wp-config.php. Leur rôle était de lire les données de la base de données ci-dessus, de les décoder, puis d'écrire du code PHP exécutable dans le répertoire temporaire du compte. Ouvrir wp-config.php et lis-le d'un bout à l'autre. Tout ce qui se trouve après le commentaire « fin de modification » mérite ton attention.

Parmi les chaînes de code récurrentes observées dans les charges utiles, on trouvait notamment _nx_auth, _NX_PERSISTEDet feature=selftest.

Données utiles dans les répertoires temporaires

Cinq charges utiles exécutables ont été trouvées dans le répertoire temporaire d'un compte, en respectant la convention de nommage des fichiers temporaires propre à PHP : les caractères php suivi de six caractères alphanumériques choisis au hasard. C'est exactement le même modèle que PHP utilise pour les téléchargements de fichiers normaux, et c'est justement pour ça qu'il passait inaperçu. Normalement, les fichiers temporaires de téléchargement sont supprimés à la fin de la requête. Tout fichier correspondant à ce modèle et qui est resté là pendant des jours mérite qu'on s'y attarde.

Entrées Cron

Vérifie le crontab du compte, pas seulement celui d'WordPress . Un compte comportait une tâche de cinq minutes qui restaurait un fichier de plugin supprimé à partir d'une copie de sauvegarde dans le dossier « uploads », ainsi que cinq tâches distinctes de trente minutes chacune effectuant des autotests. Une entrée légitime dans le crontab d'WordPress appelle wp-cron.php et rien d'autre. Toute autre utilisation récurrente de PHP ou de curl sur ton propre site doit être prise en compte.

Comptes utilisateurs et jetons

• Des identifiants d'administrateur consécutifs. Un compte comptait 38 administrateurs non autorisés dans une série ininterrompue d'identifiants utilisateur. La création consécutive est un indice structurel.
• Modèles de noms d'utilisateur. Parmi les préfixes observés, on trouve wpsvc_ et wp2_ suivis d'un code hexadécimal, ainsi que des comptes créés à partir du nom du site avec des suffixes tels que _dev, _editoret _suporte.
• Mots de passe des applications. Clique sur « Utilisateurs », puis sur chaque profil, puis sur « Mots de passe d'application ». Les jetons créés par les pirates portaient des noms tels que auto-bootstrap et bot-token. Ces identifiants restent valables même après un changement de mot de passe et ne nécessitent pas de passer par le formulaire de connexion.

Signatures de journal

Dans les fichiers journaux d'accès, cherche les requêtes POST vers /?rest_route=/batch/v1 ou /wp-json/batch/v1 renvoyant un code HTTP 207, surtout par rafales. Sur un compte, les requêtes comportaient les chaînes « User-Agent » wp2shell et wp2shell-uploader. La création d'un compte administrateur quelques secondes après une telle vague d'activité, c'est ça qu'il faut surveiller.

Les deux comptes ont suivi le même schéma : une série rapide de requêtes groupées, puis une requête pour wp-login.php, puis une connexion réussie, puis un téléchargement de plugin via update.php avec le action=upload-plugin paramètre. Ce téléchargement est une action normale de l'administrateur d'WordPress , et en soi, ça n'a rien d'anormal. Ce qui est inhabituel, c'est que ça se passe juste après une rafale de requêtes groupées provenant de la même adresse IP.

Note que les chaînes « User-Agent » sont modifiées de manière insignifiante et que les variantes ultérieures pourraient ne plus les utiliser. Les requêtes de route par lots renvoyant un code HTTP 207 constituent un indicateur plus fiable. Si ton hébergeur efface ou compresse les journaux d'accès à intervalles réguliers, récupère les journaux archivés couvrant la période de mi-juillet à fin juillet 2026 avant qu'ils ne soient supprimés.

Vérification de la réponse du serveur pour les téléchargements

Demande un fichier PHP sous wp-content/uploads directement, en contournant le cache, et vérifie la réponse. Le code HTTP 403 est correct. Le code HTTP 200 a été renvoyé avec content-type: application/octet-stream ça veut dire que le fichier est servi en tant que source lisible plutôt qu'en tant que code à exécuter.

Le mode « Serving » est le plus sûr des deux modes de défaillance, puisque le code ne s'exécute pas, mais il expose tout de même le contenu de ce fichier à quiconque demande l'URL. Les deux comptes avaient besoin d'une règle de refus explicite couvrant les extensions exécutables dans le dossier « uploads », et les deux en ont reçu une. On a identifié ce problème en effectuant des tests depuis l'extérieur du serveur avec des requêtes sans cache, en utilisant un User-Agent de navigateur normal, Googlebot et d'autres, car certaines configurations réagissent différemment selon le client. Si on avait testé avec un seul navigateur, on l'aurait manqué.

Valeurs de durcissement à vérifier

• wp-config.php droits définis sur 0600
• Tout fichier PHP valide dans le dossier « uploads » dont les droits d'accès sont définis sur 0600
• DISALLOW_FILE_EDIT et DISALLOW_FILE_MODS défini comme vrai
• FORCE_SSL_ADMIN défini comme vrai
• Pas de fichiers accessibles en écriture par tout le monde, pas de fichiers appartenant à un autre compte, pas de liens symboliques inattendus dans le répertoire racine des documents

En quoi consiste exactement un nettoyage certifié ?

La remise en état s'est déroulée selon la même structure dans les deux cas. C'est ainsi que ça se passe, et ça constitue un point de référence raisonnable pour évaluer n'importe quelle opération de nettoyage, qu'elle soit effectuée en interne ou par un prestataire.

Commence par le conteneur. Le premier site a été bloqué par un code d'erreur HTTP 403 pendant l'enquête. Nettoyer un site qui est encore accessible, c'est se retrouver en concurrence avec les mécanismes de restauration qui se déclenchent toutes les cinq minutes.

Sauvegarde tout avant de supprimer. Chaque fichier malveillant, chaque charge utile de base de données, chaque enregistrement utilisateur, chaque crontab et chaque fichier de configuration a été archivé et soumis à un hachage avant d'être supprimé. Supprimer un logiciel malveillant sans le sauvegarder t'empêche de répondre à certaines questions plus tard, notamment celle de savoir si le nettoyage a bien fonctionné.

Retire toutes les couches, puis vérifie chacune d'entre elles séparément. Système de fichiers, options de base de données, wp-config.php Les injections, les entrées cron, les répertoires temporaires, les plugins indispensables, les fichiers téléchargés et les fiches utilisateur ont tous été nettoyés et vérifiés séparément.

Vérifie l'intégrité du noyau et des paquets par rapport aux sommes de contrôle officielles. Sur les deux sites, le noyau a été vérifié. Sur le premier, on a enquêté sur une somme de contrôle de plugin qui ne correspondait pas, puis on a réinstallé le plugin à partir d'un paquet fiable ; en plus, deux thèmes dont les fichiers avaient été modifiés ont été remplacés par des paquets officiels, au lieu d'être corrigés sur place.

Fais pivoter tout ce que l'attaquant pourrait lire. En exécutant des commandes PHP et en accédant à la base de données, le pirate pourrait lire wp-config.php, le tableau des options et tous les identifiants qui y sont stockés. Ça inclut les mots de passe d'administrateur d'WordPress , cPanel, FTP et SFTP, SSH, base de données, SMTP, les clés des passerelles de paiement, ainsi que tous les jetons d'API tiers que le site détient. Les deux rapports indiquaient que la rotation était obligatoire, et non simplement recommandée.

Réduis et valide la liste des administrateurs. Sur un site, on est passé de 38 administrateurs non autorisés à trois comptes déjà existants. Pour chaque compte restant, le propriétaire du site doit confirmer, en indiquant son nom, qu'il est bien autorisé.

Supprime les sessions et les mots de passe d'application. Les mots de passe d'application WordPress créés par des pirates, dont les noms laissaient penser qu'il s'agissait de jetons d'automatisation, permettaient d'accéder au site sans même passer par le formulaire de connexion. La plupart des propriétaires de sites n'ont jamais ouvert cet écran dans leur profil. Et ça reste valable même après un changement de mot de passe.

Établis ensuite une base de référence. La base de référence enregistrée après la remédiation du premier site comprenait les hachages de plus de 36 000 fichiers exécutables et de configuration. Sans une base de référence fiable, la prochaine enquête repartira de zéro.

Ce que les agences et les développeurs devraient changer cette semaine

Trois mesures concrètes, classées par ordre décroissant de réduction des risques :

Vérifie la version d'WordPress installée sur chacun des sites que tu gères, un par un. Ne te fie pas au tableau de bord des mises à jour et ne pars pas du principe que la mise à jour forcée a bien été appliquée. Les chercheurs en sécurité ont régulièrement signalé que les sites sur lesquels les mises à jour automatiques étaient désactivées ou avaient échoué pouvaient toujours être exposés à des risques. Vérifie la chaîne de version, puis vérifie si un élément de la pile de plugins est configuré pour bloquer les mises à jour.

Vérifie à la fois les comptes administrateur et les mots de passe des applications. Un administrateur malveillant, ça se voit. En revanche, un mot de passe d'application associé à un compte légitime passe inaperçu, et c'est justement le mécanisme qui a le plus de chances de passer inaperçu lors d'un nettoyage fait à la va-vite. Vérifie les deux sur chaque site, puis jette un œil au répertoire des plugins « incontournables », qui n'apparaît pas du tout dans la liste normale des plugins.

Considère toute intrusion confirmée comme un événement nécessitant une rotation complète des identifiants. Si un pirate a pu exécuter du code PHP sur le compte, toutes les informations confidentielles accessibles depuis ce compte sont compromises. Une rotation partielle laisse une clé qui fonctionne toujours.

Une réinfection, c'est la suite logique d'un nettoyage partiel, ça n'a rien d'exceptionnel. Sur le premier site, il y a eu un intervalle de six jours, et pendant ces six jours, le site avait l'air propre, fonctionnait normalement et passait le test d'une inspection rapide.

Ce que ce genre d'enquête implique vraiment

Ces deux enquêtes ont été menées en interne par les équipes d'InMotion Hosting, sur l'infrastructure qu'on possède et qu'on exploite dans trois régions de centres de données. On n'a rien confié à un prestataire spécialisé dans l'analyse de sécurité, et aucune partie de l'analyse n'a été confiée à un tiers.

C'est important à cause de l'endroit où se cachait le malware. Un scanner de malware commercial détecte les fichiers. Il ne décode pas les charges utiles stockées dans la table des options sous des noms qui imitent les variables temporaires légitimes de l'état du site. Il ne trace pas les blocs de chargement injectés dans wp-config.php aux fichiers exécutables qu'ils recréent dans le répertoire temporaire du compte. Il ne se rend pas compte que cinq fichiers respectant la convention de nommage habituelle de PHP pour les fichiers téléchargés auraient dû être supprimés à la fin d'une requête il y a trois semaines, mais qu'ils ne l'ont pas été.

Ces conclusions sont le fruit d'une analyse du code et d'une mise en corrélation des horodatages des journaux d'accès archivés, des enregistrements d'activité d'WordPress et du crontab du compte. Chaque ingénieur de nos équipes d'assistance suit plus de 280 heures de formation avant de traiter les demandes de niveau 1, et l'ancienneté moyenne au sein de l'équipe d'assistance dépasse les cinq ans. Ces mêmes équipes sont disponibles 24 h/24 et 7 j/7, et les enquêtes à l'origine de cet article ont été menées par des personnes que tu peux joindre par téléphone.

Ça correspond aussi à la façon dont on gère les menaces au niveau de l’infrastructure. Quand une faille critique de pré-authentification dans cPanel et WHM a été révélée en avril 2026, notre équipe d’exploitation réseau a bloqué l’exposition à la périphérie du réseau dans les trois régions de centres de données en quelques heures, puis a appliqué les correctifs serveur par serveur sur l’ensemble du parc. WordPress Les mises à jour du noyau s’appliquent au sein de ton application plutôt qu’au niveau de la pile serveur, c’est pourquoi une faille comme celle-ci nécessite une réponse différente et un autre type d’enquête.

Si tu gères des sites WordPress pour des clients et que tu n'es pas sûr qu'un nettoyage précédent ait été complet, c'est justement cette incertitude qui est le problème. Envoie-nous le compte et on va examiner toutes les couches, pas seulement le système de fichiers.

N'hésite pas à contacter notre équipe ou à découvrir nos services d'hébergement géré.