The compromise of Admin Menu Editor Pro is a particularly important WordPress security incident because the attackers did not need to discover a vulnerability in thousands of individual websites. Instead, they appear to have compromised the software vendor itself and weaponized the trusted update mechanism used to distribute the premium plugin. Malicious versions 2.35 and 2.36 were made available from the official Admin Menu Editor website after an unauthorized party gained access to the maintainer’s infrastructure, causing customers who believed they were installing a legitimate software update to unknowingly deploy a backdoor onto their own WordPress sites. This is the fundamental power of a software supply-chain attack: compromise one trusted upstream provider and the normal mechanisms designed to keep downstream systems updated can suddenly become the distribution channel for malicious code.

The scale of the incident demonstrates how efficiently such an attack can propagate. The developer estimates that approximately 230 customers installed the malicious version 2.35 on at least 1,500 WordPress sites, with many customers operating multiple websites. Several hundred additional customers reportedly downloaded the plugin during the affected period and may also have received a compromised version 2.36, meaning the final number of impacted websites could be higher. This multiplier effect is what makes supply-chain attacks so attractive to adversaries because compromising one software vendor can provide indirect access to hundreds or thousands of organisations that would otherwise need to be attacked individually.

The malicious update contained a file named `includes/wp-user-consent.php`, which installed a webshell and created a hidden WordPress user account. This moved the attack beyond simple code injection because the adversary gained multiple mechanisms for retaining access to affected websites. A webshell provides a powerful remote execution capability, while a hidden WordPress administrator account can give attackers persistent application-level control even if part of the malicious code is later removed. Effective remediation therefore requires administrators to search for both filesystem and database artifacts rather than assuming that reinstalling the plugin alone removes the threat.

The attackers also created a new `/wp-content/object-cache/` directory and database entries using names beginning with `wp_ocache`, while the rogue WordPress user reportedly used an account name beginning with `wp_` and could be hidden from the normal WordPress administrative dashboard. This demonstrates a deliberate attempt to blend malicious artifacts into structures that administrators may consider routine. WordPress environments naturally contain large numbers of `wp_` prefixed database tables, cache directories and plugin-generated files, making naming conventions themselves useful camouflage. Attackers increasingly understand that persistence does not need to be invisible if it can simply look boring enough to escape casual inspection.

The hidden administrator account is particularly significant because compromise of a WordPress admin identity can provide far more than the ability to publish unwanted content. An administrator may be able to install plugins, modify themes, alter PHP code, create additional users and change security settings, depending on the site's configuration. Once attackers obtain that level of control, they can redirect visitors, inject phishing pages, distribute malware, steal credentials, alter e-commerce checkout processes or establish additional backdoors that survive removal of the original malicious plugin. Administrators should therefore treat affected sites as fully compromised rather than merely infected with one suspicious file.

The attacker’s persistence within the vendor infrastructure makes the incident even more concerning. After the developer discovered the malicious 2.35 update, removed it and published a clean version 2.36, the attacker still retained access to the website and compromised the replacement release as well. This sequence demonstrates why incident response must focus on removing the attacker rather than simply removing the visible malicious artifact. Replacing one infected file while the adversary still controls the underlying server merely gives the attacker another opportunity to reintroduce the compromise. The developer ultimately took the website offline after concluding that the intruder likely had root-level access, which was the more defensible response because trust in the update infrastructure itself could no longer be assumed.

That root-level access represents the most serious upstream security failure in the incident. Once an attacker obtains root privileges on a software distribution server, virtually every component of the delivery chain becomes suspect, including downloadable packages, update metadata, signing processes, website content and potentially credentials stored on the system. Restoring confidence requires rebuilding from known-good infrastructure, rotating credentials and verifying the integrity of every component involved in producing and distributing updates. Simply changing an administrator password is nowhere near sufficient when the attacker may have controlled the entire operating system underneath the application.

This incident therefore illustrates why software vendors should treat their update infrastructure as critical production security infrastructure rather than an ordinary web server. Systems used to build, sign and distribute software should be isolated from general-purpose websites, protected with strong multi-factor authentication, tightly restricted administrative access and detailed integrity monitoring. Build environments should ideally be separated from public-facing distribution systems so that compromise of a marketing or download website does not automatically allow attackers to modify software releases. The closer the update path is to the customer's production environment, the stronger the security controls around that path need to be.

Digital signing also becomes highly relevant in incidents like this. Cryptographic signatures can allow customers and automated update systems to verify that a package genuinely originated from an authorised build process and has not been modified after signing. However, signing is effective only if private signing keys and the build pipeline themselves remain secure. If an attacker controlling the vendor infrastructure can also trigger or access the legitimate signing process, a malicious package may still appear authentic. Software supply-chain security therefore requires protection of the complete development and distribution lifecycle rather than relying on one cryptographic control as a magical seal of purity.

For WordPress administrators, the incident also highlights a difficult reality about automatic updates. Automatic patching is normally encouraged because it reduces the time websites remain vulnerable to publicly known flaws, but a compromised vendor update channel reverses that security benefit. The same automation that normally protects customers can rapidly distribute malicious code when the upstream source becomes compromised. This does not mean organisations should disable automatic updates entirely, because leaving internet-facing software indefinitely unpatched would create a much larger problem, but high-value environments may need additional controls such as package integrity verification, staged deployment and monitoring of changes introduced immediately after updates.

