A Trusted Update Channel Turned Into a Backdoor Delivery System
A threat actor compromised the website behind Admin Menu Editor Pro, a premium WordPress plugin used to customize the wp-admin navigation menu, and abused the maintainer's own update infrastructure to push malicious releases directly to paying customers. The tampered versions silently planted a web shell and created a hidden administrator-style account on every site that auto-updated during the attack window — turning a routine plugin update into a full site compromise with no action required from the site owner.
At least 230 customers and roughly 1,500 WordPress sites are confirmed affected, and the real number may be higher since some customers who downloaded the plugin during the compromise window have not yet been accounted for.
Incident Overview
| Field | Value |
|---|---|
| Plugin | Admin Menu Editor Pro (premium) |
| Affected versions | 2.35, 2.36 |
| Last known-clean version | 2.34 |
| Free "Admin Menu Editor" plugin | Not affected |
| Attack vector | Compromised developer website / update server |
| Payload | includes/wp-user-consent.php web shell + hidden admin-level user |
| Customers affected | 230+ (minimum) |
| Sites compromised | 1,500+ |
| Attack window | September 14, 2026, ~06:00–13:00 UTC |
| Developer response | Malicious update pulled, v2.36 shipped ~19:00 UTC same day |
| Complication | Attacker re-compromised v2.36 after the first fix |
How the Developer's Site Was Compromised
According to reporting, an unauthorized party gained root-level access to the server hosting adminmenueditor.com — the site plugin developer Jānis Elsts uses to distribute updates to Admin Menu Editor Pro customers. With that level of access, the attacker was able to replace the legitimate 2.35 release package with a trojanized build and push it out through the plugin's normal auto-update mechanism, meaning affected sites received the backdoor exactly the way they'd receive any routine security patch.
The free, non-Pro "Admin Menu Editor" plugin listed on the official WordPress.org repository was not part of this incident — the compromise was limited to the Pro edition's independent distribution channel.
What makes this incident notable is that root-level server access let the attacker persist even after the developer responded. When the malicious 2.35 build was discovered and pulled, the team shipped version 2.36 as a clean replacement — but the attacker still had a foothold on the update server and re-compromised that release as well, extending the exposure window for customers who updated after the initial incident was supposedly resolved.
The Malicious Payload: A Hidden Admin Backdoor
The trojanized package dropped a new file, includes/wp-user-consent.php, into the plugin directory. Despite its innocuous name (styled to resemble a GDPR/cookie-consent helper), the file functioned as a web shell, giving the attacker a way to execute arbitrary code on any site running the malicious update.
Alongside the web shell, the payload created a hidden WordPress user account with a username beginning with the prefix wp_ — designed to blend in with legitimate WordPress-internal naming conventions and avoid catching a site owner's eye in the Users list. Combined with related cache-object storage under /wp-content/object-cache/ and options rows prefixed wp_ocache, the backdoor gave the attacker a durable, low-visibility way to regain administrative control of a site even if the plugin itself were later removed.
This pattern — a disguised file plus a deliberately unremarkable hidden admin account — mirrors a broader trend in recent WordPress supply-chain incidents, where attackers optimize for persistence and stealth rather than a single smash-and-grab payload.
Scale and Timeline
- ~06:00–13:00 UTC, September 14, 2026 — Malicious version 2.35 distributed through the plugin's update channel
- ~19:00 UTC, September 14, 2026 — Developer pulls the compromised release and ships version 2.36 as a fix
- Shortly after — Attacker, still holding access to the update server, re-compromises version 2.36
- Ongoing — At least 230 customers and roughly 1,500 sites confirmed affected; the true count may be higher among customers who updated during the exposure window but have not yet checked for indicators of compromise
Because both the "vulnerable" and the "fixed" releases were tampered with, customers who updated at any point on September 14 should treat their site as potentially compromised regardless of which version they currently have installed.
Indicators of Compromise
Site owners running Admin Menu Editor Pro should check for the following artifacts:
- The file
includes/wp-user-consent.phpinside the plugin directory - A
/wp-content/object-cache/directory that shouldn't otherwise be present - Unfamiliar WordPress user accounts with usernames starting with
wp_ - Rows in the
wp_optionsdatabase table namedwp_ocache*
Finding any of these on a site that runs Admin Menu Editor Pro version 2.35 or 2.36 (or that updated to either version on September 14, 2026) should be treated as confirmation of compromise.
What Site Owners Should Do
- Check plugin version. Confirm whether the site is or was running version 2.35 or 2.36, and whether an update occurred on September 14, 2026.
- Scan for the indicators above — the web shell file, the object-cache directory, hidden
wp_-prefixed user accounts, andwp_ocache*options rows. - Restore from a clean backup taken before September 14, 2026 wherever possible. Because the attacker had root-level access to the update server, simply deleting the malicious file is not a reliable guarantee that no other backdoor was planted.
- If no clean backup exists, manually delete the plugin, remove the
/wp-content/object-cache/directory, and delete the suspicious database entries described above — then treat the site as needing a fuller compromise assessment (rotate credentials, review other admin accounts, check for additional unfamiliar files). - Rotate WordPress admin credentials and API keys on any affected site as a precaution, since a web shell grants code execution broad enough to have harvested secrets beyond the hidden account itself.
- Hold off on updating again until the developer confirms the update infrastructure itself has been fully secured, given that the "fixed" 2.36 build was also compromised.