- Wordfence reports a Backuply flaw (versions up to 1.5.8) where a subscriber's profile text can run as SQL when an administrator restores a backup.
- It matters because the trigger is a routine restore, and it can end in an attacker-created administrator account.
- Update to Backuply 1.5.9 or later; free Wordfence users do not get the firewall rule until October 24.
A backup is a script, not a photograph
We tend to think of a backup as a frozen copy of a site. It is safer to think of it as a script the site will run on itself. If someone can write a line into that script, the site will carry it out when the backup is restored.
Wordfence's October 15 report on Backuply shows why. Wordfence says the plugin, which handles backups, restores, migrations and clones for WordPress, is active on more than 600,000 sites. An account with subscriber-level access, the lowest tier that can log in, can plant text that does nothing until an administrator restores a backup. It runs only when that administrator does the one thing the plugin exists for.
What Wordfence found
A researcher using the handle daroo reported the flaw through the Wordfence Bug Bounty Program on September 17, 2026, and earned $1,352. Wordfence calls it a second-order SQL injection. In plain terms, the attacker leaves harmful text in one place, and a different action later sets it off.
Versions 1.5.8 and earlier are affected. Any user with an account can set the Biographical Info field on their own profile. WordPress stores that text in the wp_usermeta table. That is where the attacker plants the payload.
How a bio becomes a command
Making the backup is not the problem. Backuply writes the biography into the SQL dump as a properly escaped, quoted value. In that form it is treated as data.
The trouble starts at restore time. Backuply reads each statement in the dump and uses a text-matching pattern to find the site's old table prefix. Wordfence traces the problem to that search being too broad. It can match anywhere in a statement, including inside a user's quoted biography.
When the statement also contains the string backuply_version, the matched text is pasted into a second UPDATE query with no validation. An attacker can write a biography whose "prefix" is really a full UPDATE statement. A comment character at the end cancels the plugin's own trailing code.
The attacker's command changes two settings in the wp_options table. The first, default_role, decides which role new accounts receive, and the attacker sets it to administrator. The second, users_can_register, is set to 1, which opens the public sign-up form. Wordfence notes that wp_options is restored before wp_usermeta, so the changes are already in place and persist afterward.
The attacker then registers a new account through the normal public form. WordPress gives it the default role, which is now administrator. Wordfence describes the result as complete site compromise.
Why this one is easy to miss
Wordfence stresses a limit. The attack needs an administrator to restore a backup made after the malicious biography was stored. Nothing runs until that restore happens.
That limit is also what makes the flaw hard to spot. Restoring a backup is a routine, trusted action. The administrator does nothing unusual, and the attacker's code runs with the administrator's authority.
The lesson here is that trust in a backup tool extends to everything inside the backup. This is our own inference, not Wordfence's finding. Wordfence describes one field, and a specific condition. Still, user-editable fields such as this one can become places where an untrusted person writes into a file that a trusted person will later execute.
The timeline leaves a gap
Wordfence sent the report to the Backuply team on September 28. The developer released version 1.5.9 on October 1, and Wordfence commended the response.
Firewall protection arrived on different dates. Wordfence Premium, Care and Response users got a rule on September 24. Free-version users get the same rule on October 24, 30 days later.
For a site on the free tier, the plugin update is the fix Wordfence points to before October 24. Treat the update as the control, not the firewall rule.
Questions to put to your team
Start with inventory. Which of our sites run Backuply, and are they on 1.5.9 or later? Who owns that answer for sites run by agencies or contractors?
Then ask about exposure. Which of those sites let outsiders hold accounts, such as customers, members or commenters? Those accounts are the entry point the report describes.
Finally, ask about evidence. After any recent restore, do default_role and users_can_register hold their intended values? Are there administrator accounts nobody can explain? These checks are our suggestion, not steps from Wordfence.
Wordfence does not say whether a backup taken before the update is safe to restore afterward. Ask your vendor or host before relying on one.
A backup you cannot trust is not a recovery plan. Ask how your team knows what is inside the file before it restores it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wordfence.
