Sites running the malicious update: 1,500 sites across 230 customers (Source: Janis Elsts, plugin maintainer, statement to Bleeping Computer (September 2026))
A Malware Update, Signed and Delivered by the Vendor
On September 14, 2026, users of the Admin Menu Editor Pro plugin for WordPress received what looked like a routine update. Version 2.35 arrived through the plugin's own licensing and update server, the same channel these site owners had relied on for years. Bundled inside was a new file, includes/wp-user-consent.php, that installed a web shell on the receiving server, according to plugin maintainer Janis Elsts. A clean version, 2.36, went out later the same day — but the update server was compromised again before that fix could hold.
The Plugin Wasn't the Weak Point — the Server Was
Elsts traced the intrusion not to a flaw in the plugin's own code but to a vulnerability in an outdated Linux kernel running on the infrastructure that hosts the update and licensing system. The earliest sign of compromise dates to September 13, 2026, at around 7:40 p.m. UTC. That attackers managed to push a second malicious build after the first was caught suggests they held root-level access to the server, not merely write access to one file. A third release, version 2.37, went out on September 20 for customers who hadn't already restored from a clean copy. Elsts said the team is now rebuilding the update server and licensing API "nearly from scratch," work he expects to take a couple of weeks.
Why One Plugin Incident Matters at Budget Level
Nothing about this attack required a user to click a bad link or fall for a fake login screen. The malicious code arrived through the exact channel security teams tell staff to trust: an official, automatic plugin update, served twice from a server the vendor itself did not control. Any control that assumes an update is safe because it came from the vendor's own server would have missed both versions. The incident lands on a widely deployed platform. In WebPulse's September 2026 scan of the Tranco top-10,000 domains, WordPress was the second most commonly detected platform among sites where a framework could be identified, trailing only Next.js.
Separately, WordPress's own disclosed-vulnerability record — 583 CVEs to date, 17 rated critical, and 3 listed in CISA's Known Exploited Vulnerabilities catalog — reflects a platform that has been scrutinized publicly for two decades. This week's incident sits outside that catalog entirely: it was a compromise of vendor infrastructure, not a flaw in WordPress core or in the plugin's published code. That distinction matters for anyone allocating security budget. Vulnerability scanning and patch management cover the code an organisation can see. They don't cover the server a plugin vendor uses to sign and ship its updates.
What to Ask Your Team
Four questions worth raising with whoever manages the plugin and CMS estate: Do we verify checksums or signatures on automatic plugin and theme updates before they reach production, rather than trusting the update channel by default? Which vendors' update infrastructure has ever been reviewed, and do contracts require disclosure of patch cadence on the servers that sign and distribute code to us? If a trusted update channel were compromised twice in a week, would monitoring flag a new file appearing in a production plugin directory, or would it read as ordinary update traffic? And for any WordPress deployment specifically, who owns the plugin inventory, and how quickly could every affected site be rolled back to a verified-clean build?
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Hacker News.
