On September 14, 2026, attackers compromised the Admin Menu Editor Pro update server and pushed malware to thousands of WordPress sites. Here is how we found it, traced it, and what you need to do right now.

September 15, 2026  ·  We Watch Your Website Security Team  ·  Supply Chain

Action Required

If you or your clients have Admin Menu Editor Pro installed and it shows version 2.35 or 2.36, your site has been compromised. Do not wait – follow the remediation steps at the bottom of this post immediately.

Supply chain attacks are among the hardest security incidents to catch precisely because the infection arrives through a trusted channel. The software does what it always does. The update server is the one you have always trusted. The traffic looks completely normal. And that is exactly what makes them dangerous.

Yesterday, we caught one in progress on a client’s WordPress site. Here is the full investigation, from the first suspicious log line to confirming it was a coordinated attack on thousands of WordPress installations worldwide.

It Started With One Access Log Line

Routine monitoring flagged a newly created file on a client’s site: wp-content/object-cache/ac928a/297fed97fd5e.php, timestamped September 14, 2026 at 06:09:59. The location alone was suspicious – WordPress object cache directories do not contain PHP files with random hex names.

We pulled all access logs matching that timestamp window. One entry stood out:

[14/Sep/2026:10:09:59 +0000] 5.161.250.15 1.232 – [client-site.com]
“POST /5319dea30c35de8cef0f342254c56a7fedb37817bb042dcd6f7e63262a2b84c8.php?006d1e=3437 HTTP/2.0″
200 737 1.233 “https://[client-site.com]/”
“BlogVault/1.0 (+https://blogvault.net)”

A POST request to a long hex-named PHP file at the webroot, with a suspicious query parameter, returning 200 – timed to the exact second the malicious file appeared on disk. The server filesystem was in EDT; the logs were UTC. 06:09:59 EDT is 10:09:59 UTC. Same event.

The User-Agent claimed to be BlogVault, a legitimate WordPress management and backup service used by this client. The first question: was that request actually from BlogVault?

host 5.161.250.15
# 15.250.161.5.in-addr.arpa domain name pointer hzas95.bvserver.net.

It was. The IP resolved to bvserver.net – BlogVault’s own infrastructure, hosted on Hetzner. The request was genuinely from BlogVault. We reached out to their team immediately, and what followed was a collaborative investigation that helped both of us understand exactly how the attack worked.

Dissecting the Dropped Backdoor

We pulled 297fed97fd5e.php immediately. Despite the innocent-looking header comment disguising it as an object-cache helper, the file is a fully capable fileless PHP backdoor. Every line is deliberate. Here is what it does:

It checks for a secret request parameter (w291fe108e6) and silently exits if it is absent. An attacker who does not know the key gets nothing – no error, no output, no indication the file is there at all. When the correct parameter is present, its value is base64-decoded into PHP code, written to a temporary file with the innocuous prefix oc (for “object-cache”), executed, and then immediately deleted. No persistent second-stage payload ever exists on disk.

The evasion techniques are layered. 'base64_'.'decode' splits the function name across string concatenation to defeat signature scanners. '<'.'?php ' does the same to avoid the literal PHP opening tag in the file. All file operations are silenced with @ to suppress error logging. The file disguises itself as a WordPress object cache helper – a location and filename that most security scanners and site owners would not flag.

This is not opportunistic malware. It is purpose-built for persistent, undetectable remote access.

Working With BlogVault to Understand the Vector

The backdoor file does not run itself. Something had to create it. Working with the BlogVault team, we were able to piece together exactly how – and their connector file was not involved in the way we initially suspected.

BlogVault confirmed the request at that timestamp was a legitimate, routine operation from their infrastructure. They also confirmed their connector file had not been tampered with in any way – BlogVault has integrity verification in place that would detect any modification to the connector immediately.

The real mechanism is more subtle. When BlogVault’s connector calls into a WordPress site, it bootstraps the WordPress environment – which means it loads all active plugins. That includes the malicious Admin Menu Editor Pro 2.35 that had been installed earlier in the day. The malicious plugin contained logic that monitored incoming requests and used that execution context to drop the backdoor as a side effect. BlogVault’s connector was never touched. It was simply the event that caused WordPress to load, which caused the malicious plugin to run.

This is what makes the attack design so effective: it weaponizes any trusted service that interacts with WordPress as an unwitting trigger. BlogVault bears no responsibility here whatsoever – their system worked exactly as designed. The fault lies entirely with the compromised Admin Menu Editor Pro update.

Finding the Source: A Fake Plugin Update

The next question was how the BlogVault connector got tampered with in the first place. Examining the installed plugins across all affected sites on the same server, every compromised site had one plugin in common: admin-menu-editor-pro.

The plugin directory had an unusually small number of files – just menu-editor.php, extras.php, readme.txt, and uninstall.php at the root. A real Admin Menu Editor Pro install has dozens of files across multiple subdirectories. And the version number in the plugin header: 2.35.

Shortly after we identified this, adminmenueditor.com went offline with this notice:

“On September 14, 2026, an attacker gained access to the server hosting this site and distributed a malicious version of Admin Menu Editor Pro (labeled 2.35) as a plugin update. Later on the same day, version 2.36 was also compromised.”

The timeline was exact. The fake 2.35 update was pushed on September 14. Our client’s site pulled it automatically – the legitimate update checker built into the plugin polls adminmenueditor.com every 12 hours. When it pulled the update, it installed the malicious plugin, which sat waiting. When BlogVault’s server next called home on its normal schedule, the connector bootstrapped WordPress, loaded the malicious plugin, and the plugin seized that moment to drop the backdoor – all within the same morning. BlogVault’s team confirmed this sequence matched their own records, which helped us close the loop on the full attack chain.

The Full Attack Chain

1. Attacker compromises the adminmenueditor.com update server and replaces the legitimate Admin Menu Editor Pro download with a malicious version labeled 2.35.
2. WordPress sites running Admin Menu Editor Pro automatically check for updates every 12 hours and pull the malicious 2.35 update, installing the attacker’s code.
3. The malicious plugin installs and waits. It contains logic that fires during WordPress execution, watching for the right conditions to drop the backdoor. The BlogVault connector is never touched.
4. BlogVault’s legitimate server calls home on its normal schedule. The connector bootstraps WordPress, which loads all active plugins – including the malicious one. The malicious plugin uses that execution context to silently write the backdoor to wp-content/object-cache/. BlogVault’s connector is clean throughout. BlogVault bears no responsibility here at all.
5. The attacker now has a universal, fileless code execution backdoor on the site, accessible via POST request with the correct secret parameter. No obvious trace remains of how it got there.

What To Do Right Now

If you manage WordPress sites – whether your own or for clients – check every installation for Admin Menu Editor Pro immediately. If it is present and shows version 2.35 or 2.36, the site has been compromised. Clean installs need the plugin replaced; compromised ones need full remediation.

Immediate Steps

• Delete the Admin Menu Editor Pro plugin entirely from every affected site. Do not deactivate – delete. The plugin files themselves are the initial infection.
• Search for and delete the backdoor: wp-content/object-cache/ and any subdirectories containing hex-named PHP files. Look specifically for directories matching the pattern ac928a or similar random hex strings.
• BlogVault’s connector file was not modified by this attack – their integrity verification would have caught any tampering immediately. If you use BlogVault, their system is clean and you can continue using it normally. Reach out to their support team if you have questions about a specific site.
• Search your access logs for POST requests containing w291fe108e6 as a parameter. If you find any, the backdoor was actively used after it was planted and you have a deeper compromise to investigate.
• Reset your WordPress security keys and salts (Settings > General in wp-config.php via the WordPress secret key generator). This invalidates all existing sessions.
• Force password resets for all admin users on affected sites. Database credentials were accessible to the attacker if the backdoor was triggered.
• Read the official advisory from Janis Elsts (the plugin developer) at adminmenueditor.com/blog/security-incident-affecting-customers-2026-09-14/ for authoritative guidance specific to the payload that was distributed.

For Agencies Managing Multiple Sites

• →Run a bulk search across your fleet for the plugin directory: find /path/to/sites -type d -name "admin-menu-editor-pro"
• →Check plugin versions: grep -r "Version:" /path/to/sites/*/wp-content/plugins/admin-menu-editor-pro/menu-editor.php
• →Find any hex-named object-cache subdirectories: find /path/to/sites -path "*/object-cache/*" -name "*.php"
• →Grep logs for backdoor trigger: grep "w291fe108e6" /path/to/logs/*.log

The Lesson This Attack Teaches

Auto-updates are generally good security practice – they keep sites patched against known vulnerabilities. But supply chain attacks invert that equation entirely. When the update mechanism itself is the attack vector, auto-updates become the delivery system.

This is not an argument against auto-updates. It is an argument for monitoring. The malicious 2.35 update and the backdoor it dropped were both detectable – the file in an unusual location, the access log entry at the exact wrong moment, the plugin directory with suspiciously few files. What you need is something watching for those signals.

We caught this within hours of infection because our monitoring flagged the new PHP file in the object-cache directory before any second-stage activity occurred. On an unmonitored site, that backdoor could have sat there silently for days or weeks while the attacker took their time deciding what to do with it.

The other lesson is about log retention. Tracing this attack required access logs going back to the moment of infection. If your hosting provider rotates logs aggressively or you do not have log access at all, you lose the ability to reconstruct what happened and whether the backdoor was ever triggered. Logs are not just a debugging tool – they are your forensic record.