Backups are supposed to protect your website. But what happens when restoring one creates an opportunity for attackers to take control?
That’s the unexpected security concern raised by a recently discovered vulnerability in Backuply, a popular WordPress backup and migration plugin used on more than 600,000 websites.
The issue reveals something many website owners overlook: keeping backups is important, but ensuring those backups can be restored securely is just as critical.
Let’s explore what happened, why it matters, and what WordPress website owners and developers can learn from it.
The Hidden Risk Inside a Routine Website Backup
Most WordPress website owners consider backups their last line of defence.
Whether it’s a failed plugin update, an accidental deletion, or a server issue, restoring a backup is often the quickest way to get a website running again.
However, a security flaw discovered in Backuply demonstrated that the restoration process itself could introduce a serious vulnerability.
The issue, identified as CVE-2026-93953, affected Backuply versions 1.5.8 and earlier.
It received a high-severity CVSS score of 8.0 because it could allow someone with basic WordPress account access to eventually gain full administrative control of a website.
The surprising part?
The attacker wouldn’t necessarily need to exploit the website immediately. Instead, malicious information could remain stored in the database until a future backup restoration triggered it.
How Could a Simple User Profile Become Dangerous?
WordPress allows registered users to update certain profile information, including their biography.
Normally, this is harmless content displayed on author pages or stored in the website database.
In the affected Backuply versions, however, an attacker could place specially crafted malicious data into this field.
When the website created a backup, the data was included in the database export.
The problem appeared later, during restoration.
A flaw in the plugin’s SQL processing could cause part of that stored information to be interpreted as a database command rather than ordinary profile data.
This is known as a second-order SQL injection.
Unlike a traditional SQL injection, where malicious input is processed immediately, a second-order attack involves storing dangerous input that becomes active during a later operation.
<text highlight=”blue”>The key lesson: Information stored in your database should never automatically be considered safe when another process reads or executes it.</text>
Why Administrator Access Was at Risk
The vulnerability could be used to change two important WordPress settings:
- Default user role: Changing the role assigned to newly registered users from Subscriber to Administrator.
- User registration: Enabling public account registration even if the website owner had previously disabled it.
Once those settings were changed, an attacker could create a new account and potentially receive administrator privileges automatically.
That level of access could allow unauthorized changes to website files, plugins, content, users, and security settings.
There was, however, an important condition: an administrator had to restore a database backup containing the attacker’s malicious profile data.
Simply installing Backuply or creating a backup did not automatically trigger the exploit.
This distinction matters because it explains both the seriousness of the vulnerability and the circumstances required for exploitation.
A Security Fix Is Available
The vulnerability was reported through the Wordfence Bug Bounty Program in September 2026.
Following disclosure, the Backuply developers released version 1.5.9 on October 1, 2026, addressing the security issue.
Wordfence also introduced firewall protection for its paid security products on September 24, with protection for free users scheduled for October 24.
While firewall protection provides another security layer, updating the affected plugin remains the most important step.
Website owners should ensure they are running version 1.5.9 or a newer patched release.
Five Security Checks Every WordPress Website Owner Should Make
The Backuply incident is an opportunity to review your overall WordPress security practices, not just one plugin.
1. Don’t Treat Backups as Automatically Trustworthy
A backup preserves your website’s data at a particular point in time. If that data contains malicious content, restoring it may reintroduce the problem.
Maintain multiple backup versions and use a controlled environment to test restorations when appropriate.
2. Check Who Can Register on Your Website
Not every WordPress website needs public user registration.
Review your settings under Settings → General and confirm that new accounts receive only the permissions they actually need.
For most public-registration websites, Subscriber is a safer default than any administrative role.
3. Keep Plugins Updated, Even When Everything Works
A plugin can function perfectly from a user’s perspective while still containing a security vulnerability.
Regular updates should be part of website maintenance, alongside compatibility checks and testing.
4. Review Your Administrator Accounts
Periodically inspect your WordPress user list.
Confirm that every administrator account belongs to an authorized person and remove unnecessary elevated permissions.
5. Make Security Part of Your Maintenance Routine
WordPress security is not a one-time setup.
It requires ongoing plugin reviews, activity monitoring, access control, secure backups, and a clear process for responding to newly disclosed vulnerabilities.
What This Means for WordPress Developers
For developers, this incident highlights a broader issue with database handling.
Even when user input is safely stored, it can become dangerous if a later operation uses that information to construct SQL queries without appropriate validation and preparation.
Importers, migration tools, backup restoration systems, and custom database utilities all deserve careful security testing.
The same principle applies to custom WordPress development: every point where stored data is processed must maintain a clear boundary between data and executable instructions.
It’s not enough to secure a form when information is first submitted. Developers also need to consider how that information will be used throughout the application’s lifecycle.
The Bigger Lesson: Recovery Tools Need Security Too
Website security discussions often focus on login protection, malware scanning, and outdated plugins.
Those measures are important, but this incident shows why recovery systems should also receive attention.
A reliable WordPress security strategy should protect not only the live website but also the processes used to back it up, migrate it, and restore it.
A backup is valuable only when you can trust the recovery process.
Final Thoughts
The Backuply vulnerability serves as a useful reminder that security risks aren’t always visible during normal website operation.
Sometimes, the problem appears only when an otherwise routine administrative action takes place.
For website owners using Backuply, the immediate priority is simple: check your installed version and update to a patched release.
For everyone else, the takeaway is broader. Review your backup procedures, keep your WordPress environment updated, and regularly verify who has access to your website.
At IIH Global, we help businesses maintain, improve, and secure WordPress websites through proactive maintenance, plugin management, technical troubleshooting, and ongoing development support.
Your backup plan should be part of your security strategy, not a hidden security risk.
Want to Learn More About This Vulnerability?
For a deeper technical analysis of the Backuply security vulnerability (CVE-2026-93953), including the discovery process, affected versions, and security patch details, read the original Wordfence security report.
Credit: Wordfence Threat Intelligence Team and security researcher daroo for identifying and responsibly disclosing this vulnerability.
