When the plugin update is the attack

On September 14, a few hundred WordPress site owners did the responsible thing. A plugin they’d paid for showed an update, and they installed it. That update put a web shell on their sites.

The plugin was Admin Menu Editor Pro. The developer’s running account of what happened is unusually candid: someone got into adminmenueditor.com, uploaded a malicious copy of the plugin, and the site served it to paying customers as version 2.35. A clean 2.36 went out the same day. Later that day, attackers compromised 2.36 too. The developer estimates about 230 customers in the first wave, often with several sites each, which is how BleepingComputer arrived at at least 1,500 sites.

Earlier this month I argued that WordPress is still good advice as long as you manage its known failure mode, the plugin buffet, with discipline: fewer plugins, maintained sources, prompt updates, a serious host. I stand by every word, and this incident is the caveat that piece needed. “Update promptly” is still right; it just can’t be the whole procedure anymore.

This was not a bad click — it was a poisoned update

Here’s the normal path. A plugin developer publishes a new version on their server. Your site checks in, sees the version number has gone up, and either offers you the update or installs it on its own. You trust the source because you’ve trusted it for years.

On September 14 the source itself was the problem. Nobody downloaded a cracked plugin from a forum or fell for a fake update banner. The malicious package sat on the developer’s real website, under the real plugin name, for about seven hours that morning by BleepingComputer’s account, and the plugin’s own update mechanism delivered it. When the developer noticed, he pulled it and shipped a clean 2.36. Then the attacker, who may have had root-level access to the server, replaced that one too. The server went offline that evening. The free version of the plugin on WordPress.org doesn’t appear to have been touched, BleepingComputer reports.

That’s a supply-chain attack in the most literal sense. The chain you rely on for fixes carried the payload.

First, decide whether your site was in the blast radius

The applicability test is short. It’s about version, date, and source together, not version alone.

You’re affected if you installed version 2.35 of Admin Menu Editor Pro on September 14, 2026. You may be affected if you installed 2.36 that day, particularly, the developer says, if you downloaded it after 19:00 UTC. Version 2.34 should be clean. The 2.37 he later posted is 2.34 with a new number. If the plugin isn’t on your site at all, the rest of this article is about your next update, not this one.

Don’t let silence stand in for a check. The developer emailed affected customers, but he says his list is likely incomplete. About 300 more customers downloaded something in or near the window, with no version number to confirm it. Check the plugin’s version in your dashboard and, if you can, when the file was last modified.

What the malicious update left behind

The developer published a list of what customers found on affected sites. Some of it is visible from the dashboard. Most of it isn’t.

The update carried a new file, includes/wp-user-consent.php, which installs a web shell. From there, the shell set up a /wp-content/object-cache directory holding a subdirectory and a script with names made of hex characters. Sites also found new entries in the options table starting wp_ocache or _wp_ocache_. They found must-use plugins in /wp-content/mu-plugins named wp- followed by hex, and a scheduled WP-Cron event called _wp_cconsent_tick. And they found a new user whose login is wp_ plus hex characters.

Two other names came up in reports: a plugin called wordpress-cache-optimizer and a user called wpsecuresuppbot. In the developer’s view, those belong to an older malware strain seen months earlier and may be a coincidence. Treat them as things worth removing if you find them, not as proof this incident reached you.

A clean dashboard is not a clean site

The hidden user is the important one. The developer’s notice says it probably won’t appear in the admin dashboard’s Users screen, but it will show up if you query the wp_users table directly. So “I looked in Users and there’s nothing there” is not a finding. It’s the attacker’s design working as intended.

The same goes for the other artifacts. Must-use plugins run without appearing in your installed-plugins list. Options are database rows, not admin screens. Cron events are scheduled tasks you never see unless you install a tool to show them. WordPress can run code from all three places while the dashboard looks normal.

