Plugin File Manager resté en ligne : une porte grande ouverte
Un gestionnaire de fichiers dans l'admin est une cible quotidienne. Désinstallez-le après usage. S'il a été exposé — même une semaine — partez du principe que des fichiers ont été déposés : racine, mu-plugins, uploads.
Un gestionnaire de fichiers dans l'admin est une cible quotidienne. Désinstallez-le après usage. S'il a été exposé, partez du principe que des fichiers ont été déposés.
Pourquoi les bots l'adorent
Un RCE ou un upload dans File Manager, c'est le jackpot : écriture arbitraire. Les CVE de WP File Manager ont été massivement scannées. Le plugin n'a pas besoin d'être « ouvert au public » : un admin faible ou une faille d'auth suffit.
Le laisser « au cas où je dois éditer un CSS » est une porte 24/7. Usage, puis désinstallation le jour même. Plugin vulnérable.
Un File Manager exposé — même une semaine — se traite comme une écriture arbitraire déjà utilisée. Partez de la liste : `radio.php` à la racine, mu-plugin, `installer.php`, zip extrait, `wp-config` touché, `.htaccess` redirect, `phpinfo.php`. Les dates = fenêtre d'exposition. Hide login ne cache pas les endpoints ajax. Désinstaller le plugin enlève le dossier, pas les dépôts : c'est le malentendu n°1. L'éditeur de fichiers du cœur (`DISALLOW_FILE_EDIT`) est la petite sœur : désactivez-le après.
Les CVE File Manager se rescannent des années après. Un dossier encore sur le disque, même désactivé, a des endpoints. Retirez le dossier après copie. Les clones et « theme editor pro » dans le même inventaire. cPanel file manager : secret panel distinct, changé en premier, ce n'est pas une excuse pour garder le plugin.
Le dossier du plugin, même désactivé, reste joignable : retirez-le du disque.
Même « caché » derrière wp-admin
Les endpoints ajax / REST du plugin sont devinables. Hide login ne les cache pas. Un attaquant avec un cookie volé a un explorateur de tout le compte, voisin compris parfois (chemins `../`).
Hide login ne cache pas les endpoints ajax du plugin. Un cookie volé suffit. Partez du principe que des fichiers ont été déposés, même si « vous n'avez rien vu ».
Ce qu'on dépose en trois clics
`radio.php` à la racine, un mu-plugin, un `installer.php`, un zip qu'on extrait, une modification de `wp-config.php`, un `.htaccess` redirect. Partez de cette liste. Dates = fenêtre d'exposition du plugin.
Les backups extraits dans le webroot. Les `phpinfo.php` de test.
Cherchez aussi les zips extraits dans un dossier à nom aléatoire et les `phpinfo.php` de « test ». Un File Manager permet de remonter d'un cran (`../`) vers le compte voisin : inspectez les autres sites du panel, pas seulement ce WordPress.
- PHP à la racine et dans mu-plugins.
- uploads : .php et .php.jpg.
- wp-config et .htaccess touchés.
- installer.php / archives .zip.
Chasse après exposition
Comme un incident complet, pas « je désinstalle et c'est bon ». Users créés via l'admin (ils avaient le File Manager). Par où commencer, PHP uploads.
Listez les users créés pendant la fenêtre d'exposition : ils avaient l'explorateur. Révoquez application passwords. Régénérez les clés AUTH. Le plugin désinstallé n'invalide pas les sessions déjà ouvertes.
La chasse après exposition est un incident, pas un delete. Dates = fenêtre. `../` vers le voisin. Users créés. installer.php posé via l'explorateur. Duplicator. Désinstaller sans ça, c'est le malentendu n°1.
WP File Manager, Filebird, et les clones
Filebird est une bibliothèque de médias, moins un explorateur système — autre risque. Les clones « Advanced File Manager », versions nulled : pire. Inventaire : tout ce qui permet d'écrire un PHP depuis wp-admin sans SFTP.
Tout ce qui écrit un PHP depuis wp-admin sans SFTP est dans la même famille : Advanced File Manager, clones nulled, « theme editor pro ». Inventaire, pas seulement le logo WP File Manager.
Éditeur de fichiers du cœur
Apparence > Éditeur de fichiers. `DISALLOW_FILE_EDIT` dans wp-config après le clean. Moins puissant qu'un File Manager, assez pour un `functions.php`. Désactivez.
Désinstaller n'efface pas les dépôts
Le dossier du plugin part. `radio.php` reste. C'est le malentendu n°1. Désinstaller est obligatoire et insuffisant.
SFTP + DISALLOW_FILE_EDIT + plus de plugin explorateur. Une urgence : une heure, puis delete + chasse. Deux jours en 2023 sans inspection : passe courte due.
Remplacer par SFTP
Un client SFTP, un mot de passe panel distinct, pas d'explorateur web. Pour une urgence, File Manager une heure, puis delete + chasse.
Remplacez par SFTP, secret panel distinct. Urgence : le plugin une heure, puis delete + chasse. Guide WordPress, créer un espace.
File manager cPanel, multisite, et l'éditeur du cœur
Le gestionnaire de fichiers du panel n'est pas le plugin WP : il est derrière le mot de passe d'hébergement, à changer en premier. Plus puissant. Secret distinct. Multisite : un File Manager réseau est encore plus grave. Sortez-le. Multisite.
Apparence > Éditeur : `DISALLOW_FILE_EDIT` après le clean. Assez pour un functions.php. Wordfence qui « bloque File Manager » n'est pas une raison de le garder : surface RCE historique.
Vous l'avez eu deux jours en 2023 : si rien n'a été inspecté, une passe dates / racine / mu-plugins reste raisonnable. Les bots frappent encore les vieux endpoints. Créer un espace.
Après exposition : partir du pire
Partez du principe que racine, mu-plugins, uploads, wp-config, .htaccess et un zip extrait ont été touchés. Dates = fenêtre. Users créés. Voisin de compte (`../`). Désinstaller n'efface rien de tout ça. SFTP désormais. Éditeur du cœur off.
Deux jours en 2023 sans inspection depuis : une passe courte reste due. Les CVE File Manager se rescannent encore. Par où commencer. Créer un espace.