Backuply SQL Flaw Puts 600,000 Sites at Risk: Fix It Now

If you run a WordPress site and use Backuply to protect it, there is something you need to know: the very plugin responsible for keeping your site safe was, until very recently, carrying a vulnerability that could let an attacker take over your entire website. Security researchers at Wordfence have disclosed a second-order SQL injection flaw in the Backuply plugin — tracked as CVE-2026-93953 with a CVSS score of 8.0 (High) — that puts more than 600,000 active WordPress installations at risk. A patch is available, but what makes this story unusual is not just the scale. It is the method: a low-privilege user plants a hidden payload, and the trap only springs when an administrator restores a backup.

In this guide, we will break down exactly what happened, why this type of attack is so dangerous, who is affected, and — most importantly — the concrete steps you can take right now to secure your site before your next restore operation.

What Happened: Backuply’s Second-Order SQL Injection, Explained

On October 15–16, 2026, the Wordfence Threat Intelligence team publicly disclosed a critical vulnerability in Backuply – Backup, Restore, Migrate and Clone, one of the most widely used WordPress backup plugins, with over 600,000 active installations. The vulnerability is a Second-Order SQL Injection, and it carries the identifier CVE-2026-93953 with a CVSS severity rating of 8.0, classified as High.

The flaw was discovered by an independent security researcher known as “daroo”, who submitted the finding through Wordfence’s Bug Bounty Program on September 17, 2026, earning a bounty of $1,352. After responsible disclosure to the vendor on September 28, a patched version — Backuply 1.5.9 — was released on October 1, 2026. Wordfence’s own firewall customers were protected early: premium users received a firewall rule on September 24, while free users receive protection starting October 24.

Here is what makes this vulnerability remarkable. A first-order SQL injection is the classic kind: an attacker submits malicious input, and the application executes it immediately. A second-order SQL injection, by contrast, is a delayed weapon. The attacker stores a malicious payload somewhere in the database, where it sits quietly and harmlessly — for days, weeks, or longer. Later, a different piece of code retrieves that stored data and uses it in a new database query without properly escaping it. Only then does the payload detonate. The attack in Backuply follows exactly this pattern, and it exploits one of the most routine, trust-filled actions a site owner can perform: restoring a backup.

Timeline of the Disclosure

Understanding the timeline helps you judge your own exposure. If you restored a backup between the introduction of the vulnerable code and the patch, the details below matter.

As of the disclosure, no confirmed cases of active exploitation have been observed in the wild, and the vulnerability’s EPSS score (a measure of real-world exploit probability) sits at a low 0.3%. That is encouraging — but it is not a reason to delay. Public disclosure means the technical details are now available to everyone, including attackers, and historically, plugin vulnerabilities with hundreds of thousands of installs attract exploit attempts within days of publication.

How the Attack Works: A Step-by-Step Breakdown

Second-order SQL injection is one of the harder vulnerability classes to grasp, so let us walk through exactly how this attack chain unfolds, in plain language.

Step 1: The attacker hides a payload in their profile

The attacker needs only a subscriber-level account — the lowest privilege role on a WordPress site, and one that is handed out freely on sites with open registration, membership plugins, or comment systems. The attacker edits their own WordPress user profile and types a carefully crafted, malicious SQL snippet into the “Biographical Info” field — the harmless-looking text box where users normally write a short bio.

At this stage, nothing bad happens. WordPress stores the biographical text in the wp_usermeta database table exactly as typed. The site continues working normally. No alarms, no errors.

Step 2: Backuply writes the payload into the backup, verbatim

When Backuply creates a backup, it exports the database as a SQL dump — essentially a large text file containing INSERT statements that describe every row of every table, including wp_usermeta. The plugin writes the attacker’s biographical text into that dump verbatim, exactly as stored. The poisoned backup is now sitting on your server (or in your cloud storage) looking perfectly legitimate.

Step 3: An administrator restores the backup — the trap springs

This is the “second order” moment. Restoring a backup is a routine, trusted operation — often performed during site migrations, after a bad update, or while moving between hosts. During the restore process, Backuply runs a regular expression (regex) over the stored user data to rewrite table prefixes (for example, changing wp_ to a custom prefix like mysite_). That regex gets tangled in the attacker’s stored payload, and the result is that the attacker’s SQL breaks out of its original INSERT statement and executes as a brand-new query — this time with the full database privileges of the restore process itself.

Step 4: The payload escalates to full site takeover

The executed payload does two devastating things. First, it sets WordPress’s default_role option to administrator. Second, it enables open user registration. From there, the attacker simply registers a new account on the site — and because the default role has been silently changed, that new account is created as a full administrator. The attacker now has complete control: they can install plugins, add backdoor users, exfiltrate the database, deface content, or use your server to attack others.

The elegance — and the danger — of this attack is its patience. The payload is stored long before it fires, and the detonation is triggered by the victim’s own administrator performing an everyday maintenance task. That is precisely why second-order vulnerabilities are so prized by attackers and so feared by defenders: the person who pulls the trigger is not the attacker.

Who Is Affected: Affected vs. Patched Versions

The scope of this vulnerability is large. Here is where you stand:

Any site running Backuply 1.5.8 or earlier is vulnerable. With 600,000+ active installations, this is one of the largest plugin vulnerability disclosures of the year. Note an important subtlety: even if you update to 1.5.9 today, backups created by the vulnerable versions may still contain the poisoned payload. Updating the plugin protects future backups, but a backup generated while you were running a vulnerable version — and restored by an administrator — remains a live threat. We will address that in the hardening steps below.

