Backuply SQL Injection (CVE-2026-93953): 600,000 WordPress Sites at Risk, Update to 1.5.9 Now

More than 600,000 WordPress sites have a ticking problem sitting in their plugin lists. A SQL injection flaw in Backuply, the backup, restore, migration and clone plugin, lets an attacker with nothing more than a subscriber account lay a trap that fires the next time an administrator restores a database backup. The result is full administrator access and complete site takeover.

The short answer: If your site runs Backuply version 1.5.8 or earlier, update to version 1.5.9 right now. Wordfence disclosed the vulnerability (CVE-2026-93953, CVSS 8.0) on October 16, 2026, and the developer shipped the fix on October 1. Then audit your user accounts and double-check your default registration role before you restore any older backup.

What happened

On October 16, 2026, security firm Wordfence published the details of a vulnerability found by researcher daroo through its Bug Bounty Program. The timeline:

• September 17, 2026 — daroo submits a second-order SQL injection report through the Wordfence Bug Bounty Program.
• September 19 — Wordfence validates the proof of concept.
• September 24 — Wordfence pushes a firewall rule to its Premium customers.
• September 28 — full disclosure details go to the Backuply team.
• October 1 — the developer releases the fully patched version, 1.5.9.
• October 16 — public disclosure.

The plugin has over 600,000 active installations, which puts this among the larger WordPress plugin vulnerabilities disclosed this month.

How the attack works

This is a second-order SQL injection, which means the malicious input does not do anything when the attacker first submits it. Instead, it sits quietly in the database until a later operation processes it in an unsafe way. In this case, that later operation is a database backup restore — the core job of the plugin.

Here is the sequence Wordfence describes:

1. An attacker with subscriber-level access or higher edits the Biographical Info field in their WordPress user profile and stores a crafted SQL payload in it.
2. Backuply exports that value verbatim into an INSERT statement in the SQL dump when it backs up the database (the wp_usermeta table).
3. When an administrator later restores that backup, Backuply uses a regular expression to detect the site’s old database table prefix. That expression is not limited to actual table creation statements — it can match text inside stored user data, including the attacker’s payload.
4. The plugin builds another SQL query from the captured text without enough validation, and the crafted payload breaks out of the INSERT statement and appends attacker-controlled SQL that runs with full database privileges.

Because the injection fires inside an INSERT during a restore and nothing comes back to the attacker, the payload cannot be used to read data directly. Instead it writes — the attacker uses it to change the default_role option in wp_options to administrator and enable open user registration. They then register a normal account through the standard WordPress registration form, and that account is automatically granted the administrator role. From there, complete site compromise is straightforward.

Which sites are affected

• Every site running Backuply 1.5.8 or earlier.
• Backuply 1.5.9, released October 1, 2026, is not affected.
• The attack needs an authenticated user with at least subscriber-level access, and it needs an administrator to restore a database backup created after the malicious profile value was saved.
• Sites that never accept user registrations or never restore backups face much less practical risk — but with 600,000 installs, a large number of membership sites, course sites, and multisite networks are squarely in the danger zone.

Wordfence stresses one important point: this is a validated vulnerability, not a confirmed exploitation campaign. No widespread attacks have been reported so far. The risk is potential, not yet observed in the wild — which makes now, before disclosure details spread, the best time to patch.

What to do right now

1. Update Backuply to version 1.5.9 through Plugins > Installed Plugins. This is the complete fix.
2. Audit your user accounts. Go to Users > All Users and look for accounts you do not recognize, especially recent subscriber registrations.
3. Check Settings > General. Confirm the default role for new users is still what you intended, and that membership registration is only enabled if you need it.
4. Before restoring any older backup, inspect it — a backup made while an attacker’s payload was sitting in a user profile could still contain it. Restoring it would re-arm the trap.
5. Wordfence users on the free tier get the firewall rule automatically on October 24 (Premium users already have it), but updating the plugin is the real fix and should not wait.

Backup plugins are high-value targets for exactly this reason: they touch every table in the database and run operations with high privileges. This is not the first time backup tooling has been the weak link — attackers recently turned vulnerable AhsayCBS backup servers into crypto miners, and incomplete AhsayCBS patches drew a CISA deadline this same month.

Why second-order SQL injection is so dangerous

First-order SQL injection is caught by testing inputs; second-order injection hides in data that is stored first and executed later. Security reviews tend to focus on forms and URLs, while the restore path — a trusted admin operation on trusted backup data — gets far less scrutiny. The lesson for site owners is simple: backups are not inert archives. Treat restored data with the same suspicion you would apply to live user input, and keep every plugin that touches your database updated.

WordPress plugin supply-chain attacks have been accelerating all year — the Bricksforge flaw (CVE-2026-85097) reached CVSS 10.0 with active exploitation — so a 600,000-install plugin with an 8.0 deserves immediate attention.

FAQ

Is my site hacked if I run Backuply 1.5.8?

Not necessarily. The vulnerability requires an attacker with an account on your site and a backup restore to fire. If you have no unexpected users and have not restored backups from untrusted periods, your exposure may be low. Update anyway, and audit your users.

Does the patch remove payloads already stored in my database?

No. Version 1.5.9 fixes the unsafe restore behavior going forward, but it does not scan your backups or database for malicious values planted earlier. Review user profiles and be cautious restoring backups created before the fix.

Can this be exploited without a user account?

No — the attacker needs at least subscriber-level authenticated access to plant the payload in the Biographical Info field. Sites with registration completely disabled are harder targets, but patching is still recommended.

Is there a workaround if I cannot update immediately?

Wordfence Premium’s firewall rule blocks this exploit. Free-tier users get the rule on October 24. The recommended path remains updating the plugin to 1.5.9 as soon as possible rather than relying on the firewall rule.

Who found this and was there a bounty?

Researcher daroo reported it through the Wordfence Bug Bounty Program and received a $1,352.00 bounty. Wordfence validated it within two days and the vendor shipped a fix within two weeks.