WordPress 7.1.3 brings seven security fixes in one go, what should the site do during the patch window period?
The patch window period refers to the time between the release of the security version announcement and the completion of the upgrade on the entire site - the vulnerability details have been publicly disclosed, and the fix has not yet been implemented. This period is when the attack surface is at its largest. WordPress released 7.1.3 on October 6, 2026, bringing seven security fixes and four defect fixes in one go, and the official recommendation is to update immediately. The correct sequence during the window is to back up first, then verify the affected areas, practice in the test environment, perform the formal upgrade, and then review after the fact, rather than clicking the update button as soon as the announcement is seen.
What does the patch window period refer to?
From the moment the security announcement was made public, the site faced pressure on both sides: one side was the existing exposed surface that had not been upgraded, and the other side was the compatibility issues caused by the hurried upgrade. Window period management is about finding the order between these two sides.
Most sites encounter problems during the window period, not because they missed the announcement, but because they had no fallback state after the upgrade failed. The absence of backups would turn a failed upgrade into a downtime incident, giving attackers more time.
Backup first or upgrade first?
First, back up and make sure the backup can be restored. There is no room for discussion on the order of this step: upgrading will change the program files and data structure, and the cost of errors is irreversible.
AnQiCMS supports data and static file backup and recovery, and the backup operation can be scheduled as a timed task. What really needs manual confirmation is the recovery capability: when was the last successful recovery exercise, and how long does the recovery take. Only backup without exercise, the day of failure will find that the backup file is incomplete.
After backup, it is necessary to check the impact scope. What subsystems are covered by the security fix, whether the corresponding functions are used on the sites, and how many sites need to be processed separately, these three things determine the batch division of the upgrade.
Why should we rehearse in the test environment once?
The performance of the same repair is not consistent on different sites, and the differences come from plugins, templates, and custom code. The role of the test environment is to expose these differences in advance.
The rehearsal should check three things: whether the upgrade process itself is completed, whether the front-end page renders normally, and whether the background login and key writing are normal. The third item is most likely to be skipped, and login authentication is exactly the part most frequently touched in security repair.
If the scale of the site group is large, you can first try to upgrade on a low-traffic site, treat it as a gray batch, and observe the round of crawling and access logs before pushing to the rest of the sites.
After the upgrade, which three places should be reviewed?
The first place is version confirmation. Check whether the actual running version is consistent with the announced version, and it is easy to occur in the cache and multi-node environment that the disk has been updated but the process is still running the old version.
The second aspect is authentication and authorization. Any security update is recommended to synchronize the rotation of signature keys and change the administrator password, to invalidate any credentials that may have been leaked during the vulnerability exploitation period. This is an action outside of the announcement, but with the highest benefits.
The third aspect is residual content. Check if the sensitive word filtering and content review rules are still effective, and confirm that there has been no reset or configuration rollback due to the upgrade.
Where is the difference in the Go stack site?
The same process is missing a few steps in a system implemented in Go language. AnQiCMS v3.6.6 was released on October 8, 2026, fixing two high-risk issues such as SQL injection in list sorting parameters and the possibility of forging login credentials during site switching. The upgrade recommendations also require rotating the Token signature key and changing the administrator account password.
Comparing plugin ecosystem sites, there are three differences. First, the application is a single binary, there is no problem with thousands of third-party extensions each bringing their own vulnerabilities, the attack surface is converged in the core and runtime; second, the built-in defense is within the application - JWT authentication, SQL injection and XSS protection, content sensitive word filtering and anti-crawling interference code all belong to the system自带, do not need to rely on external extensions to fill in the blanks; third, the memory usage is reduced by about 80% compared to PHP class CMS, the same machine can leave some space for test instances, and the exercise environment does not need to buy extra machines.
The manual process has not disappeared: version upgrades still require backup, still require verification of authorization, but do not need to check the compatibility status of third-party extensions individually.
Window period disposal order list
| Stage | Action | Completion criteria |
|---|---|---|
| Notice publication | Confirm the list of affected functions and sites | Know whether you are among them |
| First step | Complete backup and verify recoverability | There was a successful recovery drill recently |
| Second step | Test environment drill upgrade | Front-end rendering and back-end login are normal |
| Step 3 | Gray-scale site upgrade first | No access and fetch log exceptions |
| Step 4 | Full site upgrade | Running version consistent with announced version |
| After the event | Rotation of signature key and administrator password | All old credentials have expired |
Common questions
Can we just turn off the plugins and wait for the official fix?Can be used as a temporary relief, but the recovery time should be recorded. Long-term shutdown of features will change the behavior of the site, and it is easy to be forgotten after a few weeks.
Can automatic updates replace manual review?No. Automatic updates solve the problem of 'whether the patch has been applied', and the review solves the problem of 'whether it is normal after the patch has been applied'. The two cannot be merged into one step.
How to decide the order when there are many sites?Grade according to impact: deal with transactions first, content-based later; no more than half of the number of sites in the same batch, retain the space for rollback.