How to Secure Your Site Right Now

Do not wait for your next restore operation. Work through these steps in order.

Step 1: Update Backuply to 1.5.9 (or newer) — before your next restore

1. In your WordPress dashboard, go to Dashboard → Updates and check whether Backuply 1.5.9 (or a newer release) is available.
2. Alternatively, go to Plugins → Installed Plugins, find Backuply, and click Update now.
3. After updating, verify the version number shown under the plugin name reads 1.5.9 or higher.
4. Take a fresh backup with the patched plugin — this gives you a clean restore point generated by safe code.

This is the single most important action. The patch closes the hole; the fresh backup gives you something safe to restore from.

Step 2: Audit your users — especially subscriber-level accounts

Because this attack begins with a subscriber-level account planting a payload in the “Biographical Info” field, a user audit is essential:

1. Go to Users → All Users and review every account with the Subscriber role (or any custom low-privilege role).
2. Open suspicious profiles and inspect the Biographical Info field for anything that looks like code — SQL keywords such as INSERT, SELECT, UPDATE, quotes, semicolons, or table-prefix patterns are red flags.
3. Delete any accounts you do not recognize, especially ones created around the time of suspicious activity.
4. Check the administrator list carefully: look for accounts you did not create. An attacker who already succeeded will have left a rogue admin behind.
5. If your site allows open registration and does not need it, disable it at Settings → General → Membership (uncheck “Anyone can register”), and confirm the New User Default Role is set to Subscriber — not Administrator.

Step 3: Practice backup hygiene

1. Quarantine old backups: backups created by Backuply 1.5.8 or earlier could theoretically contain a stored payload. Do not restore from them unless you have verified they are clean.
2. Generate fresh backups with the patched 1.5.9 version and label them clearly as post-patch restore points.
3. Inspect before restoring: if you must restore from an older backup, consider scanning the SQL dump for suspicious content in the wp_usermeta INSERT statements first.
4. Keep an off-site copy of your most recent clean backup, so a compromised local backup never leaves you without options.

Step 4: Consider a web application firewall

Wordfence’s own firewall blocked this attack for its Premium users from September 24, 2026, with free-tier coverage arriving October 24. A reputable WordPress firewall adds a layer of defense-in-depth against the entire class of injection attacks, including future variants that have not been disclosed yet.

Why Second-Order Vulnerabilities Deserve Special Attention

It is worth pausing on why security teams treat second-order SQL injection as a particularly nasty category. Traditional input validation usually guards the front door: data is checked when it arrives. Second-order attacks exploit a blind spot — data that passed validation on arrival gets reused later in a completely different context, by different code, with different assumptions. The developers who wrote the profile-saving code and the developers who wrote the backup-restore code may never have considered that their two features would interact this way.

For site owners, the lesson is broader than Backuply: backups are trust boundaries. We treat backup files as inherently safe, but a backup is simply a snapshot of everything your site contained — including anything an attacker managed to store there. Verifying backups, generating them with patched software, and being cautious about restoring from untrusted sources are habits worth building regardless of which plugin you use.

Frequently Asked Questions

Is my site affected if I already updated to Backuply 1.5.9?

If you are running 1.5.9 or newer, the vulnerability itself is patched and new backups are generated safely. However, review your user accounts anyway: if an attacker planted a payload while you were on a vulnerable version, or if a rogue administrator account already exists, the patch alone does not remove that. Complete the user audit in Step 2 above.

Can this attack work without an administrator restoring a backup?

No — and that is the defining trait of this second-order flaw. The stored payload is inert until an administrator restores a backup created by a vulnerable version of the plugin. The restore operation is the trigger. This is why updating before your next restore is the critical action.

Has this vulnerability been exploited in the wild?

As of Wordfence’s disclosure, no confirmed active exploitation has been observed, and the EPSS score stands at just 0.3%. That said, the technical details are now public, and vulnerabilities in plugins with 600,000+ installations historically attract exploit attempts quickly after disclosure. Treat the absence of known exploitation as good news, not as a reason to postpone patching.

What does a CVSS score of 8.0 mean?

CVSS (Common Vulnerability Scoring System) rates vulnerabilities from 0 to 10. A score of 8.0 falls in the High severity band. It reflects that the flaw can lead to full site takeover (the worst confidentiality, integrity, and availability impact), tempered by the fact that exploitation requires a subscriber-level account and an administrator-triggered restore — which slightly reduces the score from the Critical range.

Should I switch away from Backuply?

Not necessarily. The vendor patched the flaw promptly — within two weeks of being notified — which is a good sign of responsible maintenance. Every backup plugin is software, and every piece of software can have bugs. What matters is the vendor’s response time, which was solid here. Keep the plugin updated, follow the hardening steps above, and you can continue using it with confidence.

The Bottom Line

The Backuply second-order SQL injection (CVE-2026-93953) is a textbook example of why WordPress security is never “set and forget.” A low-privilege account, a quiet payload in a profile field, and a routine restore operation — that is all it takes to hand an attacker the keys to your site. The good news: the fix is a single update away. Update Backuply to 1.5.9 before your next restore, audit your subscriber accounts, generate a fresh clean backup, and tighten your registration settings. Do those four things today, and this 600,000-site scare becomes a non-event for you.

Sources

• Wordfence Threat Intelligence — “600,000 WordPress Sites Affected by SQL Injection Vulnerability in Backuply WordPress Plugin” (October 2026): wordfence.com
• SecurityOnline.info — “Backuply WordPress Plugin SQL Injection Vulnerability” (October 2026): securityonline.info