Supply Chain · Vendor Access

Malicious Admin Menu Editor Pro Plugin Backdoors 1,500 WordPress Sites

September 16, 2026 · 5 min read

On September 14, 2026, an attacker with what appears to have been root-level access to the adminmenueditor.com server swapped in a poisoned build of Admin Menu Editor Pro and let the plugin's own auto-update machinery carry it to customer sites. The window was roughly seven hours, from about 06:00 to 13:00 UTC. That was enough time for approximately 230 customers to pull the malicious version, spreading the payload across at least 1,500 WordPress installations. When the update channel itself is the delivery mechanism, your perimeter controls are largely spectators.

What actually happened

Admin Menu Editor Pro is the paid tier of a plugin that roughly 300,000 WordPress sites rely on to customize dashboard menus, hide plugins from lower-privileged users, and configure per-role access rules. Developer Jānis Elsts, operating under IK Gling, distributes updates through adminmenueditor.com. On September 14, 2026, an unauthorized party accessed that server and replaced the legitimate version 2.35 package with a trojanized build.

The malicious package carried a file at includes/wp-user-consent.php. When a site owner updated the plugin, that file installed a web shell and created a hidden WordPress administrator account. The attacker would then have persistent, privileged access to any affected site, independent of the site owner's own credentials or security hardening.

Elsts detected the intrusion the same day, pulled the compromised package, and pushed a clean version 2.36 at 19:00 UTC. The investigation indicated the attacker likely had root-level access to the distribution server, which led Elsts to take the entire adminmenueditor.com site offline rather than risk serving further tampered files. A static incident-notice page was published in its place.

"Several hundred additional customers downloaded the plugin in or near the relevant time window, and could have also been affected." — Jānis Elsts, developer of Admin Menu Editor Pro

Based on update-server log analysis, about 230 customers confirmed as having installed version 2.35, but those customers collectively manage an estimated 1,500 or more individual WordPress sites. The true blast radius may be larger given the additional downloads in the surrounding time window.

Why this should matter to you even if you don’t run Admin Menu Editor Pro

If your organization runs WordPress, this incident deserves attention regardless of whether Admin Menu Editor Pro is in your stack. The attack pattern here is a vendor's authenticated distribution channel turned against its own customers. Your firewall, your WAF, your endpoint agent: none of those controls are positioned to catch a malicious file arriving as a signed, expected plugin update from a vendor you trust. The trust relationship is the vulnerability.

Premium WordPress plugins represent a category of third-party software that sits in an interesting blind spot for many security programs. They are often managed by a developer or an agency rather than a central IT function, they update frequently and often automatically, and they carry significant privilege on the server where WordPress runs. An attacker who can modify even one file in one update package can land a persistent foothold on every customer site that auto-updates before the vendor notices.

The scale also warrants attention. A single compromised update reaching 230 customers expanded to at least 1,500 affected sites. Organizations that manage WordPress sites on behalf of clients, hosting providers, and digital agencies face a multiplier effect that a traditional software breach does not produce in the same way. One poisoned package, many victims, and each victim may have their own downstream exposure.

Cyber insurers are increasingly asking about third-party and vendor software controls. An incident like this one, where the attack arrives through a trusted update mechanism, tests whether your policy actually covers supply-chain compromise and whether you have the asset inventory to even know you were affected.

The control that would have blunted it

The specific control that would have reduced exposure here is vendor access governance combined with staged update deployment. In practical terms, that means treating plugin updates, especially updates to plugins with server-level or admin-level privilege, as a change that requires review before it reaches production. Auto-update is convenient and genuinely useful for security patches, but it removes the inspection step that would catch a trojanized package.

For WordPress environments, staged deployment looks like this: updates land first in a staging environment that mirrors production, automated or manual verification runs against the new package, and promotion to production happens after a defined window. Seven hours is a short window, and a purely manual process might not catch everything, but staged deployment combined with file-integrity monitoring on the WordPress installation directory would surface an unexpected new file like wp-user-consent.php before it executes in a live environment.

File-integrity monitoring deserves particular emphasis here. A web shell dropped into a plugin's subdirectory is exactly what FIM is designed to detect. If you have a known-good baseline of your WordPress file tree and an alert fires when a new PHP file appears in a plugin directory, you have a detection opportunity even if the update slipped through staging. The operational cost is real: FIM generates noise, baselines drift as plugins legitimately update, and tuning takes ongoing effort. That tradeoff is worth accepting for environments where WordPress runs business-critical or client-facing applications.

Cyber insurers commonly ask about vendor access controls, software inventory, and change management processes during underwriting and claims review. The ability to answer "yes, we run staged updates and file-integrity monitoring on our web applications" directly maps to controls that reduce the likelihood and severity of a supply-chain compromise. Beyond the insurance question, those controls also give you the audit trail to determine quickly whether you were in the affected window, which is the first thing you need to know when an incident like this is disclosed.

Privileged account auditing is the other control worth naming. The malicious payload created a hidden WordPress administrator account. If you run regular audits of administrator-level accounts and alert on new account creation in that role, you have a second detection layer even if the file-integrity monitoring missed the initial file drop. Neither control is a guarantee, but two independent detection opportunities are meaningfully better than one.

Strondex's Vendor Access product helps organizations inventory and govern third-party software access, including plugin-level privilege in web application environments, so you have the visibility to act when a vendor's update channel is compromised.