Quick Page/Post Redirect : son propre développeur avait caché un backdoor pour piller le SEO de 70 000 sites WordPress

Ce n'est pas un hacker externe qui a trouvé une faille. C'est l'auteur du plugin lui-même qui a inséré un backdoor dans son propre code - dès 2020, via le dépôt officiel WordPress.org. Pendant cinq ans, le plugin Quick Page/Post Redirect a secrètement utilisé les 70 000 sites de ses utilisateurs pour injecter du contenu SEO caché au profit de tiers. Les propriétaires de sites ne voyaient rien. Leurs visiteurs et Google, si. Le mécanisme est dormant depuis que le serveur de commande s'est déconnecté - mais il reste actif, prêt à être réactivé. WordPress.org a retiré le plugin le 14 avril 2026. Si vous l'utilisez, désinstallez-le - une simple mise à jour ne suffit pas. Et faites vérifier votre site par un professionnel si vous l'aviez en version 5.2.1, 5.2.2 ou 5.2.3.

Quick Page/Post Redirect, 70 000 sites

Quick Page/Post Redirect est - ou était - un plugin WordPress de gestion des redirections. Simple, léger, bien noté, plus de 70 000 installations actives. Le genre de plugin qu'un développeur installe lors de la création d'un site, configure une fois, et oublie. Ces plugins-là sont les plus dangereux : personne ne surveille une extension qu'on ne touche plus.

Le plugin était développé et maintenu par "anadnet" - un développeur qui, on le sait aujourd'hui, a intentionnellement transformé son propre plugin en outil de piratage. Ce n'est pas le premier cas de supply chain attack sur WordPress, mais c'est l'un des rares cas documentés où l'auteur légitime est lui-même l'attaquant. Aucun rachat d'entreprise, aucune compromission de compte : juste un développeur qui a décidé de monétiser secrètement la confiance de ses utilisateurs.

La trahison : le développeur contre ses propres utilisateurs

En octobre 2020, "anadnet" a commis un changement dans le code officiel du plugin, publié normalement sur WordPress.org : l'ajout d'un update checker personnalisé. Ce composant avait un seul but - faire chercher les mises à jour du plugin sur anadnet.com plutôt que sur le dépôt officiel de WordPress. Les utilisateurs qui ont mis à jour leur plugin entre fin 2020 et début 2021 ont récupéré ce mécanisme silencieusement.

En février 2021, l'auteur a retiré ce composant du code visible sur WordPress.org - pour éviter que quiconque le remarque lors d'une revue. Mais pour les sites qui avaient déjà installé la version contaminée : trop tard. Le mécanisme était en place. En mars 2021, le serveur w.anadnet.com a poussé la version 5.2.3 directement sur ces sites - sans passer par WordPress.org, sans validation de sécurité, avec des droits administrateur complets.

Cette version 5.2.3 contenait la backdoor active. Elle ne s'est jamais retrouvée dans le dépôt officiel WordPress.org - elle a été livrée en dehors de tout contrôle, uniquement aux sites ayant précédemment installé les versions 5.2.1 ou 5.2.2.

Comment le backdoor fonctionnait

La backdoor de la version 5.2.3 reposait sur deux composants distincts. Le premier est le mécanisme de mise à jour frauduleux lui-même - celui qui permettait à l'auteur de pousser n'importe quel code sur les sites infectés avec des droits admin. C'est la vraie bombe : si anadnet.com revenait sous le contrôle d'un acteur malveillant, chacun des 70 000 sites encore infectés pourrait recevoir du code arbitraire sans aucun avertissement.

Le second composant est un backdoor passif, déjà actif au moment de la compromission. Il utilisait le hook WordPress the_content pour intercepter le contenu des pages au moment de leur génération, et injectait du texte caché en provenance de w.anadnet.com. Ce texte n'était visible que pour les visiteurs non connectés - invisible pour l'administrateur du site, invisible dans l'éditeur WordPress. Impossible à détecter sans inspecter le code source de sa propre page en mode "visiteur anonyme".

