Wordfence has disclosed a SQL injection vulnerability in Backuply, a WordPress backup plugin with more than 600,000 active installations, that can let an attacker with only a subscriber account take over a site. The flaw, CVE-2026-93953, carries a CVSS score of 8.8. It affects all versions up to and including 1.5.8 and is fixed in 1.5.9.
A Second-Order Injection Planted in a Subscriber’s Profile
Wordfence published the advisory on October 15. The vulnerability is a second-order SQL injection, meaning the malicious input is stored first and used later. An authenticated subscriber, the lowest standard WordPress role, places a payload in the Biographical Info field of their profile.
How Backuply Carries the Payload Into a Restore Query
Backuply writes the profile data into a database backup. When an administrator later restores that backup, an unanchored regular expression matches the stored text and concatenates it into an UPDATE query. The planted payload then executes as part of that query.
From Restore to Administrator Registration
The injected query changes two site settings. It sets users_can_register to 1 and default_role to administrator. With those values in place, the attacker can register a new account through the normal registration process, and that account is automatically assigned the administrator role.
An Administrator Must Restore the Tainted Backup First
Full site compromise is possible, but only after an administrator restores a backup that contains the planted data. The attack therefore depends on a legitimate administrative action taking place after the payload is stored. Wordfence’s description does not say how often such restores occur.
The Attack Sequence in Order
The full chain has four steps. First, a subscriber saves the payload in the Biographical Info field. Second, Backuply includes that profile data in a database backup. Third, an administrator restores the backup, at which point the unanchored regular expression matches the stored text and places it in an UPDATE query. Fourth, the query sets users_can_register to 1 and default_role to administrator, and the attacker registers an account that receives administrator rights automatically. The first step needs only a low-privilege account, while the third needs a normal administrative action.
Researcher Credit and Exploitation Status
A researcher using the handle “daroo” found the flaw and earned a bounty of $1,352. There is no public proof-of-concept and no confirmed exploitation. Backuply’s install base of more than 600,000 sites sets the potential scale of exposure for sites that have not updated.
Fixing Backuply and Checking Existing Backups
The patched release is available now, and the remediation advice extends past the update itself.
The fix is Backuply version 1.5.9. Beyond updating, the guidance is to audit user profiles and to confirm that the default registration role is restricted before restoring older backups.
That second step addresses a part of the problem that the update alone does not. A backup created while a vulnerable version was installed may already hold a subscriber’s stored payload. Because the injection triggers at restore time, the question for administrators with old backups is whether the restore code that processes them is the patched version and whether any profile contains unexpected content.
Why the Backup Feature Became the Attack Path
The vulnerability turns a recovery tool into the means of privilege escalation. The attacker never needs to bypass authentication or reach the database directly. The attack depends on the plugin treating profile text as safe when it writes the data into a backup and again when it reads it back, with the unanchored regular expression allowing the stored text to match and flow into the query.
Wordfence’s report places the vulnerability in the narrow gap between two ordinary operations, saving a profile and restoring a backup. Neither action looks suspicious on its own, and the plugin’s 600,000 installations mean that a large number of sites run the affected code in versions up to 1.5.8. Sites on 1.5.9 no longer process the stored text in the vulnerable way.
