What the WordPress hack tells us about plugin security
- What did the hack do?
- What did it mean for site owners?
- A classic supply chain attack
- Is WordPress insecure?
- How Statamic reduces the risk
- Want to read more?
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.
A classic 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.
Is WordPress insecure?
This doesn't mean WordPress is bad, or that every WordPress site gets hacked. With a competent developer, few installed plugins, and good routines, it works just fine. But the bar for keeping a WordPress site secure over time is higher than most people think — and the risk is there no matter how careful you are.
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.
No database means no SQL injection is possible
When you use Statamic, a visitor can't perform SQL injection through a contact form or any other email form. The reason is simple: Statamic doesn't store any data in a database. Everything is stored in files (YAML, Markdown, and PHP files).
No database → no SQL queries → SQL injection is technically impossible.
This is one of the biggest differences compared to WordPress, where almost all form plugins (Contact Form 7, Gravity Forms, WPForms, and others) write their data to a MySQL database, which means they can be vulnerable if they aren't perfectly secured.
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.
Something else I find a bit awkward and unsafe is that when you buy or download a plugin for WordPress, it comes as a .zip file. As a developer, that makes me wince a little. I get no information about the history of what's been done or changed in that plugin (I'm not entirely sure about this). Which means I have to go in and review the code myself, or use AI to help me find any vulnerabilities. I might be overly critical and cautious here, but it's something I've learned from this industry.
Compare that to Statamic, which uses a single place where you buy addons. When you install one, which only I as the developer can do, I do it through Composer, which is PHP's own package manager. And as a bonus, I can also see the history of these plugins through the version history in Git. I feel I have much more control over what actually gets installed on my client's server when I work with Statamic and Laravel.
Want to read more?
Austin Ginder was the person who alerted WordPress.org that something was wrong. He's written a very detailed article about the incident, including which plugins were infected.