Ce que vos visiteurs voyaient sans que vous le sachiez

L'objectif de l'auteur n'était pas de voler des données ni de chiffrer des fichiers. C'était plus subtil , et franchement plus retors : du SEO parasite. En injectant du contenu invisible sur 70 000 sites, il "louait" les positions Google de ses utilisateurs à des tiers, selon les termes d'Austin Ginder qui a découvert l'attaque. Vos pages accumulaient de l'autorité SEO depuis des années ; quelqu'un d'autre en profitait.

Le contenu injecté était conçu pour être indexé par les moteurs de recherche mais invisible pour les visiteurs humains. Les robots de Google, eux, le lisaient - et l'associaient à votre domaine. Sur le long terme, ce type d'injection peut faire apparaître votre site pour des requêtes totalement étrangères à votre activité, voire déclencher des pénalités manuelles de Google si le spam est détecté. Dans les audits SEO que nous menons sur des sites WordPress en difficulté, ce type d'injection cachée est l'une des causes les plus fréquentes de positions inexpliquées ou de chutes soudaines de trafic.

Pourquoi le danger n'est pas terminé

Le serveur w.anadnet.com est actuellement hors ligne. Le backdoor passif est donc dormant - il ne peut plus charger de nouveau contenu depuis le C2 désactivé. Mais "dormant" ne veut pas dire "inoffensif".

Le mécanisme de mise à jour frauduleux, lui, est toujours en place dans le code des sites infectés. Ce mécanisme vérifie régulièrement si anadnet.com a de nouvelles mises à jour à pousser. Si ce domaine était racheté ou repris par un acteur malveillant, ces 70 000 sites recevraient du code arbitraire - ransomware, redirections vers des sites malveillants, vol de données - avec des droits administrateur complets, sans aucune notification. C'est un risque systémique qui ne disparaît qu'avec la désinstallation complète du plugin.

La découverte : 12 sites alertés sur une même flotte

C'est Austin Ginder, fondateur de Anchor, un hébergeur WordPress spécialisé, qui a mis le doigt dessus. Douze sites hébergés sur sa plateforme ont déclenché une alerte de sécurité au même moment - un signal inhabituel qui l'a poussé à creuser. En remontant aux fichiers communs à ces 12 sites, il a isolé le plugin Quick Page/Post Redirect version 5.2.3, puis a reconstitué la chaîne d'événements en analysant l'historique des commits du plugin sur WordPress.org.

Ce travail d'investigation a été transmis à l'équipe de revue de plugins de WordPress.org, qui a officiellement fermé le plugin le 14 avril 2026. Bleeping Computer et CyberSecurityNews ont couvert l'affaire, ainsi que GBHackers et SC Media.

Versions concernées

Ce qu'il faut faire maintenant

Si vous ne savez pas par où commencer ou si vous gérez plusieurs sites, c'est exactement ce que couvre un contrat de maintenance WordPress : surveillance des plugins, détection d'anomalies et réaction rapide quand un plugin est retiré ou compromis.

Chronologie

• 1
  Octobre 2020

  L'auteur "anadnet" intègre un update checker malveillant dans les versions officielles 5.2.1 et 5.2.2, publiées normalement sur WordPress.org. Les sites qui mettent à jour récupèrent le mécanisme frauduleux à leur insu.
• 2
  Février 2021

  L'auteur retire discrètement le composant malveillant du code visible sur WordPress.org pour ne pas se faire repérer. Mais il est déjà installé sur des milliers de sites.
• 3
  Mars 2021

  Le serveur anadnet.com pousse la version 5.2.3 directement sur les sites infectés, contournant WordPress.org. Cette version active le backdoor passif - injection SEO cachée via w.anadnet.com.
