Backdoor WordPress dans Quick Page Post Redirect que vérifier tout de suite

audit sécurité WordPress avec plugin compromis et checksum WP CLI
5/5 - (1 vote)

Quick Page Post Redirect fait partie de ces extensions WordPress qu’on installe souvent sans trop y penser. Elle gère des redirections de pages, d’articles et d’URL personnalisées. Utile pour garder un site propre, éviter les erreurs 404 et préserver le trafic SEO quand une adresse change.

Sauf que fin avril 2026, ce plugin installé sur plus de 70 000 sites s’est retrouvé au centre d’une vraie alerte sécurité. Austin Ginder, chez Anchor Hosting, a publié une analyse après avoir repéré douze sites avec une version 5.2.3 qui ne correspondait pas au paquet officiel de WordPress.org. Même numéro de version, mais fichier différent. Et côté sécurité WordPress, ce détail change tout.

Le plugin a été fermé temporairement par WordPress.org le 14 avril 2026 pendant son examen. Les sources publiques indiquent que les versions 5.2.1 et 5.2.2 embarquaient un mécanisme de mise à jour tiers pointant vers anadnet.com. Ce canal pouvait fournir un build 5.2.3 altéré, distinct de la version officielle disponible via WordPress.org.

Le problème ne se limite donc pas à une vieille faille corrigée avec un clic sur mettre à jour. Le sujet, ici, c’est l’intégrité du fichier installé. Ton tableau de bord peut afficher une version rassurante, alors que le code présent sur le serveur ne correspond pas à la version saine.

Ce qu’il faut vérifier maintenant
  • Quick Page Post Redirect comptait plus de 70 000 installations actives.
  • Des versions 5.2.1 et 5.2.2 ont embarqué un canal de mise à jour hors WordPress.org.
  • Un build 5.2.3 altéré pouvait injecter du contenu pour les visiteurs non connectés.
  • Le comportement pouvait servir du spam SEO à Googlebot sans apparaître aux admins connectés.
  • Le bon réflexe consiste à vérifier les checksums, pas seulement le numéro de version.

Pourquoi Quick Page Post Redirect inquiète WordPress

D’après l’analyse d’Anchor Hosting, les douze sites contrôlés affichaient Quick Page Post Redirect en version 5.2.3 via WP CLI. Le hash du fichier principal, lui, ne correspondait à aucune version officielle testée depuis les paquets WordPress.org. Le hash MD5 du fichier altéré signalé est ad717da18cf8a2b69899c0d7dafee05a.

Le fichier modifié ajoutait une fonction branchée sur le hook the_content. Cette fonction s’activait pour les visiteurs non connectés, sur les contenus publics, puis tentait de récupérer du contenu depuis w.anadnet.com avant de l’injecter dans la page.

Pour un admin connecté à WordPress, le site peut donc paraître propre. Pour un visiteur non connecté ou pour Googlebot, la page peut servir autre chose. C’est là que le risque SEO devient très concret. On parle d’injection de contenu, de cloaking Googlebot et de spam SEO capable de polluer l’indexation d’un domaine sans être visible depuis le back office.

Ne te fie pas uniquement à la page Extensions. Une version affichée comme correcte peut cacher un fichier modifié si le paquet installé ne vient pas du dépôt officiel.

BleepingComputer et Bitdefender rapportent aussi que l’origine exacte du code doit rester traitée avec prudence. Les analyses confirment le mécanisme et le risque, mais ne permettent pas de trancher publiquement entre ajout volontaire, compte compromis ou autre scénario autour du projet.

Le piège du même numéro de version

Le réflexe classique consiste à regarder la version du plugin. Dans beaucoup de cas, c’est utile. Ici, ce n’est pas suffisant.

Le build altéré portait le numéro 5.2.3, comme une version officielle. Sauf que le fichier n’était pas le même. Une extension peut donc afficher une version connue, tout en contenant du code ajouté ailleurs. Pour ce type d’incident, le numéro de version donne une indication. Le checksum donne une preuve.

La version 5.2.4 propre, récupérée depuis WordPress.org, ne contient pas ce mécanisme selon les tests publiés par Austin Ginder. Mais si ton site a reçu une copie modifiée par le canal tiers, tu dois vérifier le fichier, pas seulement l’écran des extensions.

Astuce rapide
Quand un plugin WordPress a un comportement bizarre, compare ses fichiers avec les checksums officiels avant de chercher uniquement une faille déclarée dans une base CVE.

Le deuxième risque à ne pas rater

Le contenu injecté n’est qu’une partie du dossier. Anchor Hosting signale aussi un deuxième risque lié au système de mise à jour distante.

Les versions concernées embarquaient une bibliothèque de mise à jour tiers et appelaient un endpoint sur anadnet.com. En clair, le plugin pouvait regarder ailleurs que WordPress.org pour recevoir une mise à jour. Ce point est très sensible, car une mise à jour de plugin s’exécute avec des droits élevés dans WordPress.

Même si w.anadnet.com ne répond plus au moment des analyses, le domaine parent restait un point à surveiller. Le souci n’est pas seulement ce qui a été servi en 2021. Le souci, c’est qu’un canal externe a déjà eu la capacité de pousser du code en dehors du circuit WordPress.org.

Les signaux à contrôler sur ton site

