Commentaires WordPress : lien spam ou vraie charge utile
La plupart des commentaires sont du bruit SEO. Une minorité stocke un script ou un HTML actif, parfois déjà approuvé. On modère, on cherche les approuvés suspects, on ferme les articles trop vieux. Akismet aide ici — pas sur un shell PHP.
La plupart sont du bruit. Certains stockent un JS. Modérez, cherchez les commentaires approuvés avec script, fermez les articles trop vieux. Akismet aide ici, pas sur un shell.
Bruit de liens vs vraie charge dans le commentaire
Le spam de commentaires classique : un nom, une URL, une phrase générique. Laid, mauvais pour le SEO si vous approuvez, rarement une exécution. La charge utile : un commentaire déjà approuvé qui contient une balise script, un iframe, un onerror, un shortcode qui charge un fichier. Le front l’exécute pour tous les visiteurs.
Vous n’avez pas besoin d’un cours d’exploitation. Vous avez besoin de lister les commentaires approuvés qui contiennent `<`, `script`, `iframe`, `onerror`, ou un domaine que vous ne reconnaissez pas, puis de les passer en indésirable / corbeille après copie.
Un shell à la racine n’apparaît pas dans les commentaires. Si le site redirige ou sert un kit, cherchez aussi les fichiers. Les commentaires sont un tiroir, pas le meuble.
- Commentaires en attente : traiter en masse (indésirable), ce n’est pas urgent pour l’exécution.
- Commentaires approuvés : audit ciblé.
- Commentaires « à la une » d’un article populaire : priorité.
Où WordPress stocke et affiche
Table des commentaires, champ contenu. Le thème échappe plus ou moins. Un thème nulled ou un page builder qui `echo` sans filtre affiche ce qu’on a voulu éviter. Après incident, testez un article à commentaires sur le front, déconnecté, pas seulement l’admin.
L’avatar et le champ site web du commentateur sont des liens. Moins souvent du JS, souvent du SEO spam. Nettoyez si le volume est absurde.
Les notifications mail (« un nouveau commentaire ») peuvent elles-mêmes être un canal de phishing vers l’admin. Un pic de mails de commentaires n’est pas une preuve de payload ; c’est un indice de bot. Voyez aussi journal d’envoi si le volume SMTP explose — autre cause fréquente : formulaire, pas commentaire.
Les approuvés : le vrai stock à auditer
Filtrez par date autour de l’entrée, par auteur inconnu, par contenu avec chevrons. Exportez avant suppression : preuve. Un commentaire légitime d’un client 2018 avec un `<` dans une cote n’est pas un payload — d’où le tri humain sur les cas limites.
Les commentaires approuvés par un admin fantôme : notez l’heure, c’est une trace de session. Puis utilisateurs.
Multisite et WooCommerce « avis produits » : parfois une autre table / un autre type. Même audit.
Modération et fermeture des vieux fils
Réglages → Discussion : approbation manuelle, lien en attente si l’auteur n’en a pas déjà un, fermer les commentaires après N jours sur les articles. Pour une vitrine d’artisan, souvent : commentaires off partout sauf le blog, et le blog fermé après 14 jours.
Fermer les fils de 2016 ne casse pas le SEO utile. Ça ferme une surface. Les articles « contact » et « devis » n’ont rien à faire avec les commentaires ouverts.
xmlrpc et l’API commentaires : si vous n’en avez pas besoin, réduisez — voir xmlrpc. Pas un substitut à l’audit des approuvés déjà là.
Ce qu’Akismet fait (et ne fait pas)
Akismet classe le spam de commentaires et de formulaires liés. Utile pour le bruit. Il ne retire pas un mu-plugin, ne voit pas un PHP dans uploads, ne remplace pas un changement de mot de passe panel. Pendant l’attaque, l’installer « pour nettoyer » ajoute du bruit ; après, c’est un filet pour ce tiroir-là.
Un commentaire déjà approuvé avant Akismet reste affiché. L’historique ne se réécrit pas tout seul. L’audit manuel (ou une passe ciblée) reste nécessaire une fois.
D’autres antispam (Titan, Wordfence comments) : même limite. On ne leur demande pas un constat d’intrusion.
Quand le « commentaire » n’est pas dans wp_comments
Plugins d’avis (Site Reviews, plugins d’annuaire), Facebook comments, un iframe. L’injection est alors dans le thème, GTM, ou le compte tiers. Comparez à iframe de résa : même réflexe d’URL.
Un shortcode `[commentaire]` custom dans un article : le payload est dans le post. Autre table, même urgence d’affichage.
Les liens injectés dans les articles ne sont pas des commentaires. Ne videz pas wp_comments en croyant les enlever.
Après un incident : réglages utiles
Modération stricte, fermeture automatique, moins d’articles ouverts, Akismet ou équivalent ensuite. Captcha si le bruit revient — après, pas pendant le diagnostic disque.
Rôles : un rédacteur ne devrait pas approuver n’importe quoi. Un admin fantôme a souvent tout approuvé d’un coup : regardez les dates.
Si le HTML du commentaire s’exécute encore après corbeille : cache, ou le thème lit ailleurs. Créer un espace si vous ne trouvez pas l’echo. Premiers gestes : copie avant de vider 10 000 lignes.
Ne pas confondre avec une injection dans l’article
Un script dans post_content n’est pas un commentaire. Un widget pied de page non plus. Trois tiroirs, trois recherches. Vider les commentaires et garder le mu-plugin : le front reste sale.
Safe Browsing se lève sur le contenu servi, pas sur le nombre de spams en attente. Un million de commentaires pending n’est pas une alerte trompeur ; un iframe approuvé sur la home, si.
Restez factuel avec les clients : « nous avons fermé les commentaires et retiré des messages suspects » — pas « le virus était dans les commentaires » si vous n’avez pas vu de payload.