Can the automatic update replace manual upgrade for the WordPress core vulnerability fixed in 7.0.2?
WordPress core vulnerability is in 7.0.2, can automatic update replace manual upgrade? The answer is to cover the version, not the conclusion.The announcement from the third-party security vendor indicates that the core vulnerability with the identifier CVE-2026-63030 affects versions 6.9.0 to 6.9.4, 7.0.0 to 7.0.1, can be triggered without authentication, has a CVSS score of 7.5, and the fixed versions are 6.9.5 and 7.0.2. The announcement was released on July 17, 2026.The auto-update feature indeed allows the core version to reach the fixed version, but it cannot help you judge whether the site is still normal or has been exploited after the upgrade.
What level does the automatic update actually cover?
The design goal of automatic updates is to deliver the core patches, and it does not take responsibility for three things:
First, compatibility with plugins and themes. When the core version jumps to one level, whether the extension layer can still work is not verified by the automatic update, nor is it rolled back. Second, custom templates and shortcodes. For sites that have changed themes, changes in the behavior of template tags can only be manually traced back. Third, debugging abnormal traces. The scheduled tasks, admin accounts, and scripts in the upload directory left by vulnerabilities exploited after use will not disappear due to version upgrades.
Considering automatic updates as a 'security strategy' is essentially confusing 'version correctness' with 'site security'.
| Hierarchy | Whether to cover automatic update | Still need manual action |
|---|---|---|
| Core program file | override | Confirm the actual running minor version number |
| Plugins and themes | Do not cover | Check compatibility and source one by one |
| Custom template | Do not cover | Critical page regression verification |
| Intrusion traces | Do not cover | Account, task, upload directory investigation |
What must be done before the upgrade?
The order is wrong, and the upgrade will become a new fault. At least three things must be in place before execution: recoverable backups, verifiable recovery paths, and rollback version plans. The backup must cover both the database and uploaded files, and the recovery result of only the backup is usually 'The article is there, but the attachments are empty.'
AnQiCMS to incorporate this into the backend capability: backup and restore support for handling data along with static files, create a usable backup point before upgrading or patching, and then perform version replacement. It also has versions mainly focused on security fixes, such as v3.6.6, which fixed two high-risk issues of list sorting parameter injection and the login credentials of site switching being forgeable, and clearly required in the upgrade prompt to rotate the signature configurations of each site and change all administrator passwords - the patch only closes the entrance, while credential rotation clears the obtained sessions, and these two steps are also valid in the WordPress scenario.
How do you confirm that you are really safe after the upgrade?
Three criteria, none can be missing:
First, the version criterion. The visible version information and the version number displayed in the background should fall on the fixed version, not 'Already updated' as has been done. Second, the behavior criterion. Core process regression: login, publication, comments, form submission, site map generation. Any exception indicates that the compatibility layer has a problem. Third, the trace criterion. Check the login logs during the upgrade window to see if there are unfamiliar accounts, abnormal IP segments, or scheduled tasks that have been changed. If there are any, they should be handled according to the intrusion response plan and cannot be completed simply by updating to the fixed version.
Common questions
Ask: Is it more dangerous to turn off automatic updates?Answer: The risk is greater. The public disclosure of the core patch means the disclosure of exploitation conditions, and turning off automatic updates only extends the window. What needs to be done is to add backup and verification to the automatic update, not to turn it off.
Ask: If the hosting platform has already enabled automatic updates, do you still need to check yourself?Answer: Yes. The platform can ensure the core version, plugin source, and site anomaly traces still belong to the site operator, and the platform usually will not investigate for you.
Ask: How to arrange the upgrade sequence for a multi-site matrix?Answer: First verify compatibility in the test instance, then arrange the production sequence according to 'sites that can be accessed without authorization first', leave time for log review between each batch, and do not do it all at once.