Admin Menu Editor Pro's own update channel delivered the web shell to 1,500 sites

The write happens at install time. WordPress unpacks the package, the plugin's PHP loads, and `includes/wp-user-consent.php` deploys a web shell ^[4]. It executes with the privileges of the process running WordPress, and that is the only prerequisite the code has: dropping a shell or a persistence hook needs write access to files or the database under those privileges ^[8][9]. A filename like wp-user-consent.php also survives a skim of a plugin directory.

To an administrator, the install looked like a normal plugin update ^[10]. Hidden users may not show up in the dashboard, and the developer's instructions are to query the `wp_users` table directly ^[11]. Automatic updates take the same path as a manual click, so unattended sites pulled the package with nobody watching ^[18].

The account here comes from a dev.to summary of the developer's advisory and BleepingComputer's reporting, dated September 14 and updated September 16, which rates the incident Emergency ^[19].

Version 2.36 is where the standard remedy fails. The developer removed 2.35 and published 2.36, but the distribution infrastructure was still compromised, and malicious code was mixed into some copies of 2.36 as well ^[3]. The version string does not tell you what was in the zip you received. The summary attributes a suspicion of compromised root privileges to the description of the distribution server, and separates that from privileges on customer servers ^[7].

That also breaks hash checking. Digests published by the compromised source cannot establish that a package is safe, and the summary marks this as its own inference rather than reported fact; it points to comparison against a trusted source independent of the compromise, or staged rollouts, as what limits how far a bad build spreads ^[13].

Roughly 1,500 sites across about 230 customers works out to about 6.5 sites per customer ^[2][21]. Remediation is per site. The developer's guidance is to remove 2.35 and 2.36, recover from a backup created before September 14 where one exists, and change credentials ^[6][23].

Shells and persistence written elsewhere survive deletion of the plugin ^[17]. A WAF can block the attacker's HTTP requests and still leave the code that already ran during the update, and the users created at that moment, in place, again per the summary's analysis ^[14].

The developer's position is that sites where a web shell was deployed should be handled as if the attacker had full control ^[12]. Restoring a backup does not revoke information already taken ^[15]. The scope of that theft has not been publicly disclosed ^[16].