WordPress Supply Chain Attack: Fluent Forms, Ninja Tables Pro

On July 31, 2026, between 14:00 and 19:00 UTC, WPManageNinja's own update servers pushed backdoored builds of Fluent Forms Pro 6.2.7 and Ninja Tables Pro 5.2.11 to customer sites. This is one of the cleanest examples of a wordpress supply chain attack you'll see this year, and it's worth studying closely because nobody's code was actually broken. Fluent Forms Pro was fully patched. Ninja Tables Pro was fully patched. The plugins themselves had no vulnerable function, no missing nonce check, no bad sanitize_text_field() call. The problem sat one layer below the code: in a server WPManageNinja had already stopped using.

WPManageNinja notified 1,368 customers who had downloaded either plugin on July 30 or 31. Its own investigation puts the number who actually received tampered files at roughly 295 accounts. The company caught the breach, killed the old server's routing, and shipped clean builds the same evening. That's a fast response by any measure. It doesn't change what the backdoor did to the sites that got it, or what it means for how the rest of us think about "trusted" plugin updates.

How the Backdoor Got Into Fluent Forms Pro 6.2.7

The tampered Fluent Forms Pro build shipped with a new file: libs/class-license-sync.php. That file didn't exist in the legitimate releases either side of it. It got loaded through a single added line, a require_once directive dropped into fluentformpro.php, the plugin's main bootstrap file. That's the entire injection point. One include statement, sitting in the file every WordPress install already trusts and auto-loads on every request.

Once that file ran, it did four things. It stood up a backdoor REST API endpoint, giving the attacker a remote control channel that didn't depend on WordPress's normal admin login flow. It dropped persistent PHP files into both the mu-plugins directory and the uploads folder, which meant the backdoor didn't live only inside the compromised plugin. It created a passwordless administrator account, so even a site owner who spotted the plugin and deleted it outright could still have a live admin session waiting for the attacker. And it registered scheduled tasks through WP-Cron that kept the whole chain alive independent of the plugin's presence.

That last point matters more than it sounds. WP-Cron entries aren't tied to a specific plugin file existing on disk; they're stored in the options table and fire based on time, not on whether the code that scheduled them is still installed. Ninja Tables Pro 5.2.11 carried a comparable payload, tuned to that plugin's own update-checking class rather than Fluent Forms Pro's license sync file, but built around the same idea: hook into a file the plugin already loads on every page load, and use that hook to build persistence that survives the plugin's removal.

If you want the deeper mechanics of how PHP backdoors keep themselves alive across cleanups, we've written about that pattern in more general terms in our guide to PHP backdoors in WordPress.

Who Ran the Vulnerable Builds

You were exposed if your site downloaded Fluent Forms Pro or Ninja Tables Pro through the plugin's own update mechanism, or via a fresh purchase and install, during that five-hour window on July 31, 2026. Fluent Forms Pro 6.2.7 and Ninja Tables Pro 5.2.11 are the specific tampered versions; the clean releases the vendor shipped that same evening are Fluent Forms Pro 6.2.10 and Ninja Tables Pro 5.2.14. Versions before 6.2.7 and 5.2.11 were never touched, because the attacker only had control of the download that particular window served, not the whole release history.

No special configuration made a site more or less exposed. This wasn't a flaw that only fires with a specific setting enabled, the way a lot of plugin vulnerabilities work. If your update check happened to land in that window and pulled a fresh copy of either plugin, you got the tampered file. If it didn't, you're on a clean build regardless of your settings. That's an uncomfortable kind of randomness for a security incident: timing, not configuration, decided who got hit.

WPManageNinja's notification list skews wide on purpose. Emailing 1,368 accounts to cover an estimated 295 actual compromises is the right call when your download logs from a hastily decommissioned server aren't complete. If you run either plugin and never got a notification, it's still worth checking your own update timestamps against the window rather than assuming you're clear.

This Is a Supply Chain Attack, Not a Coding Bug

Here's the part that makes this incident different from most of what lands in a WordPress vulnerability database. WPManageNinja migrated its store and licensing system off Easy Digital Downloads onto its own in-house platform at some point before July 2026. That's a normal, sensible move for a vendor at scale.

The mistake was what happened to the old EDD-era server afterward: it kept running, and the proxy routing that decided where update requests actually went still pointed at it under certain conditions. Nobody had turned it off. Nobody was watching it. An attacker found it, got in, and used it to serve tampered files through what looked, from the customer's side, like the same trusted update channel it had always been.

