Sur WordPress, on peut passer des heures à colmater des failles “classiques” et rater le problème le plus discret: l’abus de shortcodes. Ce n’est pas la première chose qui vient à l’esprit quand on parle de malware, et pourtant c’est un vecteur fréquent parce que les shortcodes touchent directement au rendu du contenu. Un plugin (ou un thème) malveillant peut s’en servir pour déclencher un comportement pendant l’affichage, pas uniquement lors de l’envoi d’un formulaire ou de l’exécution d’une tâche planifiée.
J’ai déjà vu des infections où la page semblait normale en surface, mais où certains visiteurs déclenchaient des actions invisibles. Le déclenchement venait d’un shortcode injecté dans une page “innocente”, ou d’un shortcode déjà présent dans le thème, mais dont l’implémentation avait été remplacée ou détourée. Le résultat: redirections, chargement de scripts distants, exfiltration de contenu, parfois une cascade qui finit en spam SEO.
Ce guide vise un objectif pratique: vous aider à repérer l’abus de shortcodes, et à distinguer ce qui relève d’une intégration légitime de ce qui ressemble à une porte ouverte. On va parler de ce que font les scanners, de leurs limites, et surtout de la façon d’observer le site comme le ferait un attaquant, avec des hypothèses testables.
Pourquoi les shortcodes sont une cible intéressante
Un shortcode dans WordPress est une petite “commande” écrite en texte, du type [quelque_chose]. WordPress appelle ensuite la fonction PHP correspondante pour produire du HTML. L’idée est séduisante pour les développeurs, car elle permet d’insérer des composants dans une page sans toucher au thème.
Mais cette mécanique crée un point de contrôle: ce qui est rendu dépend entièrement de la logique côté serveur. Si un acteur malveillant parvient à:
- ajouter ou modifier un shortcode existant, enregistrer un nouveau shortcode, ou injecter du contenu qui active un shortcode,
Alors il peut obtenir un comportement arbitraire lors du rendu.
Le piège courant, c’est que beaucoup de personnes ne regardent jamais l’implémentation des shortcodes. Elles contrôlent le contenu des pages, puis elles lancent un scanner de sécurité, par exemple un scanner malware WordPress via un plugin ou un outil en ligne. Or, l’infection peut se cacher derrière un shortcode qui ne “fait” rien de visible à première vue, mais qui exécute un chargement distant ou un enchaînement de requêtes.
Ce que les scanners détectent (et ce qu’ils ratent)
Un scanner malware WordPress est utile, surtout pour repérer des signatures connues, des fichiers modifiés, ou des webshells classiques. En revanche, un scanner se base rarement sur une compréhension complète de la logique WordPress. Il cherche souvent des motifs dans les fichiers, compare des hachages, ou applique des règles heuristiques.
Trois scénarios où un scanner peut être trompé:
1) Le malware est “au bon endroit”, mais pas avec la bonne signature. S’il est légèrement modifié, il peut passer sous le radar des règles strictes.
2) Le malware est déclenché seulement dans certains contextes. Par exemple, uniquement pour un type de page, un cookie particulier, ou un rôle utilisateur.
3) Le shortcode est présent mais son implémentation a été modifiée. Un scanner peut détecter des fichiers altérés, mais si vous n’inspectez pas le code et que vous vous contentez de “tout restaurer”, vous perdez la compréhension de ce qui s’est passé. Pire, si vous restaurez sans éliminer la source, le problème peut revenir après une réactivation ou une restauration incomplète.
La bonne approche consiste à utiliser le scanner comme un radar, puis à faire une observation ciblée. Pour les shortcodes, l’observation se fait sur trois axes: le contenu qui référence le shortcode, l’enregistrement PHP du shortcode, et la sortie HTML générée lors de l’affichage.
Les indices concrets d’un abus de shortcodes
L’abus de shortcodes ne se résume pas à “il y a du code dans un plugin”. Souvent, le comportement est subtil, et vous pouvez le repérer en combinant des éléments côté navigateur, côté WordPress, et côté fichiers.
Voici les signaux qui reviennent le plus souvent sur des sites contaminés:
- présence d’un shortcode inattendu dans une page ou un article qui n’aurait jamais dû en contenir, apparition de scripts ou d’iframes qui ne sont pas liés aux plugins installés, modifications de fichiers PHP dans un thème ou un plugin qui gèrent le rendu du contenu, logs de WordPress qui montrent des erreurs ou des appels à des fonctions inhabituelles pendant la génération de pages, différence de rendu selon l’utilisateur (par exemple admin vs visiteur) ou selon la langue.
Un détail important: un shortcode légitime peut aussi produire du HTML dynamique, donc vous ne pouvez pas conclure uniquement sur l’existence du shortcode. C’est la logique derrière le shortcode, et la chaîne de déclenchement, qui font la différence.
Où chercher: le chemin du shortcode, de la page à la fonction PHP
Pour comprendre un abus, il faut suivre la trajectoire.
Dans le contenu: vous trouvez la “trace textuelle” du shortcode dans une page, un article, parfois dans un widget, ou dans des champs où il est censé être autorisé. Dans l’exécution WordPress: WordPress doit “connaître” le shortcode via l’enregistrement PHP (souvent add_shortcode). Dans le code: vous inspectez le fichier où le shortcode est défini, puis vous cherchez ce qu’il fait vraiment.Ce chemin est particulièrement clair quand vous avez un shortcode du type [something] dans une page. Vous pouvez ensuite retrouver la définition côté code.
Même si un scanner vous a déjà alerté, cette démarche vous aide à vérifier une hypothèse et à éviter les corrections inutiles. Par exemple, si le shortcode est défini dans un plugin légitime mais que le plugin est propre, alors votre suspicion doit se déplacer vers une autre couche, comme une injection dans la base de données.
Méthode pratique: confirmer qu’un shortcode déclenche un comportement suspect
Vous voulez passer du “je suspecte” à “je peux reproduire”. Il faut une démarche courte, contrôlée.
D’abord, identifiez la page concernée. Ensuite, observez le rendu dans deux contextes:
- un visiteur standard (non connecté), un utilisateur connecté (idéalement admin, pour voir le contenu complet et pour réduire certains filtrages).
Si le comportement ne se manifeste que dans l’un des deux cas, c’est un indice fort. Ensuite, regardez le HTML rendu final. Un comportement malveillant via shortcode se manifeste souvent par des éléments ajoutés au moment du rendu, donc dans le HTML final.
Vous pouvez aussi observer les requêtes réseau côté navigateur: chargement de scripts externes, requêtes vers des domaines non liés à votre écosystème, appels vers des endpoints qui n’existent pas dans vos plugins. Un shortcode peut générer un
Enfin, revenez côté serveur. Si vous avez accès aux logs, cherchez des erreurs ou des messages qui correspondent au moment d’affichage de la page. Les infections par shortcode laissent parfois des traces, même indirectes, dans les logs de WordPress ou du serveur web.
Cartographier l’enregistrement des shortcodes
Le point le plus utile, c’est de trouver où le shortcode est enregistré. C’est là que vous vérifiez qui contrôle la sortie.
Dans WordPress, l’enregistrement se fait presque toujours par des appels à add_shortcode. Si vous avez accès au code source (plugins, thèmes), une recherche dans les fichiers est souvent plus rapide que l’analyse “au hasard”.
Quand vous trouvez add_shortcode('nom', 'fonction') ou add_shortcode('nom', 'objet->methode'), vous pouvez ensuite ouvrir la fonction et lire ce qu’elle fait. Les red flags typiques:
- lecture de fichiers sur le serveur, appels à des endpoints externes, création ou modification de contenu selon des variables qui ne devraient pas être externes, base64 decode, eval, assert, ou comportements proches, utilisation de superglobals pour injecter des paramètres directement dans une sortie.
Je reste prudent sur les “red flags” car une fonction peut être complexe et légitime. Mais l’absence de besoin clair pour certains appels est déjà un signal.
Cas d’école réalistes: trois scénarios vus en audit
Sans inventer de “preuves miraculeuses”, voici des scénarios typiques qui reviennent en intervention.
1) Shortcode connu, mais fonction modifiée
Le shortcode [gallery] ou un shortcode custom habituel est dans des pages. Le scanner repère un fichier modifié dans un plugin ou un thème. En ouvrant le code, on constate que la fonction du shortcode ne ressemble plus à la version attendue. Elle insère une ressource externe. Le site “a l’air” identique, mais une minorité de visiteurs reçoit la charge.
Dans ce cas, refaire une mise à jour propre peut ne pas suffire si le fichier modifié n’est pas restauré depuis la source officielle, ou si vous remettez le code en place mais que la base contient encore du contenu malformé.
2) Shortcode injecté dans la base sans modification visible côté éditeur
Parfois, vous ne voyez aucun shortcode suspect dans l’interface d’édition. Puis un audit de la base montre une page où une chaîne [something] a été insérée dans un champ. Le shortcode existe peut-être déjà dans un plugin, même “innocent”, mais il est appelé de façon inattendue.
Le résultat peut être une redirection “au moment du rendu”, ce qui rend la contamination difficile à détecter manuellement.
3) Shortcode conditionnel selon utilisateur ou contexte
Le shortcode est “propre”, mais il déclenche une action si un paramètre est présent. Par exemple, un code qui lit $_GET['id'] et renvoie une requête interne. Un attaquant peut alors construire une URL qui active la logique.
Un scanner peut ne rien voir si le déclencheur est spécifique à certains paramètres ou à certains user agents. C’est pour ça qu’on doit parfois simuler le rendu avec des paramètres variés, sans paniquer.
Comment réduire le risque pendant l’analyse
Quand vous explorez des shortcodes suspects, vous n’êtes pas obligé d’exécuter le code malveillant “pour voir”. Vous pouvez limiter l’impact.
Le bon réflexe est de:
- travailler sur une copie du site (au moins en base de données et en fichiers), analyser d’abord le code source, puis confirmer par rendu contrôlé, éviter de déclencher des redirections vers des domaines externes en testant depuis un environnement isolé.
Si vous n’avez pas de staging, vous pouvez faire au minimum un contrôle en lecture du code et n’effectuer que des tests HTML sans comportements lourds, selon la configuration de votre environnement.
Et évitez de supprimer au hasard des shortcodes, parce qu’un plugin légitime pourrait dépendre d’un comportement spécifique. Le but est de casser le mécanisme d’abus, pas d’endommager le rendu.
Procéder au nettoyage: casser la chaîne, pas juste enlever un shortcode
Le nettoyage d’un abus de shortcode ressemble à une enquête: vous identifiez la source, puis vous coupez ses moyens d’agir. Cela inclut souvent la base de données, les fichiers, et parfois la configuration.
Voici une séquence raisonnable, sans prétendre que chaque cas est identique:
Désactivez temporairement les plugins non essentiels et passez le site en maintenance si nécessaire, pour éviter que le rendu n’active le comportement pendant que vous analysez. Restaurez les fichiers modifiés depuis les versions officielles (thème et plugins), en gardant une copie de l’état actuel pour l’analyse. Nettoyez la base si vous trouvez des shortcodes injectés ou du contenu modifié dans des tables liées aux posts, pages et options. Identifiez l’enregistrement add_shortcode concerné et supprimez la logique malveillante, ou remplacez le plugin ou le thème fautif. Vérifiez les droits et la persistance (comptes utilisateurs, scripts d’upload, tâches planifiées), car un shortcode peut être le symptôme, pas la cause unique.Cette approche évite l’erreur classique: “supprimer le shortcode de la page”, alors que le malware est dans le plugin. Le shortcode disparu n’empêche pas le prochain appel si un contenu réinjecté arrive via une autre route.
La checklist d’observation (avant d’écrire du code ou de restaurer)
Une fois que vous avez compris la logique, vous pouvez décider plus finement. Pour garder la tête froide, je recommande une mini méthode en cinq points, que vous pouvez faire en moins d’une heure.
- Repérer exactement quelles pages déclenchent le comportement, et dans quel contexte (connecté, langue, cookies). Noter le ou les shortcodes présents, même si vous ne savez pas encore d’où ils viennent. Identifier le fichier ou le plugin où le shortcode est enregistré (recherche de add_shortcode). Comparer le comportement rendu (HTML final, requêtes réseau) entre environnement sain et environnement suspect si possible. Consigner tout ce qui est modifié (fichiers, options, contenu) pour ne pas tourner en rond.
Cette checklist évite le mode “je restaure et je prie”, et elle accélère l’étape de correction ciblée.
Pièges fréquents: confondre plugin légitime et logique détournée
Le sujet est sensible parce que WordPress encourage les extensions et les shortcodes. Le risque, c’est de “casser” des fonctionnalités légitimes.
Exemples de confusions:
- Un plugin de mise en page utilise des shortcodes pour générer du contenu, mais son code est normal. Si vous voyez un add_shortcode et que vous supprimez tout, vous brisez le site. Un constructeur de pages peut stocker du contenu avec des shortcodes internes. Là encore, le shortcode n’est pas forcément l’infection. Une optimisation performance peut injecter des scripts. Sans analyse, on pourrait prendre cela pour un malware.
La différence se fait sur ce que fait le code et sur ce qui est anormal dans l’environnement. Par exemple, un plugin de galerie ne devrait pas appeler un endpoint externe de contrôle à chaque rendu. Si vous observez ce type de comportement, vous avez une vraie piste.
Comment le diagnostic se combine avec un scanner malware WordPress
Un bon flux de travail https://gardewp.fr/nettoyage-malware-wordpress/ combine scanner et inspection manuelle, sans leur demander de jouer ensemble.
- Utilisez le scanner malware WordPress pour repérer des fichiers potentiellement altérés, des patterns suspects, ou des alertes de configuration. Ensuite, prenez une alerte et cherchez la mécanique: où est le shortcode, quel fichier l’implémente, quels paramètres déclenchent la sortie. Enfin, confirmez le comportement au rendu, avec les outils navigateur et les logs.
J’ai tendance à dire ceci en audit: un scanner vous dit “où regarder”, il ne vous dit pas “pourquoi ça arrive ici”. Les shortcodes sont justement l’endroit où la “pourquoi” compte.
Prévenir la réapparition: durcir sans casser
Une fois le malware retiré, le plus dur commence, éviter la récidive. Les shortcodes abusés reviennent souvent parce que:
- un compte a été compromis, un plugin vulnérable a conservé une porte, un thème contient des modifications non contrôlées, un accès FTP ou l’hébergement a été utilisé comme levier persistant.
Quelques mesures de fond, qui ne dépendent pas du “magic shortcode”:
- mettre à jour thèmes et plugins depuis les sources officielles, limiter les permissions des comptes, vérifier les utilisateurs récemment créés, contrôler les fichiers uploadés en dehors des répertoires attendus, surveiller les tâches planifiées et événements.
Le but est que même si quelqu’un réussit à écrire du contenu, il ne puisse pas transformer ce contenu en exécution contrôlée.
Questions que je me pose avant de valider un cas
Quand vous pensez avoir identifié l’abus d’un shortcode, jetez un œil sur quelques questions qui évitent les faux positifs:
- Le shortcode est-il réellement présent dans le contenu qui déclenche la page, ou est-ce qu’il apparaît uniquement après transformation (filtrage, rendu du builder)? La sortie du shortcode correspond-elle à la logique attendue, en examinant le HTML généré? Les fichiers où le shortcode est implémenté ont-ils une provenance claire, ou bien montrent-ils des signatures de modification? Est-ce que la logique dépend d’un paramètre externe (GET, cookies, headers) qui n’est pas documenté par votre code? Après restauration et nettoyage, le comportement réapparaît-il quand vous rechargez avec un profil visiteur, pas seulement en local?
Cette série de questions est plus utile qu’un sentiment général. Le malware aime les zones grises, votre diagnostic doit aussi être précis.
Conclusion sans formule: où vous gagneriez le plus de temps
L’abus de shortcodes est un type de contamination qui se repère rarement à l’œil nu, et c’est exactement pour ça que ça coûte cher quand on le découvre trop tard. Un scanner malware WordPress peut être un excellent point de départ, mais il ne remplace pas le suivi de la chaîne, de la page au code.
Si vous prenez une seule méthode, gardez celle-ci: identifiez le shortcode dans le contenu, retrouvez son enregistrement PHP, lisez sa logique, puis confirmez au rendu. Cette approche transforme une alerte diffuse en preuve vérifiable, et vous mène vers un nettoyage qui tient.
Si vous voulez, donnez-moi un exemple de shortcode suspect (juste le nom, pas le contenu sensible) et le contexte de la page (builder, thème, plugins). Je peux vous aider à structurer le diagnostic, sans partir sur des suppositions hasardeuses.