Your Backup Plugin Is a Security Risk, Not a Safety Net

The plugin you installed to keep your website safe is now one of the most likely reasons it gets hacked. I was working through our threat feeds this week when the latest advisory landed, and it is the cleanest example I have seen in a while of a problem I keep warning people about. You bolt a tool onto WordPress to protect yourself. The tool becomes the hole in the wall.

This is not a freak event. It is a predictable consequence of where people put their backups. So before you read another guide telling you which backup plugin to install, let me make the unpopular case: for a site that matters, a backup plugin is a liability you are choosing to run.

The Tool Meant to Save You Became the Way In

On 11 June 2026, the security firm Wordfence disclosed a critical authentication bypass in UpdraftPlus, the most widely installed WordPress backup and migration plugin. It is tracked as CVE-2026-10795. It affects every version up to and including 1.26.4, and it is fixed in 1.26.5. More than three million sites run this plugin.

The mechanics are worth understanding, because they explain the lesson. The flaw let an unauthenticated attacker forge commands and run them as the connected administrator. In practice that means someone who has never logged in, never knew your password, and was never invited could deploy a malicious plugin straight into your production environment and take full control. Wordfence reported blocking over 8,000 attacks aimed at this single flaw in the first 24 hours after disclosure. By the time most owners read the headline, the bots had already been knocking for a day.

Now sit with what that does to a real business. Picture this. A solicitor's firm in Sligo runs a tidy WordPress site with a contact form and a few service pages. Someone sensible installed a backup plugin years ago and nobody has touched it since. By the time anyone notices clients are being redirected to a malware page, the attacker has held administrator access for days, and the only backup in existence is the one that vulnerable plugin took, sitting in a folder the attacker can reach too. The safety net and the site went down together.

A Backup That Lives Inside the Thing It Is Backing Up

Here is the part nobody selling you a plugin wants to dwell on. A backup plugin runs inside WordPress. It runs with WordPress's privileges. It is exposed through WordPress's public request handling. So it shares the fate of the exact thing it is meant to rescue.

That is the whole problem in one sentence. When your backup tool is just another plugin, every weakness in that tool becomes a weakness in your live site, and a compromise of your live site often reaches the backups as well. You have not added a safety net. You have added attack surface and called it protection. Plugins are already the soft underbelly of WordPress, and they have been used as a deliberate delivery route for attacks at scale before, which is exactly why piling more privileged code into that layer is the wrong instinct.

So what does a backup that actually protects you look like? Strip away the branding and it has three properties. It runs outside the application it protects, so a compromise of the website cannot reach it. It stores its copies somewhere the live site itself cannot read or overwrite, so ransomware and forged requests cannot touch the archive. And it is verified, not assumed, because a backup you have never restored is a guess wearing a badge.

This is the model behind server-level nightly snapshots that run on the hosting platform itself, beneath WordPress rather than inside it. When the backups and security are handled at the infrastructure layer, there is no public plugin endpoint for an attacker to probe, no admin-level code to hijack, and no archive sitting in a web-reachable folder. The job is simply taken out of WordPress's hands. That is not a feature you bolt on. It is a property of where the work happens.

Verify, Or You Do Not Have a Backup

I learned this one the hard way, so I will pass it on cheaply. Early in my career I trusted a backup routine that reported success every night for months. The night we actually needed it, the archives were effectively empty. We changed one rule after that and never broke it: every backup gets a test restore on a schedule, because an unrestored backup is a story you tell yourself, not a system you can rely on.

That habit matters whoever runs your backups. A green tick is a claim. A successful restore into a staging environment is proof. If you cannot remember the last time anyone actually restored your site from its backup, you do not currently have a backup you can count on. You have a hope.

When a Backup Plugin Is Genuinely the Right Call

I am not here to pretend backup plugins have no place. If you are running a single low-stakes personal site on a host that offers no backups at all, a well-maintained plugin, kept patched the day updates land, is genuinely better than nothing. For a hobby blog with no customer data and no revenue attached to it, the convenience can reasonably outweigh the risk. That is an honest trade, and plenty of people should keep making it.

Be clear-eyed about the limits of any backup, though, plugin or platform. A nightly snapshot is only as good as its last run. Make two hundred changes after the backup and get hit at 11pm, and you lose the day. That is the deal with point-in-time backups, and anyone who tells you otherwise is selling. The alternative, no backup at all, means losing everything, so know the tradeoff and act accordingly.

One more caveat worth stating, because it is the reason plugins end up doing this job in the first place. Server-level backups are only a given where your hosting actually provides and manages them. Plenty of cheap shared plans quietly leave the whole thing to you, which is precisely how a backup plugin ends up running a task it was never architected to run safely.

The Decision Worth Making on Purpose

The lesson from CVE-2026-10795 is not that you should uninstall everything and panic. If you run UpdraftPlus, update it to 1.26.5 today, then check your logs. The deeper question is the one that outlasts this particular flaw, and it will not be the last of its kind.

Should the job of protecting your site really be running inside the site itself? Once you see backups as an architecture decision rather than a plugin you install and forget, the answer gets clearer. The safest backup is the one an attacker cannot reach by sending a web request, and where that backup runs is worth deciding deliberately rather than by default. If you want the fuller picture of how backups and security actually fit together on a WordPress site, that is a good next thing to get straight.

Sources