Backdoor WordPress : comment les pirates gardent l’accès après le nettoyage

C’est LE sujet qui sépare un nettoyage réussi d’une réinfection à répétition. Selon Sucuri,
environ 70 % des sites compromis contiennent au moins une porte dérobée
(backdoor) au moment de leur nettoyage — et sur nos interventions, on en trouve rarement une
seule : un attaquant sérieux en pose plusieurs, de natures différentes, précisément pour
survivre à un nettoyage partiel. Si votre site a été « nettoyé » deux fois et réinfecté
deux fois, vous n’avez pas un problème de malchance : vous avez une backdoor. Voici comment
elles fonctionnent, où elles se cachent, et comment on les traque.

Pourquoi les pirates posent des backdoors (l’économie du piratage)

Il faut comprendre le modèle économique : 95 % des attaques sont
automatisées (constat partagé par l’ANSSI et les acteurs de la sécurité WordPress). Un robot
exploite une faille d’extension, et sa toute première action n’est pas de défigurer votre site —
c’est de sécuriser son accès en déposant des portes dérobées. Le site compromis est
ensuite monétisé dans la durée : spam SEO, redirections (campagnes type Balada Injector, plus
d’un million de sites touchés), envoi d’e-mails, minage, revente de l’accès. La faille d’entrée peut
être corrigée par une mise à jour automatique des semaines plus tard : peu importe, la backdoor
est déjà là. C’est pourquoi « j’ai tout mis à jour » ne suffit jamais après une
compromission.

Les 6 formes de backdoor (et comment on les détecte)

1. Le webshell : un fichier PHP qui exécute ce qu’on lui envoie

La forme la plus connue. Parfois un vrai panneau de contrôle (gestionnaire de fichiers,
terminal), parfois une seule ligne du type @eval($_POST[...]) — dix caractères qui
donnent le contrôle total. Cachettes favorites : wp-content/uploads/ (qui ne
devrait contenir AUCUN fichier PHP — on peut l’interdire côté serveur), la racine du site sous un
nom crédible (wp-cache.php, wp-info.php), ou un dossier d’extension
légitime. Détection : recherche de fichiers PHP dans uploads/, comparaison de chaque extension
avec son zip officiel, recherche de motifs eval, base64_decode,
gzinflate, system dans les fichiers récents.

2. L’injection dans du code légitime

Plus discret : quelques lignes ajoutées à functions.php du thème, à
wp-config.php ou au fichier principal d’une extension saine. Le fichier existe
légitimement, sa date de modification est parfois falsifiée : seule la comparaison
octet par octet avec la version officielle (checksums du cœur via
wp core verify-checksums, diff des extensions) la révèle de façon fiable.

3. Le compte administrateur fantôme

Un utilisateur au rôle administrateur, créé pendant l’intrusion, avec un nom générique et un
e-mail jetable. Variante vicieuse : des attaquants le masquent de la liste des
utilisateurs via un filtre injecté — le compte n’apparaît pas dans l’admin mais existe en
base. Notre contrôle : la table wp_users directement en base, croisée avec
wp_usermeta pour les rôles — jamais uniquement l’écran Utilisateurs de WordPress.

4. Le mot de passe d’application oublié

Depuis WordPress 5.6, chaque compte peut générer des mots de passe d’application
(accès API REST). Un attaquant qui en crée un conserve un accès complet même après que vous avez
changé votre mot de passe principal — c’est l’oubli le plus fréquent des nettoyages amateurs.
Contrôle : profil de chaque utilisateur → section Mots de passe d’application → tout révoquer.
Même logique pour les clés de sécurité de wp-config.php (AUTH_KEY et consorts) :
tant qu’elles ne sont pas régénérées, les cookies de session volés restent valides.

5. La tâche cron de réinfection

La cause n°1 des récidives « inexpliquées » qu’on nous amène : une tâche planifiée
— dans le cron WordPress (visible avec WP-CLI : wp cron event list) ou dans le
crontab du serveur — qui retélécharge le malware chaque nuit depuis un serveur distant. Vous nettoyez
le lundi, le site est réinfecté le mardi à 3 h. Contrôle des deux niveaux obligatoire, WordPress
ET serveur.

6. Le faux plugin (et le mu-plugin oublié)

Une « extension » au nom générique apparue dans wp-content/plugins/, ou —
plus discret encore — un fichier dans wp-content/mu-plugins/ : les
must-use plugins s’exécutent à chaque chargement de page, sans apparaître dans la
liste standard des extensions et sans pouvoir être désactivés depuis l’admin. Beaucoup de
sites n’utilisent pas ce dossier légitimement : tout ce qui s’y trouve doit être identifiable,
sinon c’est suspect.

La chasse aux backdoors : notre check-list de sortie

• →Aucun fichier PHP dans uploads/, exécution PHP interdite dans ce dossier côté serveur.
• →Cœur vérifié par checksums, wp-admin/ et wp-includes/ réinstallés, extensions comparées à leurs zips officiels.
• →wp-config.php et .htaccess inspectés ligne par ligne, clés de sécurité régénérées.
• →Table wp_users auditée en base, mots de passe d’application révoqués sur TOUS les comptes.
• →Cron WordPress et crontab serveur passés en revue.
• →mu-plugins/ et plugins/ inventoriés : chaque dossier doit correspondre à une extension connue.
• →Puis 30 jours de surveillance des fichiers modifiés — le vrai verdict.

Et en amont : la plupart des intrusions passent par une extension non à jour — 91 % des
11 334 vulnérabilités WordPress recensées en 2025 concernaient des extensions (Patchstack), et
les plus ciblées sont exploitées en quelques heures. Un site qui se met à jour vite et se surveille
n’offre tout simplement pas l’occasion de poser une backdoor ; c’est le rôle d’une
maintenance sérieuse.

Sources : Sucuri Hacked Website Threat Report (backdoors : ~70 % des sites
compromis ; campagne Balada Injector : 1 M+ de sites) ; Patchstack, State of
WordPress Security in 2026 ; ANSSI / CERT-FR (automatisation des attaques) ; documentation
WordPress (mots de passe d’application, mu-plugins, WP-CLI) ; interventions EVICO.