• 4
  2021 - 2026

  Le serveur C2 finit par se déconnecter. Le backdoor devient dormant mais le mécanisme de mise à jour malveillant reste actif sur ~70 000 installations. Personne n'a encore détecté l'attaque.
• 5
  Avril 2026

  Austin Ginder (Anchor) détecte l'anomalie sur 12 sites de sa flotte. Il remonte le fil, identifie le plugin responsable, et analyse l'historique des commits pour reconstituer toute la chaîne.
• 6
  14 avril 2026

  WordPress.org ferme officiellement le plugin Quick Page/Post Redirect en attente de revue. Les nouvelles installations sont bloquées. Les 70 000 installations existantes restent en place.

FAQ - Backdoor Quick Page/Post Redirect

Dois-je mettre à jour ou désinstaller le plugin ?

Désinstaller complètement. Une mise à jour ne supprime pas le code malveillant déjà présent. Le mécanisme de mise à jour frauduleux pointant vers anadnet.com reste actif même après une mise à jour vers 5.2.4. La seule solution propre est la désinstallation complète, suivie de l'installation d'une alternative maintenue.

Mon site est-il concerné si j'utilise une version avant 5.2.1 ?

Les versions antérieures à 5.2.1 ne contiennent pas le mécanisme malveillant. Cependant, le plugin étant retiré du dépôt WordPress.org, il ne recevra plus jamais de mises à jour de sécurité. Remplacez-le dans tous les cas par une alternative activement maintenue.

Comment savoir si le backdoor a été actif sur mon site ?

Cherchez dans vos logs serveur des requêtes sortantes vers w.anadnet.com. Dans Google Search Console, vérifiez si des pages de votre site apparaissent pour des requêtes hors de votre thématique. Inspectez aussi le code source de vos pages en mode visiteur non-connecté - cherchez du contenu caché avec display:none ou visibility:hidden.

En quoi c'est différent des autres attaques WordPress ?

La plupart des failles WordPress viennent de bugs de programmation exploités par des tiers. Ici, c'est l'auteur légitime du plugin qui a intentionnellement inséré un mécanisme malveillant dans son propre code et l'a distribué via le dépôt officiel WordPress.org. C'est une trahison directe entre le développeur et ses utilisateurs.

Le danger est-il passé maintenant que WordPress.org a retiré le plugin ?

Pas complètement. Le serveur C2 est hors ligne et le backdoor est dormant, mais le mécanisme de mise à jour malveillant reste fonctionnel sur les ~70 000 installations existantes. Si le domaine anadnet.com revenait sous contrôle malveillant, ces sites pourraient recevoir du code arbitraire avec des droits administrateur. La désinstallation reste la seule protection définitive.

Quand le développeur devient la menace

La plupart des attaques WordPress exploitent des erreurs - un bug de code, une vérification manquante. Ici, il n'y a pas d'erreur. Il y a une décision délibérée. Un développeur a choisi de trahir la confiance de 70 000 utilisateurs pour monétiser secrètement leur travail SEO. Et il a réussi à le faire pendant cinq ans avant d'être repéré.

Ce que cela change, en pratique : même un plugin sans aucun bug documenté peut être dangereux si son auteur ne joue pas le jeu. La réputation d'un plugin ne protège pas contre les actes malveillants de son développeur. C'est l'une des raisons pour lesquelles surveiller les plugins fermés ou abandonnés sur WordPress.org fait partie d'une maintenance WordPress sérieuse. Quand WordPress.org retire un plugin, il y a toujours une raison - et elle mérite d'être traitée rapidement.

Le schéma est différent mais la fenêtre d'exposition suit la même logique que les autres incidents que nous avons documentés cette année - la compromission de 20+ plugins via rachat d'éditeur en est la variante la plus proche. Dans un cas comme dans l'autre, le vecteur d'attaque passe par la chaîne de distribution des plugins - et non par le code de WordPress lui-même.