Wordfence a détecté un malware : que faire des 80 fichiers listés

Ce que la liste est, ce qu'elle n'est pas

C'est une liste de signatures et d'heuristiques. Utile. Ce n'est pas l'inventaire complet, ni l'ordre de l'entrée. Un `footer.php` listé est souvent le symptôme ; l'entrée est un plugin d'il y a trois mois.

80 fichiers : beaucoup de copies du même payload dans des caches, des backups Updraft, des `old/`. Comptez les uniques, pas les lignes. On sort ces archives du webroot ; on ne les restaure pas à l'aveugle.

Triez les 80 lignes en quatre seaux avant tout clic : cœur → zip WordPress ; plugin officiel → zip éditeur ; thème parent → zip auteur ; le reste → lecture. Beaucoup de lignes sont le même payload dans des caches et des backups. Comptez les uniques. « Réparer tout » écrase un thème enfant et rate le mu-plugin à côté. Copie globale du compte d'abord. La quarantaine Wordfence reste sur le serveur : exfiltrez les originaux pour le constat.

Imprimez ou exportez la liste avant le premier repair : l'écran change, vous perdez le « first seen ». Classez hors WordPress les chemins `old/`, `backup/`, `updraft/` : ce sont des copies, pas le CMS vivant. Les sortir du webroot réduit la liste plus vite qu'un repair.

Quatre seaux pour trier

Cœur (`wp-admin`, `wp-includes`, PHP de racine officiels) : remplacer par le zip. Plugin du repo : zip officiel. Thème parent marketplace : zip auteur. Reste : lecture humaine — enfant, mu-plugins, uploads, fichiers à noms aléatoires, `wp-config.php`.

Mélangez les seaux, vous cassez le métier ou vous laissez le reste. Supprimer malware.

Les backups dans `uploads` et `ai1wm-backups` font hurler Wordfence à juste titre (PHP ou dumps exposés). Sortez-les du web, ne « réparez » pas un zip de 400 Mo. Les caches minifiés (`cache/min/*.js`) peuvent contenir le mineur concaténé : on vide le cache, on ne le « repair » pas comme du cœur.

• Cœur → zip WordPress.
• Plugin officiel → zip wp.org / éditeur.
• Thème parent → zip auteur.
• Le reste → ouvrir, pas « repair all ».

Réparer : quand oui, quand non

Oui : un `class-wp-query.php` du cœur avec une ligne ajoutée, et le zip correspond. Non : `functions.php` du child, un plugin maison, un mu-plugin que vous avez écrit, un CSS. Wordfence « répare » en écrasant : adieu le correctif légitime.

En cas de doute : copier le fichier hors site, comparer, puis décider. Isoler (renommer `.php.off`) plutôt que delete si vous ne savez pas.

Les faux positifs qui reviennent

Des obfuscations légitimes (certains page builders, licences), des signatures trop larges sur `eval` dans un plugin payant officiel. Vérifiez chez l'éditeur. Marquer « ignore » sans lire, c'est l'inverse du métier — mais « repair » sur un faux positif casse aussi.

Les backups dans `uploads` / `wp-content/ai1wm-backups` : Wordfence hurle à juste titre (du PHP ou des dumps exposés). Sortez-les du web, ne « réparez » pas un zip de 400 Mo.

Ce que Wordfence n'a pas listé

Une porte d'une ligne, un user admin, un cron système, un voisin de compte, un `installer.php` sans signature connue, un `.htaccess` de redirect, une option `siteurl`. La liste à 80 peut être « tout vert » après repair et le site encore pris. Wordfence ne suffit pas.

Après un repair tout vert, relisez quand même users, `siteurl`, cron, voisin, `installer.php`. La liste à 80 n'est pas l'inventaire de l'entrée. Wordfence ne suffit pas.

Ce que la liste n'a pas : un user, un cron Linux, un voisin, un siteurl. Après le vert Wordfence, ces quatre-là restent dus. Sinon le mercredi recommence et la liste revient, parfois plus courte, parfois ailleurs.

Quarantaine et copies

La quarantaine Wordfence est sur le serveur. Une backdoor ailleurs peut la relire. Exfiltrez les originaux vers votre PC pour le constat, puis videz.

Copie globale du compte avant le premier repair. Toujours.

La quarantaine est sur le serveur. Une backdoor ailleurs peut la relire. Copie hors site des originaux, puis videz. Relancer un scan tous les quarts d'heure pendant l'attaque : charge et auto-repair. Contrôle à J+1 et J+7.

Après le tri : encore la porte

Users, File Manager, PHP uploads, thème nulled, plugin oublié. Par où commencer.

Puis Google. Blacklist.

Scanner n'est pas fermer

Relancer un scan tous les quarts d'heure pendant l'attaque : bruit, charge, parfois auto-repair. Un scan de contrôle à J+1 et J+7, oui.

Guide backdoor, créer un espace.

Après le tri, la porte n'est pas fermée : users, File Manager, PHP uploads, thème nulled. Par où commencer. Puis Google. Blacklist. Scanner n'est pas fermer. Créer un espace.

Imunify, Premium, et l'écran Chrome encore rouge

Imunify360 et Wordfence : deux listes, mêmes seaux. L'hébergeur qui « répare tout seul » : relisez le thème enfant après. Premium a plus de signatures, le même piège « tout réparer ». Un scan de six heures sur un gros uploads : excluez les backups hors web plutôt que d'attendre la nuit.

Après repair, Chrome encore rouge : une URL n'était pas dans la liste. Testez, inspectez. Ads et Safe Browsing. Relancer un scan tous les quarts d'heure : bruit. Contrôle J+1 et J+7.

Guide backdoor. Créer un espace.

Comment trier demain matin sans tout casser

Café, copie déjà faite, quatre seaux, pas de « repair all ». Cœur et plugins officiels : zip. Enfant et maison : ouvrir. Uploads PHP : delete + Deny. Backups : hors web. Quarantaine : exfiltrer puis vider. Un scan de contrôle, pas vingt.

Puis users, panel, File Manager, installer.php. Wordfence n'a pas listé ça. Par où commencer. Créer un espace.