A Backuply SQL injection vulnerability has exposed an uncomfortable weakness in a routine WordPress recovery task. A user with only subscriber-level access could place malicious text in their profile, then rely on a later database restore to execute it. In the reported scenario, that could ultimately give an attacker administrator access.
The flaw is tracked as CVE-2026-93953 and affects Backuply versions up to and including 1.5.8. Developer Softaculous released version 1.5.9 on 1 October 2026; Wordfence published its technical analysis on 15 October. The risk is serious, although exploitation depends on a particular sequence of events, not simply visiting a vulnerable website.
What is known about CVE-2026-93953?
Backuply is a WordPress plugin for backing up, restoring, cloning and migrating websites. The WordPress.org directory listed more than 600,000 active installations when checked on 18 October 2026. That is a measure of the plugin’s reach, not a count of sites running vulnerable versions.
Wordfence rates this issue 8.0 (High) under CVSS v3.1. Its researcher received the report on 17 September, the finding was disclosed to the developer on 28 September, and the patch followed on 1 October. The WordPress.org changelog independently confirms that 1.5.9 contains a security correction in the restore process credited to the Wordfence researcher.
The public analysis does not establish that the flaw is being widely exploited in live attacks. It describes a validated attack path that site owners should close before a restore operation makes stored hostile content dangerous.
How the Backuply SQL injection works
This is a second-order SQL injection. The attacker-controlled text is initially saved as ordinary profile data. It becomes executable only when a separate operation mishandles that data later.
According to Wordfence, a subscriber can edit their own Biographical Info field. Backuply includes that value when exporting the WordPress database into a backup. During a vulnerable restore, the plugin attempts to identify the original table prefix from SQL statements. A parsing expression can interpret text inside the stored biography as part of that prefix and then use it unsafely in a further database query.
The described outcome is a change to two WordPress settings: enabling public user registration and making administrator the default role for new accounts. An attacker who subsequently registers can gain administrative privileges. The research explains this as a database-manipulation route; it should not be described as an automatic remote takeover upon installation.
Most importantly, an administrator must restore an affected backup after the hostile profile text has been saved. Without that restore step, the injected text does not trigger the behaviour described in the advisory.
Why WordPress backup security matters
Backups are usually treated as trusted recovery material. Yet an archive may contain ordinary site data supplied by customers, members or other low-privilege accounts. A restore process must therefore handle database contents safely rather than assume every archived value is harmless.
This distinction matters for membership sites, shops with customer accounts and businesses that migrate websites between hosts. A backup created before an incident is often safer than one created after suspicious activity, but its date alone cannot prove that the data is clean.
Our earlier article about the Bricksforge WordPress vulnerability explored a different plugin weakness. Together, the cases show why applying a patch and assessing possible earlier compromise are separate tasks.
Backuply 1.5.9 fix: what administrators should do
Confirm whether Backuply is installed
Open Plugins in each WordPress dashboard and search for Backuply, including on staging, development and archived sites. Do not confuse the WordPress core version with the version of a backup plugin. Sites without Backuply are not affected by this particular flaw.
Update before another database restore
If an installation is running 1.5.8 or earlier, install Backuply 1.5.9 or a later verified patched release before initiating another restoration. Check that the update actually completed. The developer’s changelog identifies the restoration security fix; there is no need to remove functioning backups merely because the plugin was once outdated.
Review restoration history and site settings
Where a database was restored using an affected version, review available restore logs and administrator activity. In Settings > General, check whether anyone can register and verify that the default role for newly registered users is appropriate for the site. Examine the user list for unfamiliar administrators and investigate unexplained permission changes.
These are defensive checks, not evidence that compromise occurred. Unexpected values can have legitimate explanations, so compare them with the site’s documented configuration before drawing conclusions.
Treat older archives carefully
If you suspect an archive contains attacker-controlled data, preserve the evidence and assess it before putting it back into production. Use an isolated test environment and a patched restoration tool where practicable. A plugin update addresses the vulnerable restore code, but it cannot undo an administrator account or configuration change introduced by an earlier compromised restore.
Keep a known-good off-site copy and test recovery procedures. A working backup is useful only when its restoration process is trustworthy and the resulting site has been checked.
Limits, attack conditions and competing assessments
Wordfence said it supplied a firewall rule to its paid protection tiers on 24 September, with the corresponding free-tier rule scheduled for 24 October. Those dates concern Wordfence protection, not the Backuply patch: version 1.5.9 was already available on 1 October. A firewall is not a substitute for updating restore code or reviewing compromised data.
There is also a genuine disagreement about practical severity. In a comment published beneath the Wordfence report on 16 October, a person identifying themselves as representing the Backuply team argued that the 8.0 score overstates the likelihood of exploitation, because an attacker cannot reliably know when an administrator will restore a backup. That is a narrower argument about probability, not a denial that a correction was shipped.
The two perspectives can coexist: a conditional attack may be relatively difficult to time, yet the consequences of a successful privileged restore can be substantial. Site owners should assess their own account-registration model, restoration frequency and ability to identify unauthorised changes.
Critical analysis
The instructive part of CVE-2026-93953 is where the trust boundary fails. Backup creation stores a user’s profile text; a later restoration process interprets that text in a context where it can influence SQL. Administrators who focus only on external requests may miss risks already present in their saved data.
The vendor’s point about the unusual restore prerequisite is important. Calling this a zero-click takeover would exaggerate the evidence. Equally, dismissing the issue because a restore is not guaranteed would overlook the role of backups during precisely the outages and migrations when administrators are working under pressure.
For a small business, the sensible priority is manageable: verify the plugin version, update, check restoration history and retain tested recovery copies. The stronger long-term lesson is to make security checks part of disaster recovery, rather than treating a successful restore message as the end of the process.
Sources
- Wordfence — 600,000 WordPress Sites Affected by SQL Injection Vulnerability in Backuply WordPress Plugin, 15 October 2026; includes the developer’s 16 October response.
- WordPress.org — Backuply plugin listing and developer changelog, version 1.5.9 release notes dated 1 October 2026; checked 18 October 2026.
- OpenCVE — CVE-2026-93953 record, record updated 16 October 2026.
Leave a Reply