The core security version fixed over twenty issues in one go, where did the rollback patch stop on which branch?
The WordPress core security version has fixed more than twenty vulnerabilities, where did the rollback patch stop, what should be done for older sites? This round of repairs stopped at 4.7.39, older branches than 4.6 cannot get any patches, and can only rely on the site itself to deal with it. The judgment order is: first confirm the口径 and branch coverage, then see if the automatic update has taken effect, and finally arrange for isolation or migration for older versions that cannot get patches.
More than twenty are what criteria are counted
The publicly counted criteria is this round of repairs covering twenty-two vulnerabilities distributed in seventeen announcements, that is, the two criteria of 'vulnerability entry number' and 'announcement number'. A single announcement may contain multiple similar issues. When citing such numbers, it is necessary to specify which criteria are used, otherwise, the numbers from different sources may seem contradictory.
For operations, the difference in criteria does not affect the actions: whether it is by entry or by announcement, the handling is the same - confirming the version, confirming the branch, confirming whether manual intervention is needed.
Why does the rollback patch have a lower limit
WordPress' support policy only maintains a few active branches, this round of rollback covers from the current main line to 4.7.39, spanning many version series; while sites before 4.6 are not on any active branch, the official does not provide patches. The constraint behind this is the maintenance cost: the code structure of old branches is greatly different, and each round of repair requires additional manpower, and the project would rather push users to new versions using the support cycle.
| The location of the site | What can be obtained | Suggested action |
|---|---|---|
| The current main version | Routine fixes and security patches | Enable background automatic updates and check permissions after upgrade |
| Old versions of active branches | Rollback patches on the same day | Confirm patch version number, schedule window upgrade |
| Below branch lower limit | No patches available | Isolate entry first, then plan to migrate to the new branch |
| Sites in disabled status | No patches available | Close public write surface or go offline directly |
Do three things first for sites still on the old branch
The first step is to narrow down the exposed surface: limit paths that can be written, such as login entries, registration forms, and file uploads first, turn off what can be turned off. The second step is to investigate existing intrusion traces, focusing on executable files, modified templates and plugins in unconventional directories, as well as suddenly appearing administrator accounts. The third step is to upgrade or migrate: if there are no patches in the old branch, it means that the next announcement is still unrelated to you, and staying on an unpatched branch for a long time is not an acceptable operation and maintenance status.
These three steps cannot be reversed: first back up the data before making any changes, otherwise, if misjudged, the recovery options will also be lost. The backup must cover data and static files, and a real recovery must be performed to pass the acceptance.
To what step does the automatic update cover?
Support branch sites that can depend on background updates to obtain this round of patches. Sites that have not enabled background updates need to arrange their own windows. Automatic updates can cover the core patch layer, but plugins and themes often still require manual confirmation, especially in scenarios where compatibility issues are a concern in the production environment.The processing logic of self-built systems is the same: AnQiCMS has fixed two high-risk issues, list sorting parameter injection and login credentials of site switching can be forged at the same time in v3.6.6. The suggestion of this upgrade announcement is to rotate the site signature configuration and change the administrator password after the upgrade, and invalidate the old credentials that may have been taken away at one time.
Upgrade acceptance list for self-built sites
- Before the upgrade, make a recoverable backup and confirm that the backup files can be read;
- After the upgrade, check whether the background login, roles, and write permissions are consistent with those before the upgrade;
- Check the static address and site map, and confirm that there are no large-scale 404 errors in the historical links;
- Check whether the sorting and filtering parameters on the list page return as expected;
- Rotate the configuration of key classes and the administrator password to avoid using old values;
- Record this handling in the operation and maintenance records, including the public announcement tone and the actual impact area.
Common questions
Is it okay to only fix the plugin and not the core?This round of issues is at the core level, plugin updates cannot replace core patches, and vice versa.
How to judge if the automatic update fails?Check if the version number has changed, and whether the background still prompts for an update. In case of failure, prefer to rollback rather than retry repeatedly.
What should be done if the old version site really cannot be upgraded?Isolate the site from public access, retain only necessary pages, and arrange for content migration at the same time, so that it does not continue to expose the write entry.