On September 17th, 2026, we received a submission for a Second-Order SQL Injection vulnerability in Backuply, a WordPress plugin with more than 600,000 active installations. This vulnerability makes it possible for authenticated attackers with subscriber-level access and above to store a malicious SQL payload that is executed when an administrator later restores a database backup, ultimately allowing the attacker to escalate their privileges to administrator and take over the site.
Props to daroo who discovered and responsibly reported this vulnerability through the Wordfence Bug Bounty Program. This researcher earned a bounty of $1,352.00 for this discovery. Our mission is to secure WordPress through defense in depth, which is why we are investing in quality vulnerability research and collaborating with researchers of this caliber through our Bug Bounty Program. We are committed to making the WordPress ecosystem more secure through the detection and prevention of vulnerabilities, which is a critical element to the multi-layered approach to security.
Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against known exploits targeting this vulnerability in Backuply, hosted on WordPress.org, on September 24, 2026. Sites using the free version of Wordfence will receive the same protection 30 days later on October 24, 2026.
We disclosed this vulnerability to the Backuply team on September 28, 2026, and the developer released the fully patched version on October 1, 2026. We would like to commend the Backuply team for their prompt response and timely patch.
We urge users to update their sites to the latest patched version of Backuply, version 1.5.9 at the time of this publication, as soon as possible.
Vulnerability Summary from Wordfence Intelligence
Technical Analysis
Backuply is a popular WordPress plugin for creating backups and restoring, migrating, and cloning sites. When creating a database backup, it exports each table’s rows into an SQL dump, and when restoring, it executes each statement from that dump to rebuild the database.
This vulnerability is a second-order SQL injection, meaning the malicious input is stored during one action and only becomes dangerous when it is processed later during a different action.
The malicious input is planted through the Biographical Info field, which any user with an account can set on their own profile. WordPress stores this value as plain text in the wp_usermeta table.
When a database backup is created, Backuply exports the stored biography as a normal quoted value inside an INSERT statement in the SQL dump, correctly escaping it as data. The flaw appears during the restore process. The importer executes each complete statement from the dump, and then applies an unanchored regular expression to that same statement in order to discover the site’s old table prefix. Because the expression is not limited to a real CREATE TABLE header and does not skip quoted values, it also matches text inside the stored biography. When the statement additionally contains the string backuply_version, the captured text is concatenated into a second UPDATE query without any validation:
$res = backuply_mysql_query($sql, $conn);
// Find Prefix in create tables
if(preg_match('/CREATEs+TABLEs+[.]*[`]*(.*)options[`]*s*(/is', $sql, $prefix)){
if(!empty($prefix[1])){
$wp_old_prefix = $prefix[1];
}
}
// If backuply_version found, then execute
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);
}
Because the captured value is placed directly into the UPDATE statement as if it were a trusted table prefix, an attacker can craft their biography so that the captured text is not a prefix at all, but a complete UPDATE statement of their choosing. By ending the captured portion with a comment character, the plugin’s own trailing SQL is discarded, and only the attacker’s statement is executed.
The injected statement targets two rows in the wp_options table, default_role and users_can_register, setting default_role to administrator and users_can_register to 1. Because wp_options is restored before wp_usermeta, these changes are already in place by the time the injected query runs and persist after the restore completes.
The significance of these two options is what turns a database write into a full site takeover. When users_can_register is enabled, WordPress exposes the public registration form, and when a new user is created without an explicit role, WordPress assigns them the value stored in default_role.
After an administrator restores a backup that contains the malicious value, public registration is enabled and the default role for new accounts is set to administrator. The attacker can then simply register a new account through the standard WordPress registration form, and that account is automatically granted the administrator role, giving the attacker complete control of the site.
As with all privilege escalation vulnerabilities, this can lead to complete site compromise.
Important Note
We would like to draw attention to the fact that this vulnerability requires an administrator to restore a database backup that was created after the attacker’s malicious biography value was stored. This restore is the action that causes the injected SQL to execute. Since creating and restoring backups is the core purpose of this plugin, this is a routine action, but the injected SQL will not execute until a restore takes place.
Disclosure Timeline
Vendor / external action
Conclusion
In this blog post, we detailed a Second-Order SQL Injection vulnerability within the Backuply plugin affecting all versions up to, and including, 1.5.8. This vulnerability allows authenticated threat actors with subscriber-level access and above to store a malicious SQL payload that executes when an administrator restores a database backup, enabling them to enable public registration, set the default role to administrator, and register a new administrator account, leading to complete site compromise.
We encourage WordPress users to verify that their sites are updated to the latest patched version of Backuply as soon as possible considering the critical nature of this vulnerability.
Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against known exploits targeting this vulnerability in Backuply, hosted on WordPress.org, on September 24, 2026. Sites using the free version of Wordfence will receive the same protection 30 days later on October 24, 2026.
If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk.
The post 600,000 WordPress Sites Affected by SQL Injection Vulnerability in Backuply WordPress Plugin appeared first on Wordfence.