Wordfence published a write-up today (15 October) of CVE-2026-93953 in Backuply, the backup plugin with more than 600,000 active installs on wordpress.org. CVSS 8.0. Any logged-in user, down to a subscriber, can plant text that turns into SQL when an administrator later restores a backup. Versions up to and including 1.5.8 are affected; the author shipped 1.5.9 on 1 October.

Wordfence's write-up of CVE-2026-93953, published 15 October 2026: Backuply 1.5.8 and older affected, 1.5.9 patched

How it works, because the two-step part is what makes it odd. A subscriber puts a crafted string in the Biographical Info field of their own profile. WordPress stores it as plain text in wp_usermeta, and when Backuply makes a database backup it writes that bio into the dump as a correctly quoted value. Nothing is wrong yet. The flaw is in the restore: after running each statement from the dump, Backuply runs an unanchored regular expression over the same statement to find the old table prefix. That pattern is not limited to a real CREATE TABLE line and does not skip quoted values, so it also matches text inside the bio. If the statement also contains the string backuply_version, the captured text is pasted straight into an UPDATE query as if it were the prefix.

So the bio can carry a whole UPDATE statement of the attacker's choosing, ended with a comment marker so the plugin's own trailing SQL is thrown away. Wordfence's example sets default_role to administrator and users_can_register to 1 in wp_options. After the restore, the registration form is open and every new account is an administrator. The attacker registers one and owns the site.

Backuply's page on wordpress.org on 15 October 2026: 600,000+ active installations, current version 1.5.9

Some calibration on the 8.0. It needs an account on the site, so a site with open registration or a membership or shop setup is the exposed kind. It needs an administrator to restore a backup made after the bio was planted, and nothing runs until that restore happens. Restoring is the whole point of the plugin, so that is a routine action, but a site that only makes backups and never restores is not hit by it. Wordfence says nothing about exploitation in the wild in the write-up. The injection returns nothing to the attacker, so it can only change records, not read them, which is why the privilege escalation goes through those two options.

Timeline from Wordfence: reported 17 September, firewall rule for Premium, Care and Response users on 24 September, vendor told 28 September, patch 1 October, and free Wordfence users get the same rule on 24 October. The plugin's changelog for 1.5.9 says only "fixed a security issue in the restoration process", so the details are in the Wordfence post.

What I would do this week: update Backuply to 1.5.9 on every site that has it, including the ones you forgot about. If you restored a backup in the last few weeks on a site that lets people register, look at Settings, General, and check that "Anyone can register" and the New User Default Role are what you set. Check Users for administrators you did not create. And if you have not updated yet, hold off on restoring any backup that was made while subscribers could edit their profiles.

When you do restore on a site with user accounts, do you check anything first, or do you just trust your own backups?