What the WordPress hack tells us about plugin security

In April 2026, there was another major attack on WordPress sites. Over 30 WordPress plugins were compromised, and all of them were given a backdoor into the server.
WordPress, plugins, screen
None of the plugins shown in the image are related to this article

What actually happened?

A person calling himself "Kris" (with a background in SEO, crypto, and online gambling) bought a company called Essential Plugin on Flippa on August 8, 2025. The company had developed 31 plugins. After the purchase, he planted a so-called "backdoor" in all of them. But he didn't do anything noticeable for about 8 months before the backdoor was activated in April 2026.

What did the hack do?

It gave the attacker total control over the website and everything on the server — what's called full remote code execution (RCE).

What actually happened was that the hack made it possible to inject hidden SEO spam into the website, all without the site owner noticing a thing. The attack was optimized to only show the spam to Googlebot, not to the person who owns the site. So nobody saw the "ads" the attack was serving.

What did it mean for site owners?

What "Kris" gained from this was exploiting the authenticity of other people's websites for his own benefit. He got Googlebot to boost his own affiliate links and similar content, which pushed him higher up in Google's search results without having to do anything more than let the hack work for him. Had this gone on for longer, the hacked websites would have risked losing their own ranking as Google flagged them as spam — without the owners having any idea why. WordPress permanently took down all 31 plugins once it was discovered, but the injected code in wp-config.php is still there and has to be cleaned out manually by a developer.

What is a supply chain attack?

This is a textbook supply chain attack, which in this case exploits WordPress's reliance on third-party plugins from many different developers.

This means that the hacker does not attack you, the user, directly, but rather something you rely on for your website to function – in this case, a plugin. The hacker takes control of the plugin and embeds malicious code within it, which is then smuggled in via a completely normal update. And because the update comes from a trusted source, it doesn’t raise any suspicion.

Is WordPress insecure?

This does not mean that WordPress is bad or that all WordPress sites get hacked. The core of WordPress itself is secure and receives regular security updates. With a knowledgeable developer, few plugins installed and good maintenance routines, it is perfectly possible to keep it secure. WordPress is simply more exposed to risks because it is such an extremely popular CMS; 43% of all websites are built using WordPress. So people often assume that WordPress is insecure when they hear it has been hacked. But in reality, it is the plugin market that is less secure.

How Statamic reduces the risk

I'd say no one can fully avoid being hit by a supply chain attack, but with Statamic you avoid that risk almost entirely:

  • No need for multiple plugins. Most of the features you need are already built into Statamic.
  • Statamic is developed by a single team that's very active.
  • Flat-file architecture (no database) — that alone eliminates common attacks like SQL injection.
  • Built on the modern and secure PHP framework Laravel.
  • Much smaller attack surface and significantly lower risk of mass infections.

One marketplace, one package manager

Another important aspect is that customers can buy plugins from any number of different websites — like CodeCanyon, WordPress.org, and PluginsForWordPress — which makes the WordPress market extremely fragmented.

When you buy or download a WordPress plugin, you receive a .zip file. There is no version history or insight into what has changed over time. If, as a developer, I want to review the code, I must either unzip it and go through it manually or use AI to scan for vulnerabilities.

Unlike Statamic, which uses a platform where you purchase add-ons. When I install them – which, as the developer, only I can do – I do so via Composer, which is PHP’s own package manager. And as a bonus, I can also view the history of these plugins via the version history in Git. I can see exactly what has changed, when, and by whom.

That’s one of the reasons why I build with Statamic. WordPress still has its place for certain types of projects, but I want to be able to guarantee the security of what I deliver.

Want to read more about the hack?

Austin Ginder was the person who alerted WordPress.org that something was wrong. He has written a very detailed article about this incident, including which plugins were affected.

Mastodon