Security · 17 Sep 2026 · Rob Nidschelm

The WordPress Update Was Backdoored, Then Its Replacement Was Compromised Too

The reassuring next step after a malicious software update is usually to install the replacement. In this incident, that assumption failed too. The developer of Admin Menu Editor Pro says the replacement version was subsequently compromised, leaving WordPress administrators with a harder question: which parts of their site can they still trust?

The developer’s incident notice, updated on 17 September, says version 2.35 included a web shell and should be treated as compromised. Version 2.36 should be treated as potentially compromised. The free plug-in is not identified as affected. The latest update places the earliest observed compromise around 19:40 UTC on 13 September and identifies a possible privilege-escalation route involving an outdated Linux kernel.

The recovery date matters more than the version badge

The same notice warns that the malicious payload is not fully understood. It describes hidden users, persistent components and potentially incomplete customer notifications. The developer also says there is not yet a safe general download channel for all customers; an already-held older copy of 2.34 or earlier is suggested instead. That is not an endorsement of an arbitrary download claiming to be the same release.

For administrators, the revised timeline changes a practical decision. A backup labelled “before 14 September” could still post-date the earliest known indication on the evening of 13 September. Choose a restore point from before that indication, then establish why it is considered trustworthy. The absence of a notification email cannot establish that a site is unaffected.

There is no confirmed kernel vulnerability identifier in the reviewed notice. BlackTree is not assigning one, claiming a completed root-cause investigation or converting a possible route into an established exploit chain. Nor does the public account establish that every customer or every installation was breached.

Do not mistake removal for recovery

A web shell changes the nature of the response. Deleting the original plug-in can remove an entry point without removing changes already made elsewhere. A successful plug-in update is therefore not an appropriate closure test for an incident involving site control.

BlackTree recommends dividing the work into evidence, recovery and validation. Have the hosting or response team preserve relevant records and assess the surrounding environment before routine housekeeping obscures the timeline. Decide whether a known-good restoration is required rather than assuming that a malware scanner has proved the whole installation clean.

• Establish installation history. Record the version actually installed, when and where it was downloaded, and which sites share the package or hosting environment. An asset list should include staging installations as well as production.
• Choose a defensible restore point. Evaluate backups predating the earliest known indication. Retain the original installation and evidence where appropriate instead of overwriting the only record of the incident.
• Follow the vendor’s current artefact guidance. Give the technical team the original notice and ask it to check the listed files, database entries, users and scheduled components. Avoid deleting an object-cache.php file blindly: the developer explicitly notes that legitimate caching software may create it.
• Rotate secrets from a trusted environment. After establishing recovery, review WordPress accounts, security keys, database and hosting access, file-transfer credentials and third-party API keys. Do not place replacement secrets into an environment still suspected of compromise.
• Validate more than the homepage. Check administrator access, background jobs, integrations, outbound connections and the hosted applications sharing the account. Document what was checked and what remains uncertain.
• Assess the data consequences. Have incident, privacy and legal owners determine whether information was accessed or altered and whether further action is required. A working website is not evidence that its historical data was untouched.

The lesson is not to stop updating

Supply-chain incidents can tempt organisations into the opposite mistake: delaying every update indefinitely. That trades one risk for another. The useful improvement is a controlled recovery process that can temporarily distrust a delivery channel, identify a trustworthy source and verify the resulting state.

For website owners, the immediate question is simple enough to put in a ticket: “Which evidence lets us trust this site again?” If the answer is only that the update notification disappeared, the work is not finished.

Sources

• Admin Menu Editor Pro, Security Incident Affecting Customers, initially published 14 September and last updated 17 September 2026 at 10:41 UTC. Check the current notice before recovery; the investigation remains ongoing.