Checking them means opening the database or the file system. If those words don’t describe something you’ve done before, that’s where your host, developer, or security service earns its keep. Ask them to check the users table, the mu-plugins folder, the options table, and the cron schedule for the names above. That’s a specific request they can act on in an hour.

Why a backup may beat a cleanup

Because the payload was a web shell, the developer’s advice starts with an assumption: treat the attacker as having had full control of the site. His first recommendation is to restore from a backup made before September 14 if you have one. The cleanup steps come second. He says himself they may be insufficient, since he doesn’t yet fully understand the payload.

That ordering surprises people who think of recovery as deleting the bad thing. A web shell isn’t the bad thing. It’s the door, and once it’s open, the attacker can add whatever they like. The artifact list, built from user reports, might not be complete. A backup from September 13 doesn’t have the door.

So the decision runs like this. If you have a clean backup from before the 14th, restore it, then install the clean version the developer has posted and change your passwords anyway. If you don’t, follow the developer’s cleanup. Delete the plugin. Delete the object-cache directory, but not the object-cache.php file a caching plugin may legitimately keep. Remove the hidden user, the options, the cron event and the MU plugins. Change every WordPress user’s password, regenerate the salts and keys in wp-config.php, and rotate the database, SFTP, hosting-panel, and API credentials. Run a malware scan and review every file modified since September 14. If you’re not sure the site is clean afterward, that’s the case for professional review, not for hoping.

WordPress’s own handbook spells out what a restore needs: both the database and the files, with three to five recent copies in different places. I’ve written before that backups, updates, and access control only work as a connected system. Here, the update failed, and the backup makes the failure survivable.

Keep updating, but stop treating updates as magic

The wrong lesson here is to stop updating. WordPress’s documentation still says you should always update plugins and themes to the latest version. The reason hasn’t changed. The vast majority of WordPress vulnerabilities live in plugins, as the Patchstack numbers in my last piece showed, and a known hole is a far more common way in than a poisoned update. Since WordPress 5.5 you can switch on auto-updates plugin by plugin, and once enabled they run twice a day.

The same page includes the sentence people skip: before enabling auto-updates, make sure you can roll back to a previous version of your site if things go wrong. That’s this whole article in one line, from WordPress itself. Updating is good. Updating without a restore path is a bet.

So keep the habit and add the loop. Update promptly, keep a backup from before the update, and know how to restore it.

Which plugins deserve extra review

Not every plugin needs the same scrutiny, and trying to inspect them all equally is how people end up inspecting none.

Premium plugins delivered from a developer’s own server are one group. Paying isn’t the risk; the update comes from infrastructure only that developer protects. Plugins that change how administration works, as this one does, are another, since they already sit deep in the site. Add anything with broad file or database access, anything unmaintained for a year, and anything installed across a dozen client sites, where one bad update becomes twelve incidents.

One tool helps with part of this. WP-CLI’s verify-checksums command compares a plugin’s files against WordPress.org’s checksums and reports what doesn’t match. It’s a good routine check for repository plugins. It has nothing to compare a premium plugin against, since that plugin never came from WordPress.org, so it would not have caught this incident. It’s one control, and it covers the easy half of the list. The security basics that fail are usually the ones implemented for the easy half.

Build a post-update check that you can actually repeat

Routine updates to repository plugins don’t need an incident-response sweep. The deeper check is for the group above: high-permission, off-directory, recently compromised or unusually sensitive plugins. For those, run Table 1 after each update. In ten minutes, most rows are answerable from the dashboard.

The table is the routine. It won’t catch a poisoned update on the day it lands, but it catches the artifacts one leaves, and it makes sure you have somewhere to go back to when one does.

Update promptly, then verify the site you got back

The rule didn’t change. Fewer plugins, from maintained sources, updated promptly, on a host that takes patching seriously. What September added is the second half: a backup from before the update, and checking the site afterward for what a dashboard won’t show you.

The customers in this incident did the right thing and got hurt anyway, and the developer’s first advice was to use a backup that predated the update. Keep updating. Just make sure every update has a way back.