Hacked plugin updates backdoored about 1,500 WordPress sites

A paid WordPress plugin became a delivery channel for a backdoor after someone broke into the site that distributes its updates. According to the original report, the developer of Admin Menu Editor Pro found that an unauthorised party uploaded a tampered release, and that a replacement version pushed hours later was also modified because the intruder still had access. Roughly 230 customers and at least 1,500 sites are known to have installed a malicious build, and the real number may be higher.

What happened

Admin Menu Editor Pro is the commercial edition of a plugin used to reorganise the WordPress dashboard, hide plugins and set per-role access rules; the free version is on more than 300,000 sites and does not appear to be affected. The attacker accessed adminmenueditor.com and published version 2.35 containing a file named includes/wp-user-consent.php, which installed a web shell and created a hidden administrator account. The developer, Janis Elsts, says that build was downloadable for roughly seven hours before being pulled, and that the clean 2.36 release he published the same evening was subsequently compromised as well.

The investigation suggests the intruder held root-level access to the server, so the site was taken offline and replaced with a static incident page. Version 2.34 is believed to be clean. Indicators of compromise listed in the report include that wp-user-consent.php file, a new /wp-content/object-cache/ directory, a user in wp_users whose name starts with wp_ and may not appear in the dashboard, and wp_ocache* entries in wp_options. The recommended fix is restoring from a backup taken before 14 September; failing that, removing the plugin, the directory and those database records.

Why it matters

For a small company, a paid plugin from a known author is usually treated as the safer option. This incident shows the failure mode is not the code quality but the distribution channel: auto-updates pulled from a vendor's own server, with no registry review and often no signature to verify. Two compromised releases in one day also mean "update to the latest version" was the wrong instinction for several hours — a hard problem for anyone running unattended updates across a fleet of client sites.

The payload is the kind that survives cleanup: a hidden administrator plus a web shell gives persistent access independent of the plugin itself. Deleting the plugin alone does not close it. And because the vendor site was taken offline, teams cannot rely on the usual channel to confirm which build they have.

What to do

• If you or your clients run Admin Menu Editor Pro, check for the four indicators above now, including the database entries. Do not assume an uncompromised site because the plugin looks normal.
• Where a site is affected, restore from a backup predating 14 September if one exists. Otherwise clean manually, then rotate all administrator passwords, application passwords and any keys or tokens stored in the site.
• Review your update policy for premium plugins that bypass the wordpress.org repository. Staging first, a short delay before production, and file-integrity monitoring on wp-content catch this class of attack better than speed does.
• Keep an inventory of which paid plugins each site uses and where each one updates from. During an incident like this, that list decides whether triage takes an hour or a week.