Un shortcode ou un article WordPress qui exécute du PHP
Un plugin « PHP in post » ou une insertion brute : l'article exécute du code, rien à la racine. Désactivez ce plugin, relisez les contenus récents. C'est une porte élégante — et un argument pour ne plus jamais exécuter de PHP depuis l'éditeur.
Plugin « PHP in post » ou insertion brute. Désactivez ce plugin, relisez les articles récents. C'est une porte élégante : rien à la racine.
Rien à la racine, et pourtant
Les scans cherchent `radio.php` et les doubles extensions dans `uploads`. Ils passent à côté d'un article « Contact » qui, via un plugin, exécute un one-liner. L'admin a l'air normal. La page, elle, fait autre chose pour certains user-agents, ou envoie un mail, ou écrit un fichier.
C'est pour ça que « le FTP est clean » n'est pas un constat. Il manque la base, les posts, les options, les plugins qui évaluent du texte comme du code.
Nous ne publions pas de recettes. Le geste : trouver ce qui évalue, l'éteindre, relire les contenus qui ont pu servir de véhicule, comparer le reste du site comme d'habitude.
Les plugins qui rendent ça possible
Insert PHP, « PHP Code Widget », des forks, des builders qui ont un widget PHP, des plugins « snippets » trop permissifs (tout le monde peut écrire un snippet). La page Extensions suffit souvent à les nommer. Sur le disque, un dossier dont le readme vante `eval` ou « run PHP in posts ».
Un snippet plugin légitime (Code Snippets bien limité aux admins) n'est pas le même risque qu'un « PHP everywhere ». Après incident, même le légitime se relit : un snippet créé à 3 h, ce n'est pas vous.
Thème enfant : `functions.php` et des `require` depuis un article (via un shortcode thème) : même famille, autre tiroir. Relisez le thème, pas seulement les plugins.
Shortcode, bloc, et champ personnalisé
Un `[php]…[/php]`, un bloc « custom HTML » qui n'est pas du HTML, un champ ACF « qui accepte tout ». Parcourez les posts modifiés récemment (date, pas seulement « publié cette semaine » : un article de 2018 réenregistré). Les révisions WordPress aident parfois à voir l'insertion.
Les widgets (classique ou blocs) et les templates Elementor : même chasse. Un header global est plus rentable pour un attaquant qu'un billet obscur — mais le billet obscur indexé, si.
Commentaires + thème qui exécute les shortcodes auteurs : autre entrée. Commentaire avec payload.
- Posts et pages : date de modification, révisions.
- Widgets, templates builder, footers.
- Champs ACF / metabox « libres ».
Relire sans tout vider
Ne videz pas tous les articles « pour être sûr ». Vous perdez l'historique et de vrais contenus. Filtrez : shortcodes suspects, blocs bruts, auteurs fantômes, dates groupées. Exportez avant suppression. Les pages spam IA se traitent à part (générateur, 410).
Une recherche en base sur des motifs trop vagues casse des contenus légitimes. Mieux : lister via l'admin les derniers modifiés, plus une recherche du nom du shortcode du plugin (une fois que vous l'avez).
Copie hors serveur avant toute purge de posts. Toujours. Sauvegarder l'état actuel.
Désactiver, puis chercher le reste
Éteindre « Insert PHP » arrête l'évaluation. Ça n'efface pas un mu-plugin, un cron, un user admin posés grâce à cette évaluation. Ensuite, le protocole habituel : comparaison, accès, sitemaps.
Supprimer le plugin sans relire les articles laisse le shortcode visible (laid) ou, selon le thème, un reste. Relisez après extinction.
Ne réinstallez pas le même plugin « le temps de récupérer un snippet métier ». Sortez le métier vers un vrai fichier, plus tard, à froid.
Ce que l'éditeur de fichiers a en commun
Pouvoir écrire du PHP depuis l'admin (thème / plugin editor) est le cousin : pas besoin d'« insert PHP », l'admin suffit. On le ferme après incident. DISALLOW_FILE_EDIT.
Les deux fonctionnalités existent pour le confort. Après un vol de session admin, elles sont des rampe. Le confort se paie au deuxième dossier.
Un compte éditeur (pas admin) + insert PHP pour les éditeurs : encore pire. Moindre privilège. Rôles.
Après : interdire, pas « faire attention »
Pas de plugin d'exécution dans les posts. Pas d'éditeur de fichiers. Snippets réservés à un admin nominatif, 2FA. Revue des extraits après chaque freelance.
Si un besoin métier « vraiment, du PHP dans une page » revient, c'est un malentendu : c'est une fonctionnalité, donc un développement, donc un dépôt, donc une revue. Pas un article.
Surveillance : nouveau plugin de cette famille, nouveau snippet, posts modifiés en masse. Surveillance.
Décider si le contenu reste
Un article légitime qui contenait un shortcode pirate : on retire le shortcode, on garde le texte si vous l'assumez. Un article créé pour l'exécution : on le tue (410 s'il était indexé), on ne le « nettoie pas pour le SEO ».
Les révisions : une révision propre peut servir. Ne restaurez pas une révision au hasard : elle peut être l'insertion.
Déclarer : dites si un plugin « PHP in post » est dans la liste. Ça oriente la première lecture de base, pas seulement le disque.