How to Verify a WordPress Plugin Update Is Genuine

On July 31, 2026, WPManageNinja's own update servers shipped backdoored builds of Fluent Forms Pro and Ninja Tables Pro straight through the plugin's real, trusted update channel. Nobody's code had a bug. The plugins were fully patched. The thing that failed was the pipe the update traveled through, and every site that pulled a fresh copy during a five-hour window got a passwordless admin account along with it.

That's not a one-off. Our blog has covered three of these incidents this year, each through a different failure mode. Clicking "update now" is supposed to be the safe, boring action on a WordPress site. This guide covers what to check after you click it, so an update you trusted can't quietly own your site.

Three times the update channel itself was the attack

Smart Slider 3 Pro, April 7, 2026. An unauthorized party got into Nextend's update infrastructure and pushed a trojanized build of Smart Slider 3 Pro, tagged 3.5.1.35, through the plugin's official auto-update channel. For about six hours, any site with auto-updates enabled that checked in received a backdoor that dropped persistence in three separate places: a must-use plugin, the active theme's functions.php, and a fake file inside wp-includes disguised as a core file. It also accepted pre-authenticated remote code execution via custom HTTP headers. We covered the full backdoor fingerprint and cleanup steps in our Smart Slider 3 Pro backdoor writeup.

The Essential Plugins portfolio, planted August 2025, activated April 2026. This one didn't involve breaking into anything. A buyer purchased a portfolio of roughly thirty small utility plugins through Flippa, then shipped a shared-library update in August 2025 that did nothing visible. Eight months later, on April 5, 2026, the dormant code woke up and injected roughly 6 KB of PHP into wp-config.php, serving SEO spam only to Googlebot while human visitors saw nothing wrong. The command-and-control address was read from an Ethereum smart contract, so blocking one domain didn't stop it. WordPress.org closed at least thirty plugins from the author on April 7. Full details are in our Essential Plugins supply chain writeup.

Fluent Forms Pro and Ninja Tables Pro, July 31, 2026. WPManageNinja had migrated its store and licensing system off Easy Digital Downloads, but left the old server's update routing switched on. An attacker found the decommissioned server and used it to serve tampered Fluent Forms Pro 6.2.7 and Ninja Tables Pro 5.2.11 builds between 14:00 and 19:00 UTC. The tampered files opened a backdoor REST endpoint, dropped persistence into mu-plugins and the uploads folder, created a passwordless administrator account, and registered WP-Cron entries to survive removal. Roughly 295 of 1,368 notified accounts actually received the tampered files. Our Fluent Forms and Ninja Tables backdoor writeup has the full indicator list, and the "How a Trusted Update Channel Becomes the Attack" section of our August 2026 vulnerability roundup puts it in the context of that month's disclosures.

Three different root causes: a compromised update server, a purchased author account with a dormant payload, and a forgotten server nobody decommissioned. Same result each time: sites installed malicious code through an update they had every reason to trust, and nothing in the update process itself would have told them.

What wordpress.org does about this today

WordPress.org has added two defenses on the plugin-directory side in 2026: a 6-hour cooldown between a developer publishing a release and it going live, and, as of September 9, 2026, an automated security review during that window using AI plus Jetpack Scan that auto-blocks releases it flags as high risk. Neither covers premium or third-party plugins distributed outside wordpress.org, which is where Smart Slider 3 Pro and the Fluent Forms and Ninja Tables builds came from. The Essential Plugins code did ship through wordpress.org, before either defense existed. We covered this in more depth in why WordPress vulnerabilities are rising, including WordPress.org's own announcement of the review.

That review buys time and catches obviously malicious code before it reaches your site, but it doesn't replace checking the update after it lands. It also doesn't extend to the update servers vendors run themselves, which is where two of the three incidents above actually happened.

Checks to run after any update that feels off

Most updates are fine and don't need this. Run these checks when a plugin update behaves unexpectedly, when you get a vendor security notice after the fact, or as a habit after updating anything with broad site access (forms, page builders, membership plugins).

