UpdraftPlus shipped three security releases in three days last week. The 14th, the 15th and the 16th. If you went to the vendor's own changelog page to find out what was in them, you found nothing, because that page's newest entry is version 1.26.6 from July 23. Five releases and nearly three months behind what WordPress.org is actually serving.
That would be worth a short post on its own. What makes it worth a longer one is what a security firm published this morning about the same plugin, and the thing that story says about every vendor with a key into your site.
Where this comes from. The WordPress.org plugin listing, the vendor's own documentation and changelog, and the NVD record for the June flaw, all read directly. The incident below comes from one researcher's published report on three of its own sites. We say so every time we refer to it, and we have not been able to corroborate it independently.
Start With the Part Nobody Disputes
UpdraftPlus reports more than four million active installations. In the nonprofit and association sector it is close to default furniture, because backups are usually the one security control that actually got implemented.
Three releases in three days. Versions 1.26.9, 1.26.10 and 1.26.11 landed on October 14, 15 and 16. Three in three days is the pattern you see when something is being chased rather than planned.
And the vendor's own changelog stops in July. The plugin's update screen and the vendor's website currently disagree about which versions exist. If your maintenance process is to read the changelog before approving an update, which is a sensible process, your process has been reading stale information since July. We have written about the update your theme needs not being offered to you. This is the same failure from the other direction: the update is offered, and the explanation is missing.
There was a real flaw in June. CVE-2026-10795, scored 8.1 by Wordfence as the assigning authority, affected every version up to and including 1.26.4 and was fixed in 1.26.5. NVD describes the root cause as insufficient validation of the remote communications message format. Hold onto the phrase remote communications, because that is the actual subject of this post.
Your Backup Plugin Has a Remote Control Channel
UpdraftCentral is a dashboard for running many WordPress sites from one screen: update plugins, trigger backups, install software, across an estate. Agencies use it. So do some associations with chapter sites.
The half that matters is already installed. The dashboard is its own plugin. The managed-site half is not. It lives inside UpdraftPlus, and the vendor's own setup documentation routes you to Settings, Advanced Tools, UpdraftCentral Remote Control, where you generate a key and copy it into the dashboard. No second plugin gets installed on the site being managed.
It is not on by default. It is off until somebody turns it on. A connection exists only after an administrator generates that key. Which means this is not something that happened to your website. It is something a person at your organization chose, possibly four years ago, possibly a contractor you no longer work with, and almost certainly without writing it down anywhere.
And here is the part worth writing down. The key carries the permissions of the account that created it. A key generated by an administrator can install plugins. A key generated by an account without that right cannot. Nobody makes that choice deliberately, because nobody is told it is a choice. The person setting up remote management is logged in as an administrator, so the key is an administrator key, and that is the end of the thought.
What Was Reported This Morning
One security firm, three websites it owns, published on October 19. The vendor had not responded publicly when this was written later that day, and it had had hours rather than weeks, so read that as a timestamp rather than an indictment.
The claim. Commands arrived at three sites correctly signed with valid dashboard keys. The sites were fully patched, running WordPress 7.1.3 and the current plugin release, and the researcher reports the plugin files matched the official release byte for byte. It checked and ruled out the June flaw, a modified plugin, a substituted key and a compromised administrator session.
What was used. The command was the ordinary one for installing a plugin. Not an exploit, not a crafted request, the documented instruction that a remote-management dashboard sends a hundred times a day.
And the detail that generalizes. On one of the three sites it failed. That key had been generated by a user without permission to install plugins, so the command arrived, authenticated correctly, and could not do anything. One configuration choice, made without any security intent, was the difference between a compromised site and a log entry.
What is not known. The researcher states plainly that it does not know how the attacker obtained valid signing keys. That is the central unanswered question and it is the reason to treat the whole account as provisional. Three sites, one owner, one researcher, no independent telemetry, and a vendor that has not had time to answer. We are reporting a report. If it does not hold up, we will say so here.
The Question This Should Change
The useful question is not whether you are patched. The sites in that report were patched, on the current release, with no modified files.
The question is this one. Which vendors can reach into your website right now, at what privilege level, and would anybody notice if somebody else used that door. Most associations have never written that list down, and it is longer than it feels: the remote-management agent, the security plugin that phones home, the managed-service provider's tooling, the backup service, the page builder doing a license check, the uptime monitor with an API key, the agency that built the site three redesigns ago and never had its access revoked.
This is the ownership problem again. We have made this argument before in a different register, about the fact that nobody at most associations owns the website platform itself. This is the same gap with a sharper edge. Access that nobody owns is access that nobody reviews, and the review is the entire control.
What to Actually Do This Week
- Open Settings, Advanced Tools, and look. Not because of this report. Because you probably cannot currently say whether a remote-management key exists on your site or who made it.
- If a key exists and nobody can account for it, revoke it. Removing a site from a dashboard does not delete the key stored on the site. The key is the thing that grants access, so the key is the thing to remove.
- If you genuinely need the channel, scope it. Generate it under an account that cannot install plugins. On the evidence in that report, this one choice is what separated the site that was compromised from the one that was not.
- Point WordPress fatal error emails at a human. In the reported case that is the only reason anybody noticed anything at all. A fatal error notice going to an unmonitored mailbox is a detection system you are paying for and not using.
- Update to 1.26.11. And do not use the vendor's website to decide whether to update. Use the changelog on the WordPress.org listing, which is current, until the vendor's own page catches up.
The Post We Would Have Written Wrong
We have told associations to patch promptly more times than we can count, and we were right every time. Patching would not have helped here. Neither would a web application firewall, because the traffic was correctly signed and authorized.
An inventory of who holds a key into your website, at what permission level, is a different control from patching. It is not on anybody's maintenance checklist. It does not have a plugin. It is a spreadsheet and an afternoon, and it is the thing this story actually argues for.