# 600,000 WordPress Sites Affected by SQL Injection Vulnerability in Backuply WordPress Plugin

Subscriber stores SQL payload in Biographical Info; Backuply's restore regex captures it as table prefix, injecting UPDATE to set default_role=administrator for site takeover.

- Payout: $1,352
- Severity: high
- Program: Backuply
- Found by (vendor credit): daroo
- Write-up by: István Márton
- Disclosed: 2026-10-15
- CVE: CVE-2026-93953
- Write-up quality: 7/10
- Original: https://www.wordfence.com/blog/2026/10/600000-wordpress-sites-affected-by-sql-injection-vulnerability-in-backuply-wordpress-plugin/
- Library page: https://bugbountylibrary.com/r/blog%3Awordfence-com-blog-2026-10-600000-wordpress-sites-affected-by-sql-injection-vulnerability-in-backuply-wordpress-plugin
- Tags: area:web domain:web impact:ato impact:privesc kind:research platform:research sev:high tech:php tech:wordpress technique:second-order technique:source-review vuln:privilege-escalation vuln:sqli

**Target:** WordPress plugin backup/restore SQL dump importer
**Root cause:** During restore, an unanchored regex extracts the table prefix from any statement containing 'options', matching text inside quoted biography values; the captured string is concatenated into an UPDATE query without validation.
**Steps:**
1. As subscriber, set Biographical Info to a payload that the prefix regex captures, e.g. text ending with `options` followed by `; UPDATE wp_options SET option_value='administrator' WHERE option_name='default_role'; UPDATE wp_options SET option_value='1' WHERE option_name='users_can_register'; -- `
2. Ensure the same usermeta INSERT statement also contains the string `backuply_version` so the second regex branch fires
3. Wait for admin to create a backup (payload exported verbatim into SQL dump) and restore it
4. Restore executes the INSERT, then the regex captures attacker text as prefix and runs the injected UPDATE
5. Register a new account via the now-enabled public registration form; it receives administrator role
**How found:** Researcher likely noticed the restore code applies an unanchored regex to whole statements to recover the table prefix and concatenates the capture into a query, then realized quoted usermeta values could satisfy the regex.
**Exploitation:** Attacker with subscriber account plants payload in profile biography; admin's routine backup+restore executes injected UPDATE setting default_role=administrator and users_can_register=1; attacker registers new admin account.
**Escalation:** DB write primitive converted to full site takeover by flipping default_role and users_can_register options, then self-registering as admin.
**Insight:** When a restore/import routine regex-scrapes schema info (like table prefix) from full SQL statements, check whether the regex is anchored to CREATE TABLE and skips quoted string literals; user-controlled data exported verbatim into dumps can hijack the capture.
