---
title: "Admin Menu Editor Pro Backdoor: How to Save Your Site Now"
slug: "admin-menu-editor-pro-backdoor"
description: "Admin Menu Editor Pro 2.35 and 2.36 shipped a web shell and a hidden admin. There's no clean download yet. Check, clean and roll back your site step by step."
date: 2026-09-18
modified: 2026-09-18
author: "WP Vanguard Team"
category: "News"
tags: ["admin-menu-editor-pro-backdoor", "supply-chain-attack", "admin-menu-editor-pro", "web-shell", "incident-response"]
featured_image: "/images/blog/admin-menu-editor-pro-backdoor.jpg"
---

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_options` whose names start with `wp_ocache` or `_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](/blog/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:

```bash
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:

```bash
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:

1. Deactivate and delete the Admin Menu Editor Pro folder.
2. Delete the `_wp_cconsent_tick` cron event: `wp cron event delete _wp_cconsent_tick`.
3. Delete the `wp-content/object-cache/` directory and any `wp-*` hex-named files in `mu-plugins`.
4. Delete the `wp_ocache` and `_wp_ocache_` options.
5. 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:

```bash
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](/blog/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.php` to match
- rotate any API keys or tokens defined in `wp-config.php` or 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](/blog/nulled-wordpress-plugins-risks).

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](/blog/verify-wordpress-plugin-update-supply-chain). This is at least the fourth premium plugin this year compromised through its own update channel, after [Smart Slider 3 Pro](/blog/smart-slider-3-pro-backdoor-nextend-compromise) in April and [Fluent Forms Pro and Ninja Tables Pro](/blog/fluent-forms-ninja-tables-supply-chain-backdoor) 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](/#scanner) to see where you stand.

## References

- [Admin Menu Editor Pro: Security incident affecting customers, 2026-09-14](https://adminmenueditor.com/blog/security-incident-affecting-customers-2026-09-14/)
- [BleepingComputer: Malicious Admin Menu Editor Pro plugin backdoors 1,500 WordPress sites](https://www.bleepingcomputer.com/news/security/malcious-admin-menu-editor-pro-plugin-backdoors-1-500-wordpress-sites/)
- [Wordfence Intelligence: Admin Menu Editor Pro 2.35 - 2.36 - Backdoored Software](https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/admin-menu-editor-pro)