WordPress security alert the hidden backdoor of the Quick Page / Post Redirect plugin that still threatens thousands of sites

A backdoor implanted years ago in the Quick Page / Post Redirect plugin - installed on tens of thousands of WordPress sites - turns an apparently harmless utility into a gateway for arbitrary code injection and SEO spam operations. Researcher Austin Ginder, founder of the Anchor hosting, detected the campaign after several alerts on his platform and documented how old official versions of the plugin contained a hidden self-update mechanism that consulted an external server, allowing to replace or inject code outside the control of the official repository.

The threat combines two dangerous vectors: a "silent" update from a server other than WordPress.org and a backdoor that is activated only for disconnected users, making it difficult to detect by administrators. According to the analysis, versions 5.2.1 and 5.2.2 included the malicious logic that pointed to anadnet [.] com; in March 2021 a 5.2.3 build was used from that infrastructure with a different hash than that of the same version on WordPress.org, and that build added a hacked code to the _ content to inject payloads oriented to SEO spam.

The real risk is not just the visible spam: the remote self-update mechanism allowed you to run arbitrary code on demand. Although today that control subdomain is not solving for all facilities, that "door" is still present in the affected sites and can be reactivated if the actor behind the domain reenables it or if the infrastructure changes hands. WordPress.org has temporarily removed the plugin from the directory for review, but while there are facilities with the update pointing to the external server the risk remains.

If you manage a WordPress, the first immediate measure is to check if you have Quick Page / Post Redirect installed and which version runs. If your installation is in the compromised versions (5.2.1 or 5.2.2) or a copy that could have been updated from that external server, uninstall the plugin and do not trust previous local copies without checking them. Replace it with a clean version directly from WordPress.org when it is published (it was pointed at 5.2.4 as an arrangement) is the recommended action, but not the only one: the presence of a malicious auto- update requires complete cleaning and verification of site integrity.

In addition to uninstalling and reinstalling from a verified source, it is essential to audit site files in search of back doors. Check recently modified files, compare hashes to the official repository when possible, search for outgoing calls to anadnet or related subdomains in the code and HTTP logs, and remove any suspicious file or crontab. Rotate administrative credentials, change API keys that could have been stored on the site and review administrative users to detect unauthorized accounts.

Do not trust only the disappearance of C2: it takes defensive measures at the network level and hosting by blocking malicious domains and subdomains (e.g. in the server firewall or hosts) and activates a WAF or blocking rules in your supplier. Run scans with specialized WordPress tools and consider asking your hosting for a forensic analysis if you detect signs of engagement. To start with scans and cleaning you can consult public resources from security providers specialized in WordPress, such as Wordfence https: / / www.wordfence.com / o reports and guide of the discoverer himself in Anchor https: / / anchor.host / the-plugin-author-was-the-supply-chain-attacker /.

This incident highlights a major lesson about the plugin supply chain: confidence in the official repository does not eliminate the risk of hidden modifications if there is an update mechanism outside the controlled ecosystem. Plugin maintainers should avoid any self-uppater that depends on unverified external servers and review teams need tools and processes that detect remote update manifests and hash differences between identical buildings.

For advanced developers and administrators, it is recommended to implement an integrity control policy (file integrity monitoring), block dangerous PHP functions when they are not necessary, and audit third party dependencies on a regular basis. For business managers and editors, the suggestion is to prioritize plugins actively maintained with good reputation, review change history and, in critical environments, evaluate the use of internal repositories or payment solutions with commercial guarantees and technical support.

Vulnerability in Quick Page / Post Redirect is a reminder that a small plugin can become a large-scale risk multiplier. It acts quickly: it identifies affected facilities, makes comprehensive cleaning or restores from clean copies, blocks the malicious infrastructure and strengthens controls to prevent a similar incident from happening again. For more context on how to handle plugin commitments and response measures, the official WordPress plugin page can serve as a starting point: https: / / wordpress.org / plugins /.