This CVE represents a supply chain compromise through an orphaned update server—a structural failure the CVSS score of 9.8 captures crudely but doesn't explain. The tampered Fluent Forms Pro build wasn't intercepted in transit; it was served from a server that should have been decommissioned. The attack succeeded by exploiting a lifecycle management gap, not a code vulnerability.
Three compounding mechanisms made this foothold persistent. First, a require_once directive injected into the core plugin loader provided code execution. Second, a passwordless administrator account was created—not as a obvious backdoor, but as a misconfiguration that standard forensic procedures classify as 'sloppy hygiene' rather than active compromise. Third, scheduled tasks survived plugin removal, persisting in the database independently of whether the plugin was reinstalled or removed. These mechanisms share a design principle: they survive the standard WordPress remediation workflow, which treats plugin removal as eradication.
The backdoor REST API endpoint adds a detection gap. WordPress REST API authentication failures return 401/403 but don't log the attempted route by default in many configurations. An attacker with knowledge of this endpoint can probe silently, making detection dependent on external indicators rather than internal telemetry.
The structural vulnerability is this: the WordPress plugin ecosystem assumes vendor continuity rather than planning for vendor mortality. There's no standard mechanism for update server deprecation, no grace period before a server becomes untrusted, and no ecosystem-level signal that an update channel is orphaned. When Fluent Forms Pro's vendor maintained a trust relationship with infrastructure they no longer secured, every site polling that endpoint received the compromised build automatically.
For defenders, the immediate actions: audit your plugin inventory for update endpoints and validate that each server's operator is still active. Enumerate all scheduled tasks regardless of whether their originating plugin exists. Check for administrator accounts created without password assignment—these masquerade as misconfigurations but may be active persistence. After removing a compromised plugin, manually inspect the database for residual cron jobs and review the mu-plugins and uploads directories, which persist after plugin removal. The persistence mechanisms exist precisely because standard remediation treats plugin removal as complete cleanup—it isn't, and attackers know this.