Security1 publisher2 min readPublished
Attacker with root on the Admin Menu Editor site poisoned the fix as well as the original update
Janis Elsts pulled the trojanised Admin Menu Editor Pro 2.35 after about seven hours and shipped 2.36 at 19:00 UTC. The intruder still held his server and backdoored that build too. At least 230 customers took the first one.
The Watch · Security desk

What happened
- Janis Elsts says an unauthorized party got into adminmenueditor.com on Monday and uploaded Admin Menu Editor Pro 2.35 as an update for the plugin's paid version.
- The developer's update server logs put the initial attack at 230 customers and at least 1,500 sites, with several hundred more customers downloading in or near the same window.
- The investigation points to root-level server access, and Elsts pulled the website offline and replaced it with a static page carrying the indicators and cleanup steps.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The hidden wp_ account and the object-cache web shell survive a plugin upgrade, so every one of the 1,500 sites stays reachable to the attacker until somebody reads the wp_users and wp_options tables.
- constraint Operators cannot use the version string to sort a clean 2.36 from a tainted one, and neither can the developer, who says he cannot count the customers running the trojanised build.
- decision Sites without a backup predating September 14 have to choose manual surgery on the database and filesystem, and then decide whether to treat every admin credential on the site as exposed.
- precedent Shipping the fix six hours after pulling the bad build, while the intruder still held root, re-infected the same customers. Eviction has to be confirmed before a replacement release goes out.
Deleting the plugin does not end this. The malicious code in 2.35 wrote includes/wp-user-consent.php into the admin-menu-editor-pro directory and installed a web shell from there [3], and it created a user account whose name begins with wp_ in the wp_users table, which may not show up in the dashboard user list [4]. Two of the four indicators Elsts lists sit outside the plugin directory: a new /wp-content/object-cache/ directory, and options named wp_ocache* in wp_options [5].
The scope figures come from the developer's own update server logs. "Based on analysis of update server logs, approximately 230 customers were affected in the initial attack. The malicious version was installed at least 1500 sites (often multiple sites per customer)," Elsts told BleepingComputer [9]. That is roughly 6.5 sites per affected customer [2].
The first window was short. Version 2.35 sat on the official site from about 06:00 to 13:00 UTC [6], seven hours [1]. Elsts pulled it and pushed a clean 2.36 at 19:00 UTC the same day [7], six hours after the removal [3]. The attacker still had access to the website and compromised that build as well [8]. The investigation indicates root-level server access [13], and Elsts took the site offline until it could be restored with confidence [13].
How many sites took the tainted 2.36 is unsettled. Elsts says it is difficult to determine how many customers are running a trojanised 2.36, so the victim count may be higher than 1,500 [12]. "Several hundred additional customers downloaded the plugin in or near the relevant time window, and could have also been affected," he said [11]. Both builds reached customers through the plugin's normal Pro update channel on adminmenueditor.com [1], so a site that shows 2.36 in its plugin list has told the operator nothing about which 2.36 it got. The four indicators are the test.
The 300,000-plus install figure attached to this plugin belongs to the free Admin Menu Editor, which does not appear affected [16][15]. Version 2.34 is believed clean [15]. The exposed population is Pro licences that pulled an update on Monday [2].
Elsts calls a restore from a backup dated before September 14 the most reliable fix [17]. Where no such backup exists, he recommends deleting the plugin, the /wp-content/object-cache/ directory and the database entries listed above [18]. That leaves the hidden account and any use made of the web shell as the open question for every site in the 1,500 [10]. Elsts said the incident was limited to his own infrastructure and apologised to affected customers [19], and has published a static page with the indicators and cleanup steps [14].
What to watch
- Whether adminmenueditor.com returns with a stated time at which the root-level access was evicted from the server.
- A revised victim count for the trojanised 2.36, which Elsts currently cannot separate from ordinary downloads in the same window.
- Any report of the web shell being used for more than the hidden account, such as spam injection or movement into other accounts on shared hosting.