Signal Ce que tu contrôles Action utile
Version 5.2.3 Le fichier principal du plugin Comparer le checksum avec WP CLI
Référence à anadnet.com Le dossier du plugin et le fichier PHP principal Supprimer la copie douteuse
Pages propres en admin L’affichage public hors connexion Tester sans session connectée
Extraits Google étranges Search Console et résultats indexés Nettoyer les URL et demander une nouvelle exploration
Fichiers récents inconnus wp-content, mu plugins, wp-config.php et htaccess Chercher une persistance

Comment vérifier ton WordPress sans perdre de temps

Si tu utilises Quick Page Post Redirect, commence par regarder si le dossier quick-pagepost-redirect-plugin existe dans wp-content/plugins. Si oui, ne t’arrête pas à la page Extensions de WordPress.

Avec WP CLI, lance cette commande.

wp plugin verify-checksums quick-pagepost-redirect-plugin

Si le contrôle signale que page_post_redirect_plugin.php ne correspond pas, ton fichier ne colle pas au paquet officiel. Dans ce cas, il faut traiter le site comme potentiellement compromis.

Tu peux aussi rechercher le hash signalé par Anchor Hosting si tu gères plusieurs installations.

find . -path '*/quick-pagepost-redirect-plugin/page_post_redirect_plugin.php' -exec md5sum {} ; | grep ad717da18cf8a2b69899c0d7dafee05a

Sans accès SSH, passe par le gestionnaire de fichiers de l’hébergement ou par FTP. Cherche dans le fichier principal du plugin les références à anadnet.com, w.anadnet.com, un dossier updater, ou une bibliothèque Plugin Update Checker qui ne devrait pas être présente dans une copie propre.

Que faire si ton site est concerné

La réponse la plus saine est de retirer Quick Page Post Redirect, puis de le remplacer par une version propre ou par une alternative maintenue. Avant suppression, exporte tes redirections si le site en dépend. Une redirection perdue peut créer des erreurs, casser des anciens liens et faire perdre du trafic utile.

Après le nettoyage du plugin, contrôle l’index Google. Regarde si des titres, extraits ou pages sans rapport avec ton activité apparaissent dans les résultats. Va aussi dans Search Console pour examiner les requêtes, les pages indexées, les alertes de sécurité et les variations étranges de couverture.

Inspecte aussi les zones sensibles du site. Regarde wp-config.php, les mu plugins, functions.php, .htaccess, wp-content et la table wp_options. Si un site a accepté du code via un canal externe, il peut rester un autre point d’entrée ou une trace de persistance.

Pense aussi au cache. Vide les caches WordPress, serveur et CDN après nettoyage. Si du contenu injecté a été mis en cache, tu peux croire que le fichier est propre alors que des pages publiques servent encore une ancienne version.

  • Priorité un Supprimer ou remplacer le plugin si le checksum échoue.
  • Priorité deux Vérifier Search Console pour repérer du spam SEO ou du cloaking.
  • Priorité trois Contrôler les fichiers sensibles et les entrées suspectes dans la base.
  • Priorité quatre Purger les caches pour éviter de servir une ancienne page injectée.

Pourquoi cette alerte dépasse Quick Page Post Redirect

Quick Page Post Redirect arrive dans un contexte plus large. En avril 2026, Patchstack a documenté la vague EssentialPlugin. Plus de vingt plugins WordPress ont été touchés après un changement de propriétaire, avec une backdoor dormante activée plusieurs mois après son ajout.

Le lien entre ces dossiers n’est pas un code identique. Le signal commun est le risque de chaîne d’approvisionnement. Un plugin connu, ancien, populaire ou installé sur beaucoup de sites peut changer de comportement au fil du temps. Un canal de mise à jour tiers, un changement de mainteneur ou une dépendance externe peut déplacer la confiance hors du dépôt WordPress.org.

Pour ton site, la bonne habitude est simple. Tu dois réduire le nombre de plugins, supprimer ceux qui ne servent plus, vérifier les checksums après une migration ou une restauration, et surveiller les extensions qui reçoivent une mise à jour inattendue après une longue période calme.

Un plugin de redirection touche directement ton SEO. Il peut modifier les URL, influencer l’indexation et changer ce que les visiteurs reçoivent. Quand ce type d’outil est altéré, le nettoyage ne doit pas s’arrêter au fichier PHP. Il faut aussi vérifier ce que Google a vu, ce que les visiteurs ont reçu et ce qui reste dans les résultats.

Maillage utile si tu veux durcir ton WordPress

Si tu as déjà vu des extraits Google en japonais ou en chinois, lis aussi l’article sur le piratage par mots clés japonais WordPress. Si tu viens de nettoyer un site, vérifie ensuite les permissions CHMOD WordPress. Et si ton back office prend des rafales de tentatives de connexion, passe par la méthode pour protéger WordPress des attaques brute force.

FAQ sur Quick Page Post Redirect

Quick Page Post Redirect est il encore dangereux

Si ton site a reçu un build altéré, oui. Vérifie les checksums, inspecte le fichier principal et remplace le plugin par une copie saine ou une alternative maintenue.

Pourquoi Google peut voir du spam que je ne vois pas

Le code signalé s’activait pour les visiteurs non connectés. Un admin connecté peut donc voir une page propre pendant que Googlebot reçoit du contenu injecté.

Une mise à jour suffit elle à régler le problème

Pas toujours. Tu dois vérifier l’intégrité des fichiers, contrôler les zones sensibles du site et regarder si l’index Google contient encore des traces de contenu injecté.