On 14 September, users of the paid Admin Menu Editor Pro plugin could receive what looked like a perfectly normal update to version 2.35. It came from the vendor’s official server. The problem was that the package contained a file called includes/wp-user-consent.php, which installed a web shell on the site – a mechanism that allows commands to be executed remotely on the server.

The vendor removed the malicious package and released a clean version 2.36 later that same day. A few hours later, that version had been tampered with as well. At that point, it was clear that this was not just a compromised admin account or a single bad file. The attackers had probably gained much deeper access to the infrastructure.

This was a supply-chain attack, not a normal WordPress vulnerability

In a typical vulnerability, an attacker looks for a flaw in code that is already installed on the website. Here, the attacker first compromised the part site owners are supposed to trust: the server distributing the official updates. That trusted source was then used to deliver a modified version of the plugin.

WebsiteGarage / Services

Explore our services.

That is exactly what makes this a supply-chain attack. Nobody has to convince an administrator to download a file from a suspicious domain. If the attacker controls the real update channel, the malicious package looks like an ordinary update.

Version 2.35: treat the site as compromised. Version 2.36 is no all-clear either

The vendor’s advisory is unambiguous. If version 2.35 was installed on 14 September, the site should be treated as compromised. Version 2.36 should also be considered potentially compromised, especially if it was downloaded after 19:00 UTC. Based on the information available so far, version 2.34 appears to be clean.

The vendor initially estimated that around 230 customers were affected during the first phase of the incident, many of them running more than one site. It later identified roughly another 300 customers who may have been exposed during the second window. Those are customer counts, not a verified number of infected websites.

What the malicious code did

The most important component was the web shell. In practical terms, that means code could be executed on the compromised site. The vendor therefore warns against treating this as a case of removing one suspicious file. The safer assumption is that the attacker may have had full control of the site.

User reports revealed other traces as well: a /wp-content/object-cache directory containing a randomly named PHP script, database entries beginning with wp_ocache or _wp_ocache_, a hidden user account with a login starting with wp_, suspicious MU plugins and a WP-Cron task named _wp_cconsent_tick.

The vendor notes that a hidden user like this may not appear in the normal WordPress user list, while still being visible directly in the wp_users table. A quick glance at the Users screen may therefore not be enough.

The first cleanup failed because the attacker was still inside

After version 2.35 was discovered, the vendor removed it and released 2.36. Later the same day, another intrusion was detected and version 2.36 had also been compromised. Attempts to stop the attack failed, so the server was taken offline.

On 17 September, a new lead emerged: a possible root escalation through a vulnerability in an outdated Linux kernel. If that theory is confirmed, it would explain why cleaning up the application layer and replacing one package was not enough. The attacker may have remained entrenched deeper in the system than the cleanup ever reached.

What should a site owner using this plugin do?

If version 2.35 from 14 September was installed on the site, the vendor says the safest option is to restore from a backup taken before 14 September. With version 2.36, the version number alone should not be treated as proof that the installation is clean.

The vendor also recommends removing the suspicious version, checking for the artefacts described above, changing WordPress user passwords, generating new keys and salts in wp-config.php, and rotating every credential the site stores or uses: database, SFTP or FTP, hosting control panel and API keys. On top of that, run a full scan and review files modified since 14 September.

The vendor itself says it still does not have a complete picture of the payload, so some of these steps may not be enough on their own. In an incident like this, “I deleted the file, so it’s clean” is closer to hope than an incident-response procedure.

WebsiteGarage says

Automatic updates matter. Updates from the original vendor matter too. This incident is not an argument for turning them off and going back to manually clicking “Update” once every few months. It shows something else: updates are one part of the security system, not the entire system.

If the vendor itself is compromised, the official update channel can become an infection route. That is why off-server backups, change monitoring, a tested restore process, limited permissions and a clear incident-response procedure matter. Without those, WordPress security can easily turn into a ritual: everything is green, everything is up to date, therefore everything must be fine. The real question is this: when someone clicks the next “Update”, does anyone also check why that update exists and whether extra steps are required afterwards? As this incident shows, reading the release notes occasionally is not a bad habit.

The most interesting lesson is even simpler. After the first malicious version was found, the vendor produced a clean replacement. The attacker tampered with that one too. If the cause of the compromise is still there, a clean replacement can simply become the next thing the attacker tampers with.