CVE-2026-93953: Backuply Restore SQLi Turns a Subscriber Bio Into Admin - Floor 1.5.9

The Situation

Backuply is a Softaculous WordPress backup/restore/migrate plugin. The wordpress.org plugin API this morning returned version 1.5.9 and active_installs 600000 (the directory's 600k bucket, last updated 2026-10-01 1:48pm GMT, tested to 7.1.3).[5][4]

Wordfence published the operator write-up on 15 October 2026. Wordfence Intelligence lists CVE-2026-93953, CVSS 8.0 High, CWE-89, publicly published October 15, 2026, researcher daroo, bounty $1,352. Affected ≤ 1.5.8. Patched 1.5.9.[1][2]

Their claim, not ours: an authenticated subscriber or above writes a crafted Biographical Info value. Backuply dumps it as a quoted INSERT into wp_usermeta. When an administrator later restores that dump, an unanchored regex treats text inside the INSERT as a table prefix and concatenates it into an UPDATE. The payload they describe sets default_role to administrator and users_can_register to 1. The attacker then registers a new account and gets admin.[1][2]

The restore is a required second action. Wordfence says so. A planted bio does nothing until someone hits Restore on a dump taken after the plant.[1]

Vendor changelog (1.5.9, 1 October 2026): [Security Fix] Fixed an issue related to the restoration process, reported by daroo [Wordfence]. No CVE ID on that page.[3][4]

CISA KEV catalog 2026.10.15 (count 1746, dateReleased 2026-10-15T17:00:11.2795Z) does not list CVE-2026-93953. Newest dateAdded today is Atlassian CVE-2026-21589, not WordPress.[8]

NVD cves/2.0?cveId=CVE-2026-93953 this morning: totalResults: 0. We are not inventing an NVD score.[9]

What the bug actually is

Wordfence: Backuply exports biography verbatim inside an INSERT. Restore runs each statement, then runs this (their excerpt, also present in the 1.5.8 tag we pulled from wordpress.org SVN):[1][2]

if(preg_match('/CREATE\s+TABLE\s+[.]*[`]*(.*)options[`]*\s*\(/is', $sql, $prefix)){
    if(!empty($prefix[1])){
        $wp_old_prefix = $prefix[1];
    }
}
if(!empty($wp_old_prefix) && preg_match('/backuply_version/is', $sql)){
    $bacuply_version_query = "UPDATE ".$wp_old_prefix."options SET `option_value`='".$GLOBALS['backuply_version']."' WHERE `option_name`='backuply_version';";
    backuply_mysql_query($bacuply_version_query, $conn);
}

The first regex is not anchored to a real CREATE TABLE header and does not skip quoted values. Wordfence: if the statement also contains backuply_version, the captured text is glued into the UPDATE as if it were a trusted prefix. End the capture with a comment character and the plugin's trailing SQL is discarded.[1]

Wordfence Intelligence points at restore_ins.php in the 1.5.7 tag (#L2247, #L2255) plus changeset 3723257.[2][7] We re-read tags/1.5.8 and tags/1.5.9 from SVN this morning. 1.5.8 still has that unanchored CREATE TABLE regex. 1.5.9 changes it to:

• only match a statement that starts as CREATE TABLE (leading dump comments allowed);
• capture identifier characters only ([A-Za-z0-9_]+) before options;
• strip non version-like characters from $GLOBALS['backuply_version'] before interpolation.

That matches Wordfence's "the expression is not limited to a real CREATE TABLE header" diagnosis. We did not execute either file against a live database.[1]

Wordfence: wp_options is restored before wp_usermeta, so the option writes persist after restore completes. Primitive is a write, not a SELECT dump, because the injected query runs inside restore with no response to the attacker.[1]

WPSec disagrees on who can plant it

WPSec WPSEC-2026-0328 (published 2026-10-02, CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H) describes the same restore regex but says an unauthenticated visitor can plant via comment text, not only a subscriber bio. They write: "Also published later by Wordfence as CVE-2026-93953, on 2026-10-15." Their scanner note this morning: Plugin Low · Affected versions None seen among sites WPSec scans, 2026-10-15.[6]

We did not test comment vs biography. Treat Wordfence as the CNA-facing write-up (subscriber+ bio) and WPSec as a second reading (unauth comment). Same floor: 1.5.9. Same required admin restore.[1][6]

Hunt the fleet - plugin version, then options, then dumps

# one site
wp plugin get backuply --field=version --allow-root
wp plugin list --name=backuply --fields=name,status,version --allow-root

# floor
wp plugin update backuply --allow-root
# confirm
wp plugin get backuply --field=version --allow-root   # want 1.5.9 or later

# shared hosting: every account that has the slug
find /home /var/www -path '*/wp-content/plugins/backuply/backuply.php' 2>/dev/null
# or, if you already have a wp-cli loop:
# wp plugin get backuply --field=version

After the update, the plugin patch does not rewind a restore that already ran. Wordfence's takeover path is default_role + users_can_register. Check those even on patched sites if anyone restored a pre-1.5.9 dump that included untrusted bios/comments:[1]

wp option get default_role --allow-root          # should not be administrator
wp option get users_can_register --allow-root    # 0 unless you meant to open signup
wp user list --role=administrator --fields=ID,user_login,user_registered,user_email --allow-root

Do not restore an old 1.5.8-era dump onto a patched plugin and call it done - 1.5.9 fixes the importer. The dump still contains the planted row. Restore on 1.5.9 should no longer treat INSERT bodies as CREATE TABLE prefixes (that is what the 1.5.9 regex change is for). We did not prove a malicious dump is inert on 1.5.9; we read the new regex.[1]

Wordfence Premium/Care/Response got a WAF rule 24 September 2026. Free Wordfence gets the same rule 24 October 2026. A WAF rule is not a version bump and does not remove a planted bio or a rogue admin.[1]

Cannot patch immediately (mitigations, not a substitute):

• Do not Restore until wp plugin get backuply --field=version is 1.5.9+.
• Lock down users_can_register and default_role at the host level if you can.
• Subscriber signups on a Backuply site are in scope for Wordfence's plant path. Open comments are in scope for WPSec's.

Honesty / What We Could Not Verify

• We did not exploit this. No bio was planted. No dump was restored. No SQL was executed. Regex text is from SVN tags 1.5.8 / 1.5.9 and Wordfence's excerpt.
• NVD has no object. totalResults 0 for CVE-2026-93953 this morning. 8.0 is Wordfence Intelligence, not an NVD v3.1 score.[2][9]
• CVE.org JSON API 404'd for CVE-2026-93953 from this box. The CVE ID is taken from Wordfence Intelligence's CVE column (links to cve.org). WPSec also maps it. Until NVD/CVE JSON serve a record, treat the ID as Wordfence-assigned pending NVD.[2][6][9]
• Not on CISA KEV as of catalog 2026.10.15 / count 1746.[8]
• Not claimed in-the-wild. Wordfence's article does not report observed exploitation. WPSec's 15 Oct scan note says they saw no affected versions in their scanned set. Wordfence's "firewall rule to protect against known exploits" is their standard WAF sentence; we are not reading that as a campaign.[1][6]
• 600,000 is the wordpress.org API active_installs bucket this morning, not a census we ran. Wordfence uses the same "more than 600,000 active installations" figure.[1][5]
• Auth disagreement. Wordfence: subscriber+ biographical info. WPSec: unauthenticated comment text, PR:N. Unresolved here.[1][6]
• Vendor page names no CVE and no CVSS. Only "restoration process" + daroo/Wordfence.[3]
• Changeset 3723257 is cited by Wordfence; the trac HTML 404'd through our fetch. We used the tagged files instead.[2][7]
• Backuply Pro. wordpress.org slug is free backuply. We did not inventory a separate Pro package. Softaculous last_updated on the free slug is 1 Oct 2026.
• RCE ≠ this CVE. Wordfence describes option writes + a new registered admin, not a webshell. Do not upgrade it to unauth RCE.

What this is not

• Not CVE-2026-39919 (Ghostscript PDF thumbnail heap overflow). Different process, different package.
• Not CVE-2026-85097 (Bricksforge unauth PHP upload).
• Not CVE-2026-87902 (WordPress core page-template inclusion, already KEV).
• Not a cPanel / Plesk / LiteSpeed / Proxmox KEV. Today's new KEV row is Atlassian.
• Not "every Backuply restore is a takeover." Wordfence's own note: the SQL runs only when an admin restores a dump that already contains the plant.

Sources

[1] https://www.wordfence.com/blog/2026/10/600000-wordpress-sites-affected-by-sql-injection-vulnerability-in-backuply-wordpress-plugin - Wordfence Backuply SQLi blog 15 Oct 2026 [2] https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/backuply/backuply-158-authenticated-subscriber-second-order-sql-injection-via-restore-to-privilege-escalation - Wordfence Intelligence CVE-2026-93953 [3] https://backuply.com/blog/backuply-for-wordpress-v1-5-9-launched - Backuply v1.5.9 vendor changelog [4] https://plugins.svn.wordpress.org/backuply/trunk/readme.txt - Backuply wordpress.org readme.txt [5] https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request%5Bslug%5D=backuply - wordpress.org plugin API backuply [6] https://wpsec.com/vuln/WPSEC-2026-0328 - WPSec WPSEC-2026-0328 [7] https://plugins.trac.wordpress.org/changeset/3723257/backuply - Backuply SVN changeset 3723257 [8] https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CISA KEV JSON catalog 2026.10.15 [9] https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-93953 - NVD CVE-2026-93953 empty 2026-10-16