TeamUpdraft released UpdraftPlus 1.26.13 and 2.26.13 in response to the compromised UpdraftCentral connection keys. The update disconnects connections made before 13:07 BST on 18 October, blocking that credential path for sites that apply it.
Updating is necessary. It is not a complete incident response.
What the update changes
The vendor says the update automatically disconnects every UpdraftCentral connection made before the incident boundary. It also released new handling for UpdraftVault and UpdraftClone credentials. The site should verify the installed version and the actual key state rather than assuming that an automatic update has completed.
The update does not erase an account or plugin that was created before the key was revoked. TeamUpdraft's advisory asks users to check for suspicious activity, including unexpected plugins and new administrators. Patchstack warns that the backdoor account may appear as an Editor and can survive removal of the plugin.
That is why the change record needs to include more than a version number:
UpdraftPlus version.
Presence or absence of an UpdraftCentral key.
Unknown users and effective capabilities.
Plugin and must-use plugin inventory.
UpdraftCentral command log review.
Web access log review around the incident window.
Do not mistake a closed channel for a clean site
Patchstack's analysis describes a remote command that installed a malicious plugin. The command was encrypted and signed with a valid key, so ordinary signature checks passed. The site's own code did not have to be vulnerable. The update removes the ability to use the old key, but the resulting persistence may remain.
If an account was created, it may still work. If a plugin was installed, it may still execute. If a backup or storage credential was exposed, changing the UpdraftPlus release does not rotate that credential. The vendor advises users who accessed a site through UpdraftCentral to reauthorize remote storage and change storage access keys as a precaution.
The correct status is "channel revoked, investigation ongoing" until the site evidence supports a clean conclusion.
Find the estate before closing the ticket
External inventory helps teams find WordPress properties that may be missing from the approved change list. The reviewed ZoomEye query was:
http.body="/wp-content/plugins/updraftplus/"
It returned 140 public matches on 29 October 2026. This is a public path count, not a list of sites with UpdraftCentral keys. It can expose an unmanaged WordPress estate or a site that needs an owner check. It cannot confirm that an update was applied or that a key was revoked.
Use the query result as an inventory lead. Verify the installed version and remote management state on the site through authorized access. Record the query time and visibility limits in the change record so the evidence is not mistaken for a complete estate scan.
Prioritize the sites that matter
An update can be applied everywhere, but not every site needs the same depth of review. Prioritize sites with:
an old UpdraftCentral key;
a key created from a shared account;
unexplained Editor or administrator users;
plugin changes during the incident window;
customer, payment, authentication, or regulated data;
a backup storage credential that may have been exposed.
Those sites deserve evidence preservation, key revocation, account review, file review, and a deliberate reconnect. A low-risk site with no evidence of key use still needs a recorded owner decision. The decision should be based on observations, not on the fact that the plugin is popular.
Reconnect with a new trust model
After the investigation, create a new connection only when the site owner can name the purpose, the controlling account, and the allowed capabilities. Prefer an account without plugin installation if routine management does not need it. Set a review date and monitor the UpdraftCentral event log.
The key is a new authorization, not a restoration of the old one. The site owner should verify that the old key is gone and that the new key has a narrower scope. Reconnecting immediately after a version update, before checking the account and plugin state, can move the operation from remediation straight back into a trust relationship without evidence.
The patch is a boundary, not a conclusion
The vendor's revocation boundary is valuable because it stops old keys from being used. It gives organizations a clear point to assess what happened before the boundary and what must still be verified after it.
The response owner should treat patching, key revocation, account review, file review, and backup credential rotation as separate controls. When all five are complete, the site has a defensible recovery record. A single green check mark for the plugin version is not that record.