WPManageNinja Ninja Tables Pro tampered build enables persistent WordPress backdoor

Ninja Tables Pro 5.2.11 contains an embedded malicious code vulnerability introduced via a tampered plugin build served through a decommissioned update server. The tampered build introduced a rogue PHP file (app/Library/updater/NinjaTableDataSync.php) that established a backdoor REST API endpoint, dropped persistent PHP files in mu-plugins and uploads directories, installed a passwordless administrator account, and registered scheduled tasks that survived plugin removal.

The supported affected scope and version boundaries are:

• The supplied record identifies WPManageNinja Ninja Tables Pro 5.2.11 as affected.
• VulnCheck lists Ninja Tables Pro <= 5.2.11 as affected. The WPManageNinja incident notice, however, specifically identifies the 5.2.11 build as tampered, so earlier versions should not be presumed compromised without evidence that a tampered build was received or executed.
• A site may be affected if it updated to or received the 5.2.11 build between 14:00 and 19:00 UTC on July 31, 2026. Because of network caching, downloads received on August 1, 2026 also require review.
• WPManageNinja identifies 5.2.14 as the clean release issued to replace the tampered build. Running an older version does not by itself prove compromise, but a site remains in the investigation group if it downloaded the plugin during the exposure window.

WPManageNinja Ninja Tables Pro is affected by CWE-506 because malicious code was embedded in a tampered plugin build rather than introduced through a legitimate plugin feature. The tampered build was served through an old update server that remained reachable through proxy routing after the distribution system had been migrated. The rogue PHP file app/Library/updater/NinjaTableDataSync.php established a REST API endpoint under the wp-update/v1 namespace and could write persistent PHP files into mu-plugins and uploads, register scheduled tasks, and alter WordPress data.

The exposure condition was that a site received and executed the tampered build, including through automatic updates. The vendor also warned that network caching could cause some downloads on the following day to receive the malicious files. Scheduled tasks and database data could continue operating after the plugin files were replaced or the plugin was removed, so updating or deleting the plugin alone does not prove that a site is clean. The supplied record describes a passwordless administrator account, while the vendor notice describes both an administrator bypass and sign-in through an existing administrator account; the exact account behavior may depend on the implant variant that ran on a particular site.

The structured record characterizes exploitation as network reachable, low complexity, requiring no prior privileges and no user interaction. The initial exposure condition still required a site to receive the tampered build through the affected update channel; automatic updates could satisfy that condition without a manual administrator action. The vendor confirmed that modified files reached customer sites during the incident window on July 31, 2026, and VulnCheck marks the advisory in its KEV database. The record does not identify a separate public exploit, named campaign, or ransomware use.

The malicious code operated in the WordPress context of the site and could establish persistence across plugin files, mu-plugins, uploads, the database, and scheduled tasks. The documented technical outcomes include creating or using administrator access, writing PHP files, registering a backdoor REST endpoint, changing configuration or disabling security plugins, and reading sensitive information from wp-config.php.

• Potential consequences include loss of website confidentiality, integrity, and availability.
• Control could persist after plugin removal because the implant's files and database rows were outside the plugin's normal lifecycle.
• The actual scope depends on whether the site received the tampered build and which actions the implant performed before detection.
• The record does not establish that every exposed site was used by an attacker or that a particular category of data was exfiltrated.

If the malicious code executed, the site could lose integrity through PHP file creation, database changes, configuration changes, or security-plugin deactivation. Administrative backdoor access could expose WordPress content and management functions, while access to wp-config.php or credentials stored in plugin settings could require the organization to rotate multiple related secrets.

• Files in mu-plugins, uploads, and scheduled tasks could preserve attacker access after an operations team only updates or removes the plugin.
• The site may experience downtime during isolation, cleanup, or restoration.
• Other sites using the same hosting account or server should be investigated because shared credentials or access could broaden the incident scope.
• The record does not establish that every site that downloaded the plugin was accessed or that specific data was stolen; the actual impact must be determined through file, database, log, and credential review.

1. If any check returns a hit, place the site in maintenance mode or take it offline where possible.
2. Delete the affected plugin directory rather than only deactivating the plugin. Remove unrecognized files from wp-content/mu-plugins/, delete unauthorized PHP files under wp-content/uploads/, remove the related database rows, and delete the scheduled tasks wp_update_check_schedule and wp_license_verify_schedule.
3. Repeat all checks after cleanup and again 24 hours later to detect reinfection or task-driven recreation. Install a fresh copy of Ninja Tables Pro 5.2.14 from the official WPManageNinja account or source.
4. Only after cleanup, replace the salts and keys in wp-config.php, reset administrator passwords, revoke application passwords, and rotate SMTP, payment, API, integration, database, hosting, and SFTP credentials.
5. Check other sites that share the server or hosting account. If the site cannot be verified clean, restore from a backup made before July 31, 2026 or rebuild the site after reviewing the database.
6. Use vendor-provided signature or checksum verification for plugin updates when available. Do not treat installation of the clean release as complete remediation until residual files, database data, scheduled tasks, logs, and credentials have been reviewed.

Perform the following checks on every site that updated the plugin during or near the incident window:

• Review update history and plugin inventory, including automatic updates, for July 31, 2026 and for downloads that may have been affected by caching on August 1, 2026.
• Check for wp-content/plugins/ninja-tables-pro/app/Library/updater/NinjaTableDataSync.php. The vendor states that this file is not present in legitimate releases.
• Review wp-content/mu-plugins/ and wp-content/uploads/ for PHP files that were not installed by the site owner, hosting provider, or a known vendor. Any unexplained PHP file under uploads and any unaccounted-for file under mu-plugins should be treated as a compromise indicator.
• Search the WordPress database for options containing the implant's reporting address:

SELECT option_name FROM wp_options WHERE option_value LIKE '%apii.observer%';

• Check for scheduled tasks named wp_update_check_schedule and wp_license_verify_schedule, then test the REST route /​?rest_route=/wp-update/v1/check; a response other than 404 indicates that the route may still be active.
• Review access logs for confirm_admin_email with an unusually long random wp_lang value and for updatelink=. Review administrator accounts, unexplained security-plugin changes, and accounts that cannot be attributed to an authorized user, especially accounts registered on or after July 31, 2026. A clean scanner result is not sufficient because the implant could make a malicious account appear to be a known administrator.