A fully patched site running only reputable, actively maintained premium plugins still got backdoored here, because the compromise never touched the plugin's source code at all. It touched the infrastructure that decides what gets served when your site calls home for an update. That's the core lesson: plugin security review, code audits, and CVE tracking all assume the file you're auditing is the file that ends up on your server. A supply chain attack breaks that assumption upstream of anything a code reviewer would ever see.

This isn't the first time WordPress has watched trust flow the wrong way through an update channel. Earlier in 2026, a cluster of essential plugins carried a backdoor traced back to a compromised build pipeline, which we covered in our supply chain backdoor writeup from April. The Smart Slider 3 Pro and Nextend compromise followed a similar shape too, where the vendor's own distribution got hijacked rather than the plugin code being flawed on its face; we broke that one down in our Smart Slider 3 Pro backdoor analysis.

What's specific to WPManageNinja's case is the cause: not a stolen signing key or a compromised build server actively in use, but infrastructure that was supposed to already be dead. A migration left a door unlocked, and it stayed unlocked long enough for someone to walk through it.

If you run a plugin business, or manage infrastructure for one, the actionable version of this lesson isn't "review your code more carefully." It's "when you migrate a store or licensing system, decommissioning the old server is part of the migration, not a cleanup task for later." Old servers don't need a vulnerability to be dangerous. They need someone to still be listening on the other end of a route your customers' sites still trust.

What to Do If You Installed Fluent Forms Pro or Ninja Tables Pro

Updating to Fluent Forms Pro 6.2.10 or Ninja Tables Pro 5.2.14 does not clean an already-compromised site. That's worth repeating because it's the single most important operational detail here: this backdoor was built specifically to survive a plugin update or removal. Updating replaces the plugin's files, but it does nothing about the mu-plugin files already dropped on disk, the files sitting in your uploads directory, the passwordless admin account already created, or the cron jobs already registered in your options table.

If your site downloaded either plugin between July 30 and 31, 2026, check these specifically:

• wp-content/mu-plugins/ for any PHP file you don't recognize, especially anything added around that date. Mu-plugins load on every request and don't show up in the normal Plugins screen, which is exactly why the backdoor used that location.
• wp-content/uploads/ for PHP files. Uploads directories should never contain executable PHP; if wp_is_writable() protections were bypassed, most hosts and security plugins will flag this immediately once you look.
• Your users list for any administrator account you didn't create, particularly one with a recent registration date and no obvious owner. Check the password reset date too; a passwordless account can look otherwise ordinary.
• wp_options and your scheduled events for cron jobs referencing update or license sync functions you don't recognize. wp cron event list via WP-CLI is the fastest way to see everything currently scheduled, including entries a plugin no longer installed left behind.

If you find any of these, treat it as a full compromise, not a plugin problem. Rotate all admin passwords and API keys, and go through a proper cleanup rather than just deleting the suspicious files you found. We cover the general signs of a compromised site and the full remediation process in our guide to signs your WordPress site is hacked and our WordPress malware removal guide, both of which apply directly here since the indicators of compromise are the standard ones: rogue mu-plugins, unexpected admin users, and persistent cron entries.

WPManageNinja has since shut down the old server's routing entirely and moved Fluent Forms Pro to signed updates, verifying a cryptographic signature and file hash before an update installs rather than trusting the download channel by default. WP Vanguard scans check for exactly this class of indicator, unrecognized mu-plugins, suspicious admin accounts, and unfamiliar cron entries, on sites that may have pulled an update during the exposure window.

Separately, and unrelated to this backdoor, the Fluent Forms Pro Add On Pack carried an unauthenticated stored XSS issue in versions before 6.2.12, disclosed on August 18, 2026, and fixed in that release. If you're already updating for the backdoor, updating past 6.2.12 covers that issue too, but it's a distinct vulnerability with its own cause and doesn't involve the tampered server.

References

• WPManageNinja: Security Incident on 31 July 2026
• VulnCheck: Fluent Forms Pro Embedded Malicious Code via Tampered Plugin Build
• Patchstack: Fluent Forms Pro Add-On Pack Plugin 6.2.7 Remote Code Execution Vulnerability
• Fluent Forms: Signed Updates for Fluent Forms Pro