One of my sites went down at 3:01pm. At that point I knew nothing about a wider Updraft incident. I was just trying to get the site back online and work out what had happened.
My site threw a fatal error
I received an email from WordPress’s built-in fatal-error detector, saying that a plugin or theme had caused the problem and named a plugin called Style Bridge.
I SSH’d into the production server, found the plugin in the plugins directory, zipped it up for evidence, and removed the folder. The site came back online immediately. Searching for Style Bridge produced almost nothing useful apart from a site using the same name. I have no evidence that site is related to the plugin, so I am not treating it as evidence.
A few hours of log analysis showed that the site had started returning 500 errors at about 2:41pm. The Nginx logs supplied the clue: a call to class-udrpc.php. Searching that filename pointed towards Updraft’s remote-control path. The Updraft logs then showed the plugin upload.
There was no corresponding WordPress activity-log entry, and no Apache or Nginx record showing a conventional plugin upload or activation. That absence does not prove the exact mechanism, but it explains why the incident was easy to miss if I had only looked for a dashboard login.
The UpdraftCentral connection and key had been enrolled automatically during plugin activation and were easy to overlook. The activation flow included an opt-out checkbox, but I had not audited the resulting connection. I removed the Central link and key as soon as the evidence pointed there.
Only after finishing that investigation did I find the Reddit post and TeamUpdraft’s incident report. That order matters: this is not a theory I started with because I had read a security announcement. It is where my own logs led me.
The Reddit post matched my logs
The Reddit report describes a suspicious plugin called Image Core, an attempted privileged user, and requests using class-udrpc.php. The fatal error may have stopped the reported user creation.
The post’s screenshots show requests carrying a WordPress/Updraft-related user agent. That demonstrates that the requests existed. It does not, by itself, prove who sent them or confirm that every similar report came from the same campaign. Other commenters described unfamiliar plugins on their sites, but those remain community reports rather than verified incident findings.
TeamUpdraft’s report showed the wider incident
After finding the cause on my own site, I read TeamUpdraft’s security incident report. TeamUpdraft says attackers accessed teamupdraft.com over the weekend of 17–18 October 2026.
The company says customer information may have been accessed, including contact details, order history, hashed passwords, two-factor authentication settings, and connection keys for UpdraftCentral, UpdraftVault, and UpdraftClone. It says payment details were not stored. TeamUpdraft also says the UpdraftPlus plugin and downloads, customer-owned backups, and self-hosted UpdraftCentral installations were not affected. Those are the company’s statements, rather than an independently published forensic conclusion.
The report did not prove every detail of my incident, but it made the matching class-udrpc.php request and the Updraft log entry considerably harder to dismiss as coincidence.
A valid remote command looks less suspicious than a login
This is the uncomfortable part. A normal WordPress investigation looks for an unknown administrator login, a changed password, or a plugin uploaded through the dashboard. A trusted remote connection can use an expected endpoint and a format the site already recognises.
That means the absence of an obvious wp-admin login does not prove that no administrative action occurred. It also means dashboard two-factor authentication may not protect a connection that was already authorised by a stolen or exposed key. That is an inference from the reported evidence, not a confirmed explanation for every affected site.
Revoke the channel before cleaning the site
The useful response is to remove trust, not just delete the suspicious plugin. TeamUpdraft recommends that affected users:
- Change the TeamUpdraft password, especially if it was reused elsewhere.
- Reset two-factor authentication and watch for phishing messages.
- Delete the UpdraftCentral connection key under UpdraftPlus → Advanced Tools → UpdraftCentral.
- Check users, plugins, and must-use plugins for unexpected changes.
- Change administrator passwords and rotate salts, application passwords, and API keys.
- Restore a backup from before 17 October if the site looks compromised.
Backups are still one of the best ways out of a compromised WordPress site. The lesson is that a backup connection is also an administrative channel. Its keys deserve the same treatment as passwords: inventory them, revoke them when necessary, and monitor what they can do.
My earlier note on hardening WordPress covers some of the surrounding controls, including stronger authentication, access restrictions, and recovery planning.
My site was the starting point, not an afterthought. The plugin, the logs, the Reddit report, and TeamUpdraft’s later incident report now point in the same direction. That is enough to revoke the connection and treat the site as compromised, while still being honest about what the evidence cannot prove.