Admin Menu Editor Pro Update Vector Compromise: Web Shell and Hidden Administrator Distributed

1. Basic Information

• Original Title: Security Incident Affecting Customers 2026-09-14
• Source: Admin Menu Editor Pro and BleepingComputer
• Publication Date: 2026-09-14
• Update Date: 2026-09-16
• Severity: Emergency
• Severity Justification: A malicious plugin was distributed through the official update channel, and traces of web shells and hidden users were reported on customer sites. Version 2.36, published as a clean version, was also tampered with, and root privileges may have been compromised on the distribution server.
• Original Link: Security Incident Affecting Customers 2026-09-14
• Related Source: BleepingComputer: Malicious Admin Menu Editor Pro plugin backdoors 1,500 WordPress sites
• Related Entities: Web shell, Admin Menu Editor Pro, WordPress

2. Executive Summary

The official distribution infrastructure of Admin Menu Editor Pro was compromised, and code that deploys a web shell was mixed into version 2.35 and some instances of version 2.36. Initial reports indicated deployment to approximately 230 customers and 1,500 sites, and the developer recommends recovery from pre-compromise backups and changing credentials.

3. Attack Flow

Flow 1: Supply Chain Compromise Using Official Plugin Updates

1. An attacker breaches the official distribution infrastructure and places malicious version 2.35 as an update package.
2. An administrator or the automatic update feature downloads and installs the package.
3. Once the malicious code inside the plugin executes, includes/wp-user-consent.php deploys a web shell.
4. On compromised sites, traces of persistence have been reported, including hidden users, PHP files, database options, MU plugins, and WP-Cron. The same behavior has not been confirmed across all installations.
5. Even after the developer removed version 2.35 and published version 2.36, the distribution infrastructure compromise persisted, and malicious code was also mixed into some instances of version 2.36.

4. Attacker Position and Execution Location

• The attacker has compromised the plugin developer's distribution server.
• On customer sites, the mixed-in PHP code runs with the privileges of the process executing WordPress.
• The suspicion of compromised root privileges comes from the distribution server description and is distinct from customer server privileges.

5. Visibility for Victims and Administrators

Victims

• Inference: General site users may not see the update process and might notice no screen anomalies after the compromise.

Administrators

• The update appeared as a normal plugin update to administrators. Hidden users may not be visible in the admin dashboard, but the developer provides instructions on how to directly check the wp_users table.
• Even if the plugin is deleted, web shells or traces of persistence placed in other locations may remain.

6. Success and Failure Conditions

Success Conditions

• The modified version 2.35 or 2.36 is installed, and the malicious code executes on WordPress. Downloading and execution are distinguished.
• Deploying web shells or persistence requires write access to the target files or database with WordPress execution privileges.
• During the phase of operating the web shell via HTTP, requests from the attacker must reach the deployment destination and execute as PHP. Stopping this communication does not rule out the execution of malicious code or the creation of hidden users during installation.

Failure Conditions

• The developer recommends removing versions 2.35 and 2.36 and, if possible, recovering from backups created before September 14. Recovery is a post-compromise response and does not revoke past information theft.
• Inference: Package verification by a trusted comparison source independent of the compromise source, or finding modifications through staged updates, can limit the expansion of deployment. Hashes provided by the same compromised source cannot guarantee safety.
• Inference: While WAFs may block suspicious HTTP requests to deployed web shells, they do not necessarily prevent code execution within the server associated with plugin updates. File write and execution controls must be verified on the server side.

7. What Happens Upon Success

• The developer recommends responding as if the attacker gained full control of the site on sites where a web shell was deployed.
• Access may persist even after deleting the plugin due to hidden users or multiple persistence methods.
• The scope of information theft from individual sites or the expansion of compromise to other sites has not been publicly disclosed.

8. Observable Logs

Email

• Inference: The recipient address and receipt time of notifications from the developer can be used to identify investigation targets. Since notification targets are considered incomplete, non-receipt cannot be used as proof of safety.

Proxy / SWG / DNS

• Inference: Check DNS or outbound traffic logs for unknown destination communications that began after the update. Specific outbound C2 destinations are not indicated in the referenced official guidance.

Endpoint / EDR

• Inference: Check file change records or EDR for wp-user-consent.php, PHP under object-cache, MU plugins, and web server child processes.

Identity / IdP

• Inference: Review WordPress audit logs for user creation and login events, and compare snapshots of the wp_users table to identify added or modified accounts. Check hosting management dashboards, FTP, etc., via their respective authentication logs.

SaaS / Cloud

• Inference: Check configuration changes and suspicious usage in audit logs for hosting, CDN, backups, and integrated APIs.

Network

• Inference: Examine web access logs for requests to web shells and cross-reference them with traffic logs. Request records alone cannot confirm command execution or data theft.

9. Attack Success Determination

Confirmed in Public Information

• Malware Execution or Successful Authentication Confirmed: Public Information: The developer has documented user-reported indicators of compromise, including web shells, hidden user accounts, and persistence artifacts. These substantiate malicious processing on reported sites, but do not indicate behavior across all installations or the number of attacker operations.

Internal Determination Criteria