Verify checksums for plugins hosted on wordpress.org:

wp plugin verify-checksums --all

This compares your installed plugin files against the checksums wordpress.org publishes for that exact version. Add --strict to also flag minor changes like an edited readme.txt. The real limit to know: this only works for plugins actually distributed through wordpress.org. Premium plugins like Fluent Forms Pro, sold and updated through the vendor's own site, have no checksums on wordpress.org to check against at all. For those, the file diff and behavioral checks below are what you have.

Verify WordPress core the same way:

wp core verify-checksums

This checks only WordPress core files against wordpress.org's published checksums. It says nothing about plugins, themes, or anything in wp-content, so it's a separate check from the plugin one above, not a substitute for it.

Diff the plugin's files between versions. For a wordpress.org plugin, download the previous and current version's zip from the plugin's Advanced View page and diff the two directories. For a premium plugin, keep your own copy of the last version you trusted and diff against that after every update. You're looking for anything that doesn't match the vendor's published changelog: a new file that isn't mentioned, a require_once added to a bootstrap file, a REST route you didn't expect.

Watch for new files outside the plugin's own directory. Smart Slider 3 Pro and the Fluent Forms and Ninja Tables builds dropped files in wp-content/mu-plugins/, wp-content/uploads/, or wp-includes/, because those locations survive a plugin update or removal. The Essential Plugins payload went into wp-config.php instead, so check that file too. Check mu-plugins directly on the filesystem since it doesn't show up in the Plugins screen, and check uploads for any PHP file, since that directory should never contain executable code.

Check for new administrator accounts:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Run this before and after an update you're unsure about, and compare. A new account you don't recognize, especially one registered right after the update, is one of the clearest signs something rode in with it.

Check scheduled events:

wp cron event list

The Fluent Forms and Ninja Tables backdoor registered WP-Cron entries specifically so the compromise would survive the plugin being deleted. Cron entries live in the options table, not tied to the plugin file that scheduled them, so this check still matters even after you've removed a plugin you suspect.

Watch for outbound requests to unfamiliar domains. This needs server-level or hosting-level monitoring rather than a WP-CLI command, since WordPress itself doesn't log outgoing HTTP calls. If your host or firewall can show you outbound connections, a plugin suddenly calling a domain it never called before is worth investigating regardless of what the plugin's own code claims to do.

Check the vendor's changelog and public announcements. If an update changed behavior you didn't expect, or a security researcher or forum thread is reporting something odd, the vendor's own changelog and status page are the fastest way to find out whether it's a known issue. WPManageNinja published a full incident report and timeline within hours of catching its own compromise, which is exactly the kind of public statement worth checking for before you assume an update is safe.

WP Vanguard's scan checks the plugin versions on your site against our vulnerability database. It doesn't verify checksums or diff plugin files against a prior version, so the checks above are still yours to run by hand after an update that concerns you. Run a scan on your site to see what's currently installed and whether any of it has a known, disclosed vulnerability.

When to delay an auto-update and when not to

A security release patching a vulnerability that's actively being exploited should go in the same day, not after a delay. Patchstack's data puts the median time from disclosure to exploitation at around 5 hours, covered in more detail in why WordPress vulnerabilities are rising, which leaves no real margin for waiting.

A routine feature or maintenance release is a different case. Waiting a few hours before applying it, rather than updating the instant it appears, gives support forums and the vendor's own channels time to surface a problem if the release itself is broken or compromised. None of the three incidents in this guide involved a security patch being delayed; they involved a normal-looking update being the attack. A short delay on non-security releases, combined with the checks above after anything unusual, closes more of the gap than either habit alone.

Related guides: how to check your plugins for known vulnerabilities, premium plugins on an expired licence, abandoned and closed plugins, and our weekly patch list.

References

• WP-CLI: wp plugin verify-checksums
• WP-CLI: wp core verify-checksums
• WP-CLI: wp cron event list