Backuply up to 1.5.8 – Subscriber+ Second-Order SQL Injection (CVE-2026-93953)

Backuply versions through 1.5.8 contain a second-order SQL injection vulnerability that can let a subscriber escalate to administrator after a database backup is restored. CVE-2026-93953 has a CVSS score of 8.0 and affects a plugin with more than 600,000 active installations. Version 1.5.9 contains the fix.

Vulnerability summary

• Product: Backuply – Backup, Restore, Migrate and Clone
• Plugin slug: backuply
• Affected versions: 1.5.8 and earlier
• Fixed version: 1.5.9
• CVE: CVE-2026-93953
• Severity: High, CVSS 8.0
• Privilege required: Subscriber or higher
• User interaction: An administrator must restore a backup created after the attacker stores the malicious profile value
• Impact: Arbitrary database writes, administrator privilege escalation, and site takeover

How the second-order injection works

The attacker stores crafted data in their WordPress Biographical Info profile field. Backuply later includes that value in an SQL backup. During restoration, vulnerable prefix-detection logic can interpret text inside the stored value as trusted SQL context and concatenate it into a new database query without adequate validation or preparation.

The injected data does not execute when the profile is edited or when the backup is created. It executes only when an administrator restores the affected database backup. Wordfence demonstrated that the database write can enable public registration and change the default role to administrator, allowing a newly registered account to take over the site.

Immediate remediation

1. Update Backuply to version 1.5.9 or later before creating or restoring another backup.
2. Do not restore database backups created with a vulnerable version until user profile data has been reviewed and the restore process is handled with the patched release.
3. Review subscriber and other low-privilege profiles for unexpected content in Biographical Info.
4. Verify that public registration is not unexpectedly enabled and that the default role is not Administrator.
5. Review recently created administrator accounts and logs around every Backuply restore. If suspicious changes followed a restore, treat the site as compromised and rotate credentials.

Safe verification

wp plugin get backuply --fields=name,status,version,update,update_version
wp option get users_can_register
wp option get default_role
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp core verify-checksums
wp plugin verify-checksums backuply

The expected default role on most sites is subscriber, and public registration should match the site’s intended configuration. A different value is not proof of exploitation, but an unexplained change after a restore requires investigation.

Indicators to review

• Unexpected markup or SQL-like fragments in user biography metadata
• users_can_register changing to enabled after a database restore
• default_role changing to administrator
• New administrator accounts created shortly after a Backuply restore
• Unrecognized restore activity, backup archives, or changes to registration settings

Sources

• Wordfence technical disclosure
• Wordfence Intelligence vulnerability record
• WordPress.org Backuply plugin page and 1.5.9 changelog
• CVE-2026-93953 record