Two supply chain attacks hit WordPress in a single week.
In the first, someone purchased a portfolio of 30+ WordPress plugins on Flippa, quietly injected a backdoor into every single one, waited eight months, and then flipped the switch. In the second, attackers hijacked the update server for Smart Slider 3 Pro and pushed a fully weaponized version to every site that auto-updated during a six-hour window.
This happened in the first two weeks of April 2026. If you run WordPress, you should read this carefully. If you used to run WordPress and migrated away, like I did, this is a grim validation of that decision.
I wrote about migrating my portfolio off WordPress not long ago. That post focused on the architecture and cost side of things. This one is about the other reason I left: the security model around WordPress plugins is broken, and it's getting worse.
The EssentialPlugin Attack
On April 7, 2026, the WordPress.org Plugins Team permanently closed over 30 plugins from a vendor called EssentialPlugin. All in one day. The reason: every single plugin in the portfolio had been carrying a PHP deserialization backdoor since August 2025.
The story was first documented by Austin Ginder at Anchor Host. One of his managed hosting clients flagged a security notice in wp-admin. Ginder ran a full audit and found malware hiding in wp-config.php. The injected code was fetching spam links, redirects, and fake pages from a command-and-control server. It only showed the spam to Googlebot, making it completely invisible to site owners.
Here is the timeline, as documented by Patchstack:
The original EssentialPlugin team (formerly WP Online Support) had been building WordPress plugins since 2015. By late 2024, revenue had dropped 35-45%. The founder listed the entire business on Flippa. A buyer going by "Kris," with a background in SEO, crypto, and online gambling marketing, acquired everything for six figures. Flippa even published a case study about the sale.
The buyer's very first SVN commit was the backdoor.
Version 2.6.7 of Countdown Timer Ultimate, released August 8, 2025, included a changelog entry that read: "Check compatibility with WordPress version 6.8.2." What it actually did was add 191 lines of code containing a PHP deserialization vulnerability. The class-anylc-admin.php file grew from 473 to 664 lines. The new code introduced an unauthenticated REST API endpoint (permission_callback: __return_true), a fetch_ver_info() method that passed remote data directly to @unserialize(), and a version_info_clean() method that let the attacker's server control which PHP function gets called and with what arguments.
In practice, the attacker's server could respond with a serialized payload that turns into @file_put_contents("/var/www/html/wp-comments-posts.php", "<?php /* backdoor */ ?>"). Arbitrary file write. Full server compromise.
The backdoor sat dormant for eight months. On April 5-6, 2026, the analytics.essentialplugin.com endpoint started serving malicious serialized payloads. The six-hour-and-44-minute attack window was enough to infect sites running any of the 30+ affected plugins.
The malware was clever. It resolved its C2 domain through an Ethereum smart contract, querying public blockchain RPC endpoints. Traditional domain takedowns don't work when the attacker can update a smart contract to point somewhere new anytime they want.
Smart Slider 3 Pro: The Update Server Attack
A few days later, on April 7, 2026, a separate group of attackers compromised the update infrastructure for Smart Slider 3 Pro. Smart Slider has over 800,000 active installations. The attackers pushed a poisoned version (3.5.1.35) through the official update channel. Every site that updated during the six-hour window before Nextend caught it got a fully weaponized remote access toolkit.
This one was more aggressive than EssentialPlugin. Patchstack's full technical analysis showed the malware had seven distinct components:
Remote shell via HTTP headers. The malware checked every single page load for a custom X-Cache-Status header with a hardcoded value. If present, it would read a second header (X-Cache-Key), base64-decode it, and pipe it directly to shell_exec(). Unauthenticated remote code execution, disguised as CDN traffic.
Dual-mode backdoor. A secondary backdoor supporting both PHP eval and OS command execution. It iterated through six different shell functions (shell_exec, exec, system, passthru, proc_open, popen) and used the first one available. Even hardened PHP configurations couldn't block it.
Hidden admin accounts. The malware created an administrator account named wpsvc_ followed by a hash of the site URL (like wpsvc_a3f1), with the display name "WordPress Service" to look like a system account. It then patched the pre_user_query filter to hide this user from the Users screen and adjusted the role count badges so the numbers still added up. Administrators would never see the rogue account in their dashboard.
Four persistence layers. The malware didn't just live in the plugin. It copied itself into a must-use plugin (object-cache-helper.php), appended itself to the active theme's functions.php, dropped a file in wp-includes/ mimicking a core class, and stored its own authentication key in the database. Deleting the plugin doesn't clean any of this up.
C2 registration and data exfiltration. On activation, the malware phoned home to wpjs1.com with the site URL, WordPress version, PHP version, database name, admin email, and the plaintext username and password of the hidden admin account.
Nextend pulled the malicious version within six hours and released a clean 3.5.1.36. But as The Hacker News reported, any site that installed the compromised version needs a full manual cleanup, not just a plugin update.
The ACF Connection (This One Hit Close to Home)
Back in January 2026, a critical vulnerability was found in ACF Extended (Advanced Custom Fields: Extended), giving unauthenticated attackers full admin access on over 50,000 WordPress sites.
This one got my attention for personal reasons. I used ACF for years. It was the backbone of how I stored structured data in WordPress: project URLs, tech stacks, experience dates, all of it. In my migration post, I wrote about how ACF fields were "a mess of meta key/value pairs that required multiple JOINs just to get a project's GitHub URL."
Turns out the data model wasn't the only problem. The plugin itself was a security risk. If I had still been running my portfolio on WordPress with ACF when that exploit dropped, an attacker could have silently created themselves an admin account on my site. On my portfolio. The site that represents me professionally.
The Numbers Are Getting Worse
According to Patchstack's State of WordPress Security report, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025. That's a 42% increase from 2024. Of those, 91% were in plugins. Not WordPress core. Plugins.
Some other numbers from the report that are hard to ignore:
- 1,966 vulnerabilities had a high severity score, meaning they could be mass-exploited in automated attacks. That's more than the previous two years combined.
- 5 hours is the median time from vulnerability disclosure to active exploitation for the most targeted flaws. Not days. Hours.
- 46% of vulnerabilities did not receive a patch from the developer in time for public disclosure.
- Hosting companies' defensive tools (WAFs, Cloudflare, etc.) only blocked 26% of WordPress vulnerability attacks in Patchstack's pentesting study.
- 76% of vulnerabilities found in premium (paid) components were exploitable in real-world attacks. Premium components also had 3x more Known Exploited Vulnerabilities than free ones.
The attack surface keeps growing, and the window to respond keeps shrinking.
This Has Happened Before
The EssentialPlugin attack isn't a new playbook. It's a proven one, just executed at a bigger scale.
In 2017, a buyer using the alias "Daley Tias" purchased the Display Widgets plugin (200,000 installs) for $15,000 and injected payday loan spam. That same buyer went on to compromise at least 9 plugins the same way.
The pattern is always the same: buy a trusted plugin with an established user base, inherit the WordPress.org commit access, and inject malicious code. The trust transfers with the sale, but the intentions don't.
What makes the EssentialPlugin case worse is the scale (30+ plugins), the sophistication (blockchain-based C2 resolution, Googlebot-targeted cloaking), and the patience (8 months dormant). And the fact that Flippa published a case study celebrating the sale.
WordPress Has a Structural Trust Problem
WordPress.org has no mechanism to flag or review plugin ownership transfers. There is no "change of control" notification to users. No additional code review triggered when a new committer starts pushing to a plugin with tens of thousands of active installs. The Plugins Team responded quickly once the attacks were discovered, but eight months passed between the EssentialPlugin backdoor being planted and being caught.
Think about what that means for anyone running WordPress in production. You install a plugin. It works fine. You enable auto-updates because that's the recommended practice. The plugin changes hands. The new owner pushes a "compatibility update." Your site is now running code from someone you've never heard of, reviewed by nobody, with full access to your server.
This isn't a bug. It's how the system is designed to work.
And it's not just the marketplace. Modern WordPress malware is designed to survive cleanup. The Smart Slider backdoor had four independent persistence layers. The EssentialPlugin malware injected itself into wp-config.php on the same line as the require_once for wp-settings.php, making it easy to miss on a quick scan. Patchstack's report found that memory-resident malware (like the Lock360 family) runs in server memory and automatically reinfects files the moment they're restored. Support teams clean an infection, and it rewrites itself immediately.
Why I'm Glad I Left
When I moved my portfolio off WordPress, the primary motivation was architectural. I was tired of maintaining a full CMS installation to serve a handful of pages. The GraphQL queries were brittle. The hosting costs didn't match the scale. Every time a plugin updated, something would quietly break.
But reading about these attacks, I realize the security argument might actually be the stronger one.
My old setup had WPGraphQL, ACF, Yoast SEO, and whatever other plugins had accumulated over the years. That's multiple third-party codebases, each with their own update cycle, their own security track record, and their own potential to change ownership at any time. I had no visibility into any of that.
Now my portfolio runs on a Next.js app with a Postgres database on Railway and images on Cloudflare R2. The admin panel is part of the same codebase. There's one user (me), authenticated through a simple session. No plugin marketplace. No third-party code I haven't reviewed. No update channel that someone else controls.
Could my setup get hacked? Sure, anything can. But the attack surface is dramatically smaller. There's no universe of plugins where a random acquisition on Flippa can inject code into my server.
What To Do If You Still Run WordPress
I'm not going to tell you to stop using WordPress. 43% of the web runs on it. Most of those sites are fine. But if you do run WordPress, especially in a professional capacity, here are some things worth doing right now:
Check for EssentialPlugin plugins. Search your site for any of the 30+ plugin slugs listed in Ginder's post. If you find one, inspect wp-config.php immediately. The injected payload adds about 6KB and sits on the same line as the require_once statement.
Audit Smart Slider 3 Pro. If you're running the Pro version, make sure you're on at least 3.5.1.36. If version 3.5.1.35 was ever installed, even briefly, treat the site as fully compromised. Check for user accounts matching the wpsvc_* pattern, files named object-cache-helper.php in mu-plugins, class-wp-locale-helper.php in wp-includes, and modifications to your theme's functions.php. Nextend has a detailed cleanup guide.
Review your plugin list honestly. How many plugins are you running? How many are actively maintained? How many have changed ownership in the last year? Every plugin is a potential entry point. If a plugin hasn't been updated in a year and you can live without it, remove it.
Don't rely on auto-updates as security. Auto-updates are a good practice, but they can also be weaponized. Both of these attacks were delivered through legitimate update channels. Consider running a staging environment and reviewing updates before they hit production, especially for plugins with broad server access.
Monitor ownership changes. This is hard because WordPress.org doesn't surface this information well. But if a plugin you rely on suddenly changes its author name, website, or starts pushing "compatibility" updates with vague changelogs, that's worth investigating.
Keep backups that go back months. Ginder traced the EssentialPlugin infection window using daily restic backups going back to November 2025. If he'd only had 30 days of backups, the injection point would have been invisible. Long-term backups aren't just for disaster recovery. They're forensic tools.
The Bigger Picture
WordPress powers a huge chunk of the internet. That makes it a permanent target. The platform itself (WordPress core) has had remarkably few vulnerabilities. Only 6 were reported in the core in all of 2025, and they were all low-priority. The problem is the ecosystem around it.
The plugin model gives millions of site owners access to functionality they couldn't build themselves. That's genuinely valuable. But the same model means those site owners are trusting code from thousands of independent developers with varying levels of security awareness, maintenance commitment, and, as we just saw, intent.
Two supply chain attacks in one week. A critical ACF vulnerability that would have given strangers admin access to my old site. Over 11,000 new vulnerabilities in a single year. Attackers weaponizing new flaws within 5 hours of disclosure. Hosting companies blocking only a quarter of attacks.
For my portfolio, moving to a custom stack was the right call. Your situation is different. But whatever you're running, pay attention to what happened this month. The people who planted that EssentialPlugin backdoor waited eight months before pulling the trigger. There might be others still waiting.