EssentialPlugin supply-chain attack (April 2026): what to check

The EssentialPlugin attack was a supply-chain compromise: a buyer purchased a portfolio of WordPress plugins, slipped a backdoor into them in 2025, and activated it on April 5 to 6, 2026. WordPress.org closed all the plugins on April 7 and pushed a forced update, but that update did not clean the code injected into wp-config.php. If you ever ran one of these plugins, check that file by hand and remove the plugins.

What happened in the EssentialPlugin attack?

EssentialPlugin was a vendor with a large catalog of small WordPress plugins. According to Patchstack, the vendor was sold through Flippa in 2025 to a buyer using the name “Kris”. A later commit titled “Check compatibility with WordPress version 6.8.2” planted a backdoor across the plugins. Patchstack dates that commit to September 2025, while The Next Web dates the shipped version 2.6.7 to August 8, 2025. Sources disagree on the exact month, so I will say only that it was planted in the second half of 2025.

The backdoor then sat dormant for about seven to eight months. It was first used on April 5, 2026, and the injection window on April 6 ran 04:22 to 11:06 UTC, per The Next Web. On April 7, the WordPress Plugin Review team confirmed the attack and permanently closed the plugins.

The number of plugins varies by source:

Patchstack lists 22 affected plugins and mentions “more than 20” and “25+”.
dxw refers to 26 plugins previously owned by the vendor.
The Next Web says WordPress.org closed 31 plugins on April 7.

I would treat any plugin from this vendor as affected, whatever the exact count.

How did the backdoor work?

Patchstack describes the mechanism like this:

Each affected plugin registered an unauthenticated REST API endpoint with no permission check.
The callback fetched data from analytics.essentialplugin.com and passed the response to PHP’s unserialize().
A gadget chain in the plugin’s own class turned that into an arbitrary file write, which could drop a PHP file such as wp-comments-posts.php on the server.

The Next Web adds that the dropped file was used to inject PHP into wp-config.php, and that the payload served spam links, redirects and fake pages only to Googlebot. That cloaking is why site owners saw nothing wrong while their search results filled with spam. The same article reports that the command-and-control address was resolved through an Ethereum smart contract, which would make a plain domain seizure ineffective.

The Next Web notes that attacks like this succeed because WordPress.org has no review or notification when a plugin changes owner, no mandatory code signing, and no mandatory two-factor authentication for plugin developers.

How do I check if my site is affected?

List your plugins (Dashboard, Plugins) and check the author. Anything published by “essentialplugin” or “Essential Plugin” is in scope. Examples named in coverage include Countdown Timer Ultimate and WP FAQ.
Look for an admin notice from the WordPress Plugins Team about plugin code that could allow unauthorized third-party access. dxw lists this as one indicator, along with a plugin disappearing from the plugin directory.
Look for a file named wp-comments-posts.php in the site root. The real WordPress file is wp-comments-post.php (no “s”), so the extra letter is the tell. This file name is documented by Patchstack as the dropped file.
Open wp-config.php and read it. Any code you did not put there, especially anything that makes remote requests or includes other files, is a red flag.
Test as a crawler. Because the spam was shown only to Googlebot, check Google Search Console for pages you did not create, or search site:yourdomain.com for unexpected pharma, casino or loan keywords.
Check access logs for requests to the plugin’s analytics REST route and for outbound requests to essentialplugin.com.

What should I do if I used these plugins?

Back up first so you have evidence, then put the site into maintenance mode if you see signs of infection.
Remove the plugins. I delete every EssentialPlugin plugin whatever the version, because WordPress.org closed them permanently and they will not get normal updates again. Find a replacement with a maintained author.
Clean wp-config.php by hand. WordPress.org’s forced update (version 2.6.9.1, per The Next Web) neutralized the phone-home but did not remove injected code in wp-config.php. dxw says the same: a plugin update alone is not enough.
Delete wp-comments-posts.php and search the uploads folder and plugin folders for PHP files you did not add.
Rotate credentials: the database password, salts and keys in wp-config.php, all admin passwords, and hosting and SFTP logins. A file write on the server means the database credentials in wp-config.php should be treated as exposed.
Review users for administrators you did not create.
Request a review in Google Search Console if the site was flagged for spam or hacked content, after cleanup.

If the site is business critical, restoring a backup taken before April 2026 and then updating everything is often faster than a line-by-line cleanup. Remove the plugins before you restore, since the backdoor code was in them from 2025.

How do I avoid the next supply-chain attack?

I cannot make plugin ownership changes visible for you, but I can reduce the damage when one goes wrong.

Audit your plugin list twice a year. Remove anything you do not use. Each one is a trust relationship.
Watch for withdrawn plugins. dxw’s automation caught this incident by detecting that the plugins were pulled from the directory.
Restrict file writes. dxw treats site code, including wp-config.php, as essentially immutable and blocks plugins from writing to arbitrary locations. dxw says this prevented the compromise from completing on its sites even where the malicious code was present.
Keep tested backups and know how to roll back, so you can undo a bad update quickly.
Do not turn off auto-updates for security releases, but be aware they can also deliver a compromised update, as happened in the Smart Slider 3 Pro incident the same week.
Check who owns a plugin before you depend on it, and re-check when a major update lands after a long quiet period.

FAQ

How many plugins were affected by the EssentialPlugin attack?

Sources disagree: Patchstack lists 22, dxw says 26, and The Next Web reports that WordPress.org closed 31. Treat every plugin from the vendor as affected.

Did the WordPress.org forced update fix my site?

Only partly. It neutralized the backdoor in the plugin, but The Next Web and dxw both report it did not remove code already injected into wp-config.php, so you must check that file manually.

Was this the same as the Smart Slider 3 Pro attack?

No, those were separate incidents in the same week. Smart Slider 3 Pro was compromised through the vendor’s update infrastructure, according to The Next Web, while EssentialPlugin was compromised after the vendor changed hands.

Is it safe to keep an EssentialPlugin plugin if it is updated?

No. All the plugins were permanently closed on April 7, 2026, so they get no normal updates. I remove them regardless of version. Replace them with a maintained alternative.