Akismet et anti-spam pendant un incident : utiles sur les commentaires, pas sur un shell
Akismet et les anti-spam filtrent le bruit public des commentaires. Ils ne voient pas un PHP à la racine. Gardez-les s'ils tournent déjà ; n'en attendez pas un nettoyage, et n'en installez pas trois le soir de l'attaque.
Ils filtrent le bruit public. Ils ne voient pas wp-core.php à la racine. Gardez-les, n'en attendez pas un nettoyage.
Ce que ces plugins voient vraiment
Un commentaire, un pingback, parfois un champ de formulaire branché sur la même API. Ils comparent à des listes, des scores, des historiques. C'est utile : ça évite que la vitrine se remplisse de liens pharmacies pendant que vous dormez. Ce n'est pas un antivirus de fichiers, ni un comparateur de zips, ni un lecteur de cron.
Akismet, Antispam Bee, les modules « captcha partout » : même famille de promesse. Chacun réduit le bruit visible. Aucun ne ferme une porte d'administration. Aucun ne dit si `wp-core.php` existe à la racine.
Si votre seul argument « on est protégés » est le badge Akismet, vous n'avez pas d'argument de clôture. Vous avez un filtre de commentaires. C'est déjà ça. Ce n'est pas un dossier de piratage traité.
Ce qu'ils ne verront jamais
Un must-use, une option `siteurl` réécrite, un utilisateur admin, un sitemap pirate, un tag GTM, un skimmer dans le checkout, un voisin de compte. Le commentaire n'est pas le chemin. Le plugin n'est pas sur le chemin.
Ils ne voient pas non plus une page spam IA générée en posts : ce n'est pas un commentaire, c'est un contenu. Ni un cloaking qui ne s'affiche que pour Googlebot.
Wordfence, Sucuri, un scanner en ligne : autre famille, autres limites. On les pose à la fin, comme filet. Pendant l'attaque, ils ajoutent du bruit. Akismet n'est pas dans cette famille : le laisser tourner ne gêne généralement pas. L'installer « en plus » le soir J, si.
- Fichiers à la racine et dans `uploads`.
- Comptes et rôles.
- Sitemaps, GTM, pixels, cron système.
Pendant l'incident : ne pas empiler
Trois anti-spam + un captcha + un firewall plugin + « cleaner » : vous changez le rendu, les hooks, parfois le cache, et vous perdez la chronologie. L'ordre utile reste constater, copier, tourner les accès, traiter la cause. Les premiers gestes n'incluent pas un tour de magasin d'extensions.
Si Akismet est déjà là et actif, laissez-le. S'il n'y est pas, ce n'est pas le moment. Vous n'êtes pas en train de recevoir plus de commentaires ; vous êtes en train de chercher une porte.
Un devis qui commence par « on installe la suite anti-spam » décrit un autre métier. Relisez.
Commentaires, trackbacks, et le vrai payload
Des milliers de commentaires spam le même jour qu'un piratage, ce n'est pas une preuve que l'anti-spam a « lâché ». C'est souvent un bot distinct, opportuniste, sur un site déjà affaibli ou simplement ouvert aux commentaires. Traitez-le comme du bruit : modération, fermeture des commentaires sur les vieux articles si vous n'en avez pas besoin.
Un trackback ou un commentaire qui contient un shortcode ou un HTML actif, c'est autre chose : le contenu publié devient un véhicule. Relisez les réglages « HTML dans les commentaires ». Désactivez ce qui n'est pas indispensable. Voir aussi commentaire avec payload.
Vider la file de modération n'efface pas un PHP. Ne passez pas la nuit là-dessus si Chrome affiche encore une alerte ou si des pharmacies sont en `site:`.
Formulaires : un autre étage
Contact Form 7, Gravity, un formulaire Elementor : l'anti-spam commentaires ne les couvre pas, ou mal. Un formulaire détourné envoie du spam mail, ou collecte. C'est un autre article, un autre contrôle. Formulaire qui envoie du spam.
Un captcha sur le formulaire de contact ne voit pas `xmlrpc.php`. Ne le posez pas comme totem de clôture.
Si le formulaire a pu exfiltrer, le volet données s'ouvre. Akismet n'a rien à dire là-dessus.
Après : à quoi ils servent encore
Une fois le site propre : un anti-spam de commentaires bien réglé évite que la vitrine redevienne un mur de liens. Fermez les commentaires là où ils ne servent pas. C'est de l'hygiène, pas de la garantie.
Ne multipliez pas les services cloud « anti-spam » qui demandent des clés et des webhooks : chaque clé est un secret de plus à révoquer au prochain incident.
La surveillance porte sur fichiers, admins, URL. Pas sur le nombre de commentaires capturés. Un pic de commentaires peut être un signal faible, rarement le premier.
Quand le commentaire est le véhicule
Rare, mais réel : un thème qui affiche le commentaire sans échappement, un plugin qui exécute un shortcode auteur. Là, l'anti-spam aurait peut-être aidé — s'il était déjà là, s'il n'était pas contourné. Après coup, on corrige le thème, on purge les commentaires publiés, on ne « fait confiance » à aucun filtre pour avoir tout vu.
Relisez les articles anciens : liens internes injectés, auteurs fantômes. Liens injectés dans de vieux articles.
Ce n'est toujours pas un shell. C'est un contenu à retirer et une faille de rendu à fermer.
Décider sans se rassurer tout seul
Gardez Akismet s'il est en place et payé. N'en faites pas le récit du nettoyage auprès d'un client ou d'un assureur. Le constat parle de fichiers, de comptes, de sitemaps. Pas du nombre de spams bloqués en 2019.
Si les commentaires sont le seul symptôme visible et que le reste est sain (inspection, `site:`, pas de PHP inconnu), vous avez peut-être « seulement » un problème de modération. Vérifiez quand même comme un visiteur. Le « seulement » se mérite.
Vous pouvez ouvrir un dossier en disant « on a Akismet, ça continue ». Nous ne commencerons pas par le désinstaller. Nous commencerons par l'origine.