A broken update. A host move that’s gone sideways. That’s usually when you reach for a backup restore – when you’re already stressed and just want the site back.
This week, two WordPress backup plugins fixed bugs that could make the restore itself run SQL planted by someone else. The data might have been sitting in the backup all along, looking harmless. Then you restore it, and the trouble starts. If you use UpdraftPlus or Backuply, update before your next restore, not halfway through an emergency.
The UpdraftPlus security update: two related fixes
UpdraftPlus released version 1.26.9 on 14 Oct 2026. It addressed a nasty situation: if a non-admin attacker could put content of their choice into a database cell larger than 1MB, and the owner later backed up and restored the site, the attacker’s SQL could run during that restore. Wordfence reported the issue to the developers.
That’s a fairly specific set of conditions. It doesn’t mean visiting a page runs the attack, or that every backup is poisoned.
Then came 1.26.10 on 15 Oct 2026. Jakub Herman reported a second, related instance. That one would execute only if the restore happened on a database server configured differently from the server where the backup was made – a host move is the obvious example. The developers say all users should update anyway. I agree. You don’t want to inspect database server settings while trying to rescue a shop.
Update, 18 Oct: UpdraftPlus 1.26.11 came out on 16 Oct 2026. It closes a gap in the 1.26.9 fix that only shows up when the database server runs in a rare SQL mode called NO_BACKSLASH_ESCAPES. Your site almost certainly doesn’t use it, but go to 1.26.11 or newer anyway.
If you use the paid edition, check for the matching 2.x release rather than looking for the free plugin’s version number.
Backuply: a profile bio that turns into an admin account
Backuply has a different path to the same awful moment. Versions up to and including 1.5.8 were affected; 1.5.9, released on 1 Oct 2026, fixed the flaw. It’s tracked as CVE-2026-93953, rated 8.0 (high). Wordfence published details on 15 Oct 2026, crediting researcher daroo.
Here’s the plain-English version. A logged-in user with only Subscriber access can put crafted text in their profile’s Biographical Info field. WordPress stores that in wp_usermeta, and Backuply copies it into the backup’s SQL dump. Later, an administrator restores that backup. The crafted text escapes its proper place and runs SQL with full database privileges.
Wordfence demonstrated a particularly direct result: switch on open registration, set the default role for new users to Administrator, then register a new account. That’s an admin account the attacker controls. Those settings stick after the restore because the site’s options are restored before the user metadata. Nobody has to click anything. The restore is enough.
Should you panic?
No reports of mass exploitation. And this isn’t an attack that fires just because someone signs up: the owner has to restore a backup containing the planted data.
Still, that delay makes it easy to overlook. Shops with customer accounts, membership sites, forums and sites accepting open registration or comments have more opportunities for stranger-supplied content to get into a backup. A host move can add the particular conditions needed for the second UpdraftPlus issue.
We’ve covered this pattern before in the attack that waits for a restore involving All-in-One WP Migration. The uncomfortable bit is the timing: the attacker plants something now and waits for you to need your backup.
What to do before your next restore
Open your WordPress plugins screen today. Don’t leave this as a note for the next time the site breaks.
- Check versions first. Update UpdraftPlus to 1.26.11 or newer, or Backuply to 1.5.9 before restoring anything. Premium UpdraftPlus users should check the matching 2.x release.
- If you can’t update yet, pause the restore. Don’t treat an older backup as safe simply because you made it yourself. Get help with the update before you import it.
- Consider what went into the backup. If suspicious accounts appeared, a backup from before they registered may be a better starting point. It isn’t a guarantee – strangers may have submitted other content too.
- Use staging when possible. Test the restore away from the live site, with the backup plugin updated first. Check the restored settings and users before using it as your live site.
Wordfence says its Premium, Care and Response firewall users have had a Backuply rule since 24 Sep 2026; free users get that rule on 24 Oct 2026. Useful protection, but a firewall rule isn’t a substitute for updating the plugin.
Does updating clean my site if it was already hit?
No. Updating stops this from happening on future restores; it doesn’t undo changes made by a vulnerable restore that already happened. If you’ve restored a Backuply backup while running an affected version, have a look now. Don’t assume a working homepage means the settings are fine.
In WordPress, go to Settings > General. Check Anyone can register (the users_can_register option) and New User Default Role (the default_role option). Registration should be off unless you need it; the default role should be Subscriber, or Customer for a shop that uses customer accounts. Administrator is not a normal default for public sign-ups.
Next, filter the Users list by Administrator. Do you recognise every account? Check recently registered accounts as well, and look through user bios for odd SQL-looking text. You don’t need to decode it yourself. Unexpected settings or an unknown admin are enough reason to stop and investigate.
If something’s off, treat the site as hacked. Change passwords, investigate accounts and database changes, and get help with hacked site cleaning. Don’t just flip registration back off and call it fixed. An attacker may already have an administrator account.
Make every restore end with a three-minute check
Even after you’ve updated, make a quick inspection part of restoring a backup: check Anyone can register, check New User Default Role, then scan the Administrator list. Do it befor you tell everyone the site is back. It’s a small habit that catches a very big surprise.
And test more than whether the homepage loads. A backup file is only part of the job; a backup is not a recovery plan. Your plan should say who updates plugins, where a restore gets tested and which settings get checked afterward.
Put the update on today’s list
This is exactly the sort of task a WordPress maintenance plan should handle quietly, before you’re staring at a broken site. If you manage the site yourself, open the plugins screen now and confirm the installed version. A restore emergency is a terrible time to discover your backup plugin missed an update.