It may also be possible to insert code during the background upgrade process, and these risk sites need to check which section first.
During the background upgrade process, it may also **insert code. This kind of risk needs to be clarified first is the upgrade window itself: from the start of the update package download to the time when the files are written to the site directory and the cache is rebuilt.WordPress released a security version 7.1.4 on October 28, 2026, and listed a weakness in the WordPress upgrade process that could lead to remote code execution during the upgrade window, and directly suggested that the site update immediately.Most teams treat upgrades as a pure operation and maintenance action, focusing on whether there are any issues with the new version, while ignoring the fact that the site itself is in a semi-open state during the writing process.
The risk is in which part of the upgrade
There are three vulnerable positions in the upgrade window. The first is the download channel: where the update package is taken from, whether there is an integrity check, and if the package path is hijacked, it means that all subsequent writes are based on malicious content.The second is the writing stage: In order for the new version of the file to overwrite the old file, the program often needs to temporarily release the directory write permission, and the site is in this state to accept requests, there is an opportunity to write the content into the executable location.The third is a short period before taking effect: the database structure has been changed, and the template and cache are still old. At this time, the front-end may report errors or behave abnormally, which is easy to lead operations personnel to temporarily relax permissions or turn off checks in a hurry, and the risk is introduced here.
Prepare an escape route before the upgrade
The first thing is to back up and make sure it is backed up according to recoverable standards. AnQiCMS's backup and restore cover databases and static files, generate a backup with a timestamp before the upgrade, and confirm that this backup can be restored in the new environment, which is more important than whether the backup exists. The second thing is to close the mouth: only accept access from necessary sources within the window period, pause unrelated scheduled tasks and external collection, and reduce concurrent writes. The third thing is to write down the upgrade steps, including what to verify after each step, to avoid operating by feel.
The two types of entries that need to be held back during the upgrade.
One type is a background entry, do not open it to multiple users at the same time during the upgrade period, the administrator password should be updated according to the official recommendation, and the site signature key should be rotated according to the upgrade instructions. The other type is a front-end writing entry, it is recommended to pause or add verification to interfaces such as comments, messages, and form interfaces during the window period, and collect writable positions to the minimum set. The purpose of doing this is not to prevent the upgrade from failing, but to make the event of 'writing abnormal content to the upgrade window' a low probability event, and it can be traced back in terms of time after the event occurs.
The repair history of the content management system also supports this kind of processing: AnQiCMS's v3.6.6 fixed the SQL injection brought by the list sorting parameters, as well as the two chains that can be forged when switching sites, which all belong to the type of 'can be tested by front-end parameters' and not defects that can be triggered by background accounts.The core side protection is layered, with JWT authentication at the interface layer, sensitive word filtering and anti-capturing interference code at the content side, and input constraints against SQL injection and XSS at the rendering layer;The extension component and the upgrade window are not on this chain, and this is the reason why they need to be covered separately during troubleshooting.
What to check after the upgrade
Perform four tasks in order. First, compare file integrity: take the directory list before and after the upgrade and focus on the newly added or modified files in the writable directories and template directories. Then check the permissions: withdraw the temporary relaxed directory permissions during the window period and confirm that write permissions are only on the attachment and cache directories. Third, check the running traces: review the access logs, check for abnormal request paths or sources during the upgrade period, and whether there is direct access to newly created directories. Finally, check the functionality: go through the login, list pagination, column page and article page, search, and attachment upload to confirm that there are no silent failures.
Common questions
Is automatic update safer than manual upgrade?
It is not certain. Automatic updates reduce procrastination, but entrusting the download and write process to unattended time points, where no one is watching in the window. A feasible compromise is automatic reminders, manual execution, or at least scheduling automatic updates during low-traffic periods and leaving logs.
Without a file integrity baseline, how can we compare after the event?
Restore a clean copy from the backup as a baseline and compare it with the current directory. This is also one of the reasons why backups need to include static files: if only the database export is included, it is impossible to compare templates and attachments.
When a suspicious file is found, should we delete it first or investigate it first?
First collect evidence and then deal with it. Keep the files with timestamps, export access logs for the corresponding period, confirm where the write path comes from, and then decide to delete and redo. Deleting directly will make it impossible to find out the cause of the failure, and the same problem will occur during the next upgrade window.