Pourquoi Wordfence ne suffit pas à nettoyer un WordPress

Ce qu'un WAF et un scanner voient

Le scanner lit des fichiers et cherche des motifs. Le WAF (si la firewall est active) bloque des requêtes connues. Ni l'un ni l'autre ne « comprennent » votre métier. Un `include` d'une ligne dans `wp-config.php` vers `uploads/cache/.ico` n'a pas de signature publique le jour J.

C'est pour ça que des sites « Wordfence vert » reviennent. 80 fichiers : même outil, autre geste (trier). Ici : les angles morts.

Le scanner cherche des motifs connus. Le WAF bloque des requêtes connues. Une ligne `include` dans `wp-config.php` vers `uploads/cache/.ico` n'a pas de signature le jour J. Les sites « Wordfence vert » qui reviennent sont ce cas. Posez le plugin après l'attaque, en filet (alertes fichiers, 2FA), pas comme premier geste : tables, charge, parfois lockout de votre IP d'investigation.

Nous reprenons chaque semaine des sites « 100 % clean » Wordfence avec un mu-plugin de 400 octets et un include wp-config. Le plugin a fait son métier : signatures. La porte unique n'en est pas une. C'est pour cela que comparer au zip n'est pas optionnel.

La porte « unique »

Un one-liner, un nom de fonction banal (`get_option_clean`), un fichier `index.php` dans un dossier d'uploads qui ne fait que `eval($_POST[x])` avec une clé. Pas de `eval(base64` classique. Grep et dates battent le scan.

Les mu-plugins d'une vingtaine d'octets. Backdoor.

Grepez `eval`, `base64_decode`, `gzinflate`, `assert`, `create_function`, mais aussi des noms banals (`get_option_clean`, `theme_setup_extra`). La porte unique évite les chaînes évidentes. Les dates de `mu-plugins` et de la racine, triées, trouvent souvent le fichier que le scan a noté « clean ».

Base, cron, voisin

Wordfence ne lit pas tout `wp_options` comme un humain. Un JS dans un widget. Un cron Linux hors WP (`wget` vers un PHP). Un site `old.domaine` dans le même panel. Aucun scan « WordPress » ne voit le voisin. Guide WP.

Demandez à l'hébergeur la crontab du compte, pas seulement WP-Cron. Un `wget` toutes les cinq minutes vers un PHP de la racine réécrit ce que vous venez de retirer. Les autres dossiers du panel (un Presta oublié, un `old/`) : le plugin WordPress ne les ouvre pas. C'est le motif n°1 des « on a déjà tout réinstallé ».

Le voisin de compte n'apparaît dans aucun écran Wordfence. Panel : listez les domaines, les cron, les comptes FTP ajoutés. Un Presta ou un `old/` dans le même home suffit. Guide voisin / IP si l'hébergeur est mutualisé.

Installer Wordfence pendant l'attaque

Ça ajoute des tables, des fichiers, de la charge, parfois un blocage de votre propre FTP d'investigation. Posez-le après, en filet : alertes de fichier, 2FA, limitation login. Pas comme premier geste. Premiers gestes.

Le mode « learning » et les trous

Un WAF en apprentissage autorise ce qu'il voit. Pendant un incident, il apprend l'attaque. Passez en protection, mais après avoir compris ce que vous bloquez (sinon vous cassez le checkout).

À quoi il sert vraiment après

Alertes « file changed » sur `wp-config`, `mu-plugins`, racine. 2FA. Captcha login. Blocage des scans de brute force — utile, pas suffisant si l'entrée était un plugin RCE. Brute force.

Coupler comparaison et logs

Zip officiel vs disque. access.log. Dates. C'est le trio. Wordfence est le quatrième, pour le bruit connu.

Sucuri SiteCheck : cinquième, distant, autre angle mort. Sucuri.

Un access.log de 48 h autour de la première date de fichier suspect suffit souvent : quel script a été appelé juste avant. Sans logs, vous avez encore les dates et les zips. Les trois ensemble ferment plus de dossiers qu'un quatrième scan.

Les logs de 48 h autour de la première date suspecte valent plus qu'un quatrième scan. Quel PHP a été appelé juste avant le premier fichier daté. Sans logs, dates + zips tiennent encore la route.

Quand s'arrêter de scanner

Quand le trio est propre et que J+7 ne recrée pas de fichiers. Scanner en boucle rassure mal. WordPress piraté, créer un espace.

Le trio fiable : zip vs disque, access.log, dates. Wordfence est le quatrième, pour le bruit connu. Quand J+7 ne recrée rien, arrêtez de scanner en boucle. WordPress piraté, créer un espace.

Mode learning, score, et pile de plugins

Un WAF en apprentissage pendant l'incident apprend l'attaque. Passez en protection après avoir compris ce que vous bloquez — sinon vous cassez le checkout. Le score « 90 % sécurisé » est une checklist du plugin, pas un audit. Ignorez-le.

iThemes + Wordfence + Sucuri plugin : trois bruits, règles qui se marchent dessus. Un filet après le clean. Wordfence qui bloque Googlebot crée une disparition artificielle. robots.txt.

Le CLI voit plus de fichiers, les mêmes signatures. Toujours pas la porte unique. WordPress piraté.

Arrêtez-vous quand J+7 ne recrée rien, pas quand le score affiche 90. Le score n'est pas un audit. Créer un espace si le trio zip / logs / dates n'est pas votre métier.

Checklist des angles morts

wp-config include. mu-plugins d'une ligne. cron système. voisin de compte. siteurl en base. user admin. installer.php. .htaccess redirect. option widget JS. service worker. GTM tag. Ces dix-là passent un scan vert. C'est le trio zip / logs / dates qui les trouve.

Posez Wordfence après, en filet. Backdoor PHP. Créer un espace.

• include wp-config.
• mu-plugins.
• cron panel.
• voisin vhost.
• siteurl.
• user fantôme.