Admin Menu Editor Pro Backdoor: How to Save Your Site Now
By WP Vanguard Team
On September 14, 2026, an attacker got into the server behind adminmenueditor.com and published Admin Menu Editor Pro 2.35 with a web shell inside it. The developer pulled it and shipped a clean 2.36 that evening. The attacker still had access, so 2.36 got backdoored too. By the developer's own count, about 230 customers installed the bad build on at least 1,500 sites, and several hundred more downloaded the plugin close to the window.
That second compromise changes the usual advice. With most plugin flaws you update to the fixed version and move on. Here the fixed version was part of the attack, and the vendor's site is still offline, so there's no clean download to update to. If you run Admin Menu Editor Pro, you're rolling back and cleaning up on your own. This post is the order to do it in.
What the Admin Menu Editor Pro backdoor does
The tampered build adds one file, includes/wp-user-consent.php, inside the plugin folder. It doesn't sit there as a single backdoor. It spreads itself across the site so that deleting the plugin doesn't remove it. The developer's incident notice lists what it leaves behind:
- a
wp-content/object-cache/directory with hex-named subfolders holding PHP web shells - a hidden administrator whose login is
wp_followed by hex characters - options in
wp_optionswhose names start withwp_ocacheor_wp_ocache_ - must-use plugins named
wp-followed by hex characters - a WP-Cron event called
_wp_cconsent_tick
The directory name is chosen to blend in. Plenty of sites have a legitimate wp-content/object-cache.php drop-in for Redis or Memcached. A directory called object-cache isn't something any caching plugin we know of creates, and it's the fastest single tell.
Each piece is a separate way back in. The web shells run commands, the hidden admin logs in, the mu-plugins load on every request whether or not the plugin exists, and the cron event can put things back after you remove them. That's the standard persistence kit we describe in PHP backdoors in WordPress, and it's why partial cleanups fail.
Timeline of the compromise
The developer, Janis Elsts, has published a running incident log. The short version:
| When (UTC) | What happened |
|---|---|
| Sep 14, morning | Tampered 2.35 published through the normal update channel |
| Sep 14, ~13:00 | 2.35 pulled from the site |
| Sep 14, ~19:00 | Clean 2.36 released, then tampered by the attacker who still had access |
| Sep 14, evening | Server taken offline; the developer believes the attacker may have had root |
| Sep 15 | Notices sent to affected customers |
The developer considers 2.34 and earlier clean, and says the free Admin Menu Editor on wordpress.org shows no sign of compromise. Wordfence lists the Pro builds as critical (CVSS 9.8) with no patched version, and no CVE has been assigned.
Why agencies should check first
230 customers on 1,500 sites is six or seven sites per customer. That matches who buys this plugin: agencies and freelancers who use it to trim the dashboard for clients. One agency licence that auto-updated on September 14 can mean a dozen client sites with the same hidden admin.
If you manage client sites, don't start with the one that feels important. Start with an inventory of every site running Admin Menu Editor Pro and which version each one has. The next section shows how to check each one.
Step 1: find out whether you ran 2.35 or 2.36
Check the installed version:
wp plugin get admin-menu-editor-pro --field=version
If it says 2.34 or lower and auto-updates were off, you're very likely fine. Turn auto-updates off for this plugin now and skip to the last section.
If it says 2.35 or 2.36, or you're not sure what it said on September 14, treat the site as compromised. The plugin being on 2.34 today doesn't prove it never ran a bad build, so check for the leftovers too:
ls -la wp-content/object-cache/ 2>/dev/null
ls wp-content/mu-plugins/ | grep -E '^wp-[0-9a-f]+'
wp cron event list --fields=hook,next_run | grep cconsent
wp db query "SELECT option_name FROM $(wp db prefix)options WHERE option_name LIKE 'wp\_ocache%' OR option_name LIKE '\_wp\_ocache\_%'"
wp db query "SELECT ID, user_login, user_registered FROM $(wp db prefix)users WHERE user_login REGEXP '^wp_[0-9a-f]+$'"
The last query goes to the database directly on purpose. The admin is described as hidden, and a backdoor that hides a user from the Users screen can hide it from wp user list too. SQL doesn't go through those filters. Any hit from any of these commands means you're in the cleanup path.
Step 2: restore a backup from before September 14
A backup taken before September 14 is the cleanest fix, and it's the developer's first recommendation. It removes every piece of the kit at once, including anything that isn't on the published list.
Restoring files and database together is what counts. If you only restore files, the hidden user, options and cron event stay in the database. If you only restore the database, the shells stay on disk.
A restore rolls the plugin back to whatever version was in the backup, which should be 2.34 or earlier. Turn auto-updates off for it straight away, or the site will try to pull a new version the moment the vendor's server comes back.
Then go to step 4. A restore puts the site back, but it doesn't change the passwords and keys the attacker may have copied while they had access.
Step 3: clean it by hand if you have no backup
If there's no usable backup, work through the developer's list in this order so nothing can put itself back while you work:
- Deactivate and delete the Admin Menu Editor Pro folder.
- Delete the
_wp_cconsent_tickcron event:wp cron event delete _wp_cconsent_tick. - Delete the
wp-content/object-cache/directory and anywp-*hex-named files inmu-plugins. - Delete the
wp_ocacheand_wp_ocache_options. - Delete the hidden
wp_user, and reassign its content to a real admin if it has any.
Then look for anything the list doesn't cover. Web shells often drop more web shells. List every PHP file changed since the compromise started:
find . -name '*.php' -newermt 2026-09-13 -not -path './wp-content/cache/*'
Compare what comes back against what you expect from your own updates that week. The full process, including core and plugin checksum checks, is in our WordPress malware removal guide.
Step 4: rotate everything the shell could read
A web shell runs as your site's PHP user, so assume it read wp-config.php. That file holds your database password, your security salts, and often API keys for SMTP, payments or storage. After the cleanup:
- change every WordPress user's password, starting with administrators
- regenerate the salts in
wp-config.php(wp config shuffle-salts), which logs everyone out - change the database password at your host and update
wp-config.phpto match - rotate any API keys or tokens defined in
wp-config.phpor stored in plugin settings
Skipping this step is how sites get reinfected a week later through a password that was never changed.
Getting a clean copy of the plugin
There isn't one yet. The vendor's site is offline, and customers asking for clean downloads have been told to wait. Until the developer publishes a verified release, you've got two safe options: run 2.34 from your own backup, or leave the plugin removed. Removing it puts the default admin menu back for your users, and nothing else on the site breaks.
Don't grab a copy from a download mirror or "GPL club" site to fill the gap. You'd be swapping a known backdoor for an unknown one, which is exactly the risk we cover in nulled WordPress plugins.
When a new release does ship, don't let it auto-update. Install it by hand and check it before it runs, using the steps in how to verify a WordPress plugin update is genuine. This is at least the fourth premium plugin this year compromised through its own update channel, after Smart Slider 3 Pro in April and Fluent Forms Pro and Ninja Tables Pro in July.
Check your site
WP Vanguard's surface scan flags Admin Menu Editor Pro 2.35 and 2.36 when it can detect the plugin version from outside. The deep scan works over SSH and checks for every piece of this kit: PHP inside wp-content/object-cache/, unfamiliar mu-plugins, the _wp_cconsent_tick cron event, and administrators that exist in the database but are hidden from WP-CLI and the Users screen. That last check compares the users table against what WordPress reports, so it catches hidden admins from other backdoors too. Run a free scan to see where you stand.
References
Related reading
Check Your WordPress Site Security
Free scan, no login required. Find vulnerabilities before attackers do.
Scan Your Site FreeGet weekly WordPress security tips
Vulnerability alerts, plugin updates, and security guides. No spam. Unsubscribe any time.