WordPress Supply Chain Attack: What Happened and How to Check Your Sites

A serious security incident has been circulating through the WordPress community this week, and for anyone managing multiple WordPress sites, it is worth paying close attention.

An attacker bought roughly 30 WordPress plugins through legitimate marketplace purchases, then used the WordPress.org commit access to quietly insert malicious code. What makes this especially troubling is not only the scale of the attack, but how long it was able to sit unnoticed. In at least one confirmed case, the malicious code remained in place for eight months before it was discovered.

How the Attack Worked

The best documented example involves a plugin called Essential Plugin, which included a module named wpos-analytics. For years, that module worked as a normal analytics opt-in feature. Then, in August 2025, what looked like a routine update added 191 lines of code to the plugin. The changelog entry was harmless enough: “Check compatibility with WordPress version 6.8.2.” Behind the scenes, though, the update introduced a deserialization backdoor along with a phone-home function that connected to an attacker-controlled server.

Updating isn’t enough. Not even close.

Once the issue came to light, WordPress.org responded quickly and pushed out a patched version that disabled the phone-home behavior. But that patch did not address changes made to wp-config.php.

That means sites compromised before the patch was installed may still be serving hidden spam to Google even after the plugin has been updated. The reason is simple: the malicious code written into wp-config.php does not disappear when the plugin is patched or removed.

This is where most site owners will get burned. Updating or deleting the plugin is the right first step, but it is not the last one. If the plugin had a chance to run before the fix was applied, wp-config.php should be reviewed and cleaned manually.

What You Should Do

Start by checking whether any of the affected plugins are installed across your sites. The original security disclosure includes a full list of plugin slugs.

Next, inspect wp-config.php on any site that may have been exposed. We have released a Code Snippet designed to scan wp-config.php across all of your child sites and flag known indicators tied to this attack. It takes only seconds to run and lets you check your full fleet at once instead of reviewing sites one by one.

Full instructions how to use the Code Snippet are all available in our Help Document.

This incident is a useful reminder that trust in a plugin depends not only on who built it originally, but also on who owns and maintains it now. Keeping track of what is installed across your sites, and having a fast way to inspect them when something like this happens, is exactly where MainWP can help.