• Initial Execution Confirmed: Criteria: Correlate malicious update installation records with the generation of web shells and persistence by the mixed-in code. Do not determine that the installation count of 1,500 sites equals the same number of successful executions.
• Information Theft or Session Compromise Confirmed: Criteria: Substantiate the transmission of file and database contents to the attacker or unauthorized credential usage with concrete records. Access to a web shell alone does not constitute information theft. Individual theft details remain unconfirmed in public information.
• Subsequent Compromise Confirmed: Criteria: Confirm the execution of additional malicious code, unauthorized access to other sites or hosting accounts, or content tampering with evidence. The overall scope is unknown from public information.

10. Investigation Playbook

Triggers

• Inference: Initiate based on the installation of version 2.35 or 2.36, traces from official guidance, or notifications from the developer.

Initial Verification

• Inference: Check download and installation timestamps, version, package hashes, backups, web access logs, and database differences.

Endpoints and Servers

• Inference: Preserve plugins, object-cache, MU plugins, WP-Cron, PHP processes, and modified files.

Authentication and Cloud

• Inference: Check credentials and session usage history for WordPress, hosting, FTP/SFTP, databases, and APIs.

Subsequent Operations

• Inference: Track web shell operations, additional files, data exfiltration, and unauthorized access to other sites chronologically.

Containment

• Inference: Isolate the site to preserve evidence and restore from pre-compromise backups. Change all WordPress user passwords, credentials stored on the site, and wp-config.php authentication keys and salts, then re-investigate. Update integrated service settings and verify the impact of authentication failures or outages.

Decision Categories

• Inference: Evaluate downloads, installations, malicious code execution, web shell operations, information theft, and compromises of separate environments independently.

11. Defense and Detection Ideas

Single Events

• Inference: Inspect PHP files with hex-string names under wp-content/object-cache, users combining wp_ with hex strings, options starting with wp_ocache or _wp_ocache_, and _wp_cconsent_tick. Do not judge by matches alone; verify the generation process.

Chronological Correlation

• Inference: Correlate update processing, wp-user-consent.php, web shell generation, hidden users, MU plugins, WP-Cron, and external requests chronologically.

Hunting

• Inference: Check installation history for versions 2.35 and 2.36 across all sites using the target plugin, along with differences in PHP, databases, and scheduled tasks since September 14.

Log Gaps

• Inference: The scope of verification varies depending on retention periods for update history, installed packages, database audits, WP-Cron, and web access logs. The absence of records must not be used as proof of no compromise.

Priority Measures

• Inference: Prioritize restoration to the pre-compromise state, credential changes, and difference monitoring for files, users, and scheduled tasks. Since wp-content/object-cache.php may be used by legitimate caching features, do not delete it based on the name alone.

12. Facts / Inference / Hypothesis

Facts

• According to the developer, malicious version 2.35 included includes/wp-user-consent.php, which deploys a web shell.
• Version 2.36, published as a clean version on September 14, was also tampered with on the same day. The developer advises treating sites that installed version 2.35 as compromised and sites that installed version 2.36 as potential compromise targets.
• According to explanations obtained by BleepingComputer from the developer, malicious updates from the initial compromise were deployed to approximately 230 customers and 1,500 sites. This count does not represent the number of sites where individual command execution was confirmed.
• Attackers may have obtained root privileges on the distribution server and showed signs of attempting to delete related logs. This does not indicate the acquisition of root privileges on customer servers.
• Users reported PHP files with hex-string names under wp-content/object-cache, hidden users, options starting with wp_ocache or _wp_ocache_, MU plugins, and a WP-Cron event named _wp_cconsent_tick.

Inference

• When the distribution source itself is compromised, safety cannot be judged solely by the fact that an update is official. It is necessary to monitor differences in files, users, and scheduled tasks before and after updates.
• Even if web shells or plugins are deleted, additional persistence or stolen credentials may remain. Recovery and credential changes must be verified separately.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation".

13. MITRE ATT&CK Mapping

• T1195.002 Supply Chain Compromise: Compromise Software Supply Chain (Confidence: high): Official plugin update packages were tampered with.
• T1505.003 Server Software Component: Web Shell (Confidence: high): Deployment of web shells via mixed-in code has been reported.
• T1136 Create Account (Confidence: high): Creation of hidden WordPress users has been reported.

14. Unknowns and Additional Investigation

• Initial intrusion vector into the distribution server and the attacker's identity.
• The number of sites that installed malicious version 2.36 and the overall scope of impact.
• Details of web shell operations, additional malicious code, exfiltrated data, and compromises of separate environments.
• The scope of logs attempted for deletion on the distribution server and the status of evidence preservation.

15. Impact on SOCs and Organizations

If paid WordPress plugins are omitted from central asset management, it becomes impossible to track the deployment destinations of compromised updates. Following the developer's guidance, treat version 2.35 as compromised and version 2.36 as a potential compromise target, and inspect databases, MU plugins, and WP-Cron in addition to comparing backups. It is important to include post-recovery credential updates and verification of integrated service operations within the scope of response.

16. Summary by Persona

• SOC: Correlate the generation of PHP files, hidden users, options, MU plugins, and WP-Cron with update timestamps, and separate installation counts from evidence of execution and operations.
• Administrator: Remove versions 2.35 and 2.36, and restore from pre-compromise backups if possible. Change passwords, authentication keys and salts, and integrated credentials, and verify service impact.
• User: General users may not notice compromises. Report any suspicious site displays or behavior to administrators.