The most reliable recovery recommendation from the developer is to restore affected websites from a known-safe backup created before September 14. That recommendation is significant because once an attacker has executed arbitrary code and created persistent administrative access, manually cleaning individual artifacts may provide false confidence. The attacker could have installed additional backdoors, modified themes, altered plugins or changed database entries that investigators have not yet identified. Restoring from a known-clean backup reduces the risk of leaving hidden persistence behind, although administrators must still rotate credentials and patch the root cause before reconnecting the restored site to production.

Where restoration is not possible, administrators need to remove the affected plugin, delete the unexpected `/wp-content/object-cache/` directory and inspect the database for suspicious `wp_ocache` options and hidden users beginning with `wp_`. However, these published indicators should be treated as minimum checks rather than a complete forensic guarantee. Attackers with remote code execution could easily have created additional persistence using different filenames, cron jobs, modified theme files or secondary administrator accounts. A clean indicator search therefore does not necessarily prove that a site was never compromised.

Credential rotation should also be part of remediation because attackers with administrative or server-level access may have obtained WordPress database credentials, hosting control-panel credentials, API keys or secrets stored in configuration files such as `wp-config.php`. Passwords for WordPress administrators, database users, hosting accounts and related services should therefore be considered potentially exposed on confirmed compromised systems. Authentication tokens and API keys should likewise be revoked and replaced where practical because removing malware while leaving stolen credentials valid simply provides the attacker with a more convenient way back in.

Website owners should also inspect outbound network traffic and server logs for signs that compromised systems communicated with external infrastructure. File-integrity monitoring can help identify recently modified PHP files outside the known malicious plugin, while database auditing may reveal newly created accounts or changed options. Centralised logging is particularly valuable because attackers with server access may delete or modify local evidence. Independent logs provide defenders with a history that remains available even when the compromised system itself can no longer be trusted.

The incident also highlights the security challenges surrounding premium WordPress plugins. Free plugins hosted in the official WordPress repository benefit from a central distribution and update ecosystem, while commercial plugins frequently depend on vendor-operated websites and proprietary update servers. This distributes security responsibility across hundreds of independent developers whose operational security maturity may vary considerably. A premium plugin can have perfectly secure application code while its distribution infrastructure remains vulnerable, meaning website owners need to evaluate not only what software they install but also how the vendor builds and delivers future updates.

Organisations running large fleets of WordPress sites should therefore maintain an inventory of plugins, versions and update sources across every site rather than managing each website independently. When an incident like this emerges, administrators should be able to identify affected deployments immediately instead of manually checking hundreds of websites. Centralised management also allows organisations to suspend a problematic plugin, search for indicators across all installations and coordinate remediation consistently.

The difference between the free and Pro editions is also important. The developer says the free Admin Menu Editor plugin, which is installed on more than 300,000 sites, does not appear to have been affected. The compromise was limited to the premium distribution infrastructure, which reinforces the need to verify the exact software edition and update channel rather than assuming every installation of a similarly named plugin is compromised. Accurate incident response depends on precise asset identification, because both overreaction and underreaction waste valuable time.

From a wider cybersecurity perspective, this incident illustrates why supply-chain security is fundamentally about trust. Customers installed the malicious update precisely because it came from the official vendor website and appeared to be a legitimate new version. No phishing message or social engineering was necessary at the customer level because the attack exploited an existing trust relationship between developer and administrator. That makes supply-chain compromises especially dangerous: the attacker inherits credibility that the legitimate vendor spent years establishing.

The incident also demonstrates why visibility after software updates matters. Organisations should monitor what changes occur immediately following updates, including new executable files, new administrator accounts, unexpected directories and outbound connections. A legitimate update may modify many files, but it should still produce behaviour consistent with the documented function of the software. A menu-management plugin suddenly creating hidden administrator accounts or deploying webshells represents an obvious behavioural mismatch, and security controls capable of identifying that mismatch can provide protection even when the malicious package originates from a trusted source.

Ultimately, the Admin Menu Editor Pro compromise shows that software provenance matters just as much as software vulnerabilities. The plugin did not need a coding flaw inside customer environments for attackers to gain access; compromise of the vendor's distribution infrastructure was enough to convert trusted updates into malware delivery. Organisations therefore need to extend cybersecurity beyond patching and vulnerability management into supply-chain integrity, update verification, behavioural monitoring and recovery planning. Trusting a vendor is necessary for modern software ecosystems to function, but trusting every future package simply because it arrives through yesterday's trusted channel is becoming an increasingly dangerous assumption.

Malicious versions of the Admin Menu Editor Pro plugin for WordPress have been distributed to more than 200 customers after a threat actor compromised the maintainer's website and pushed updates that created a hidden user account. [...]

Source: Malcious Admin Menu Editor Pro plugin backdoors 1,500 WordPress sites via Bleeping Computer — published 15 Sep 2026.