What order should be checked before upgrading the website when a planned-out-of-scope security version occurs in the running environment?
The running environment has encountered an unplanned security version, what order should be checked before the website upgrade? Follow these four steps: 'Backup and rollback → Verify affected versions → Test environment validation → Peak-shaving online observation'. An unplanned security version means that the problem is not within the regular release cycle, and the processing time limit given in the announcement is usually very tight, but it does not mean that it can be directly operated on the production site: first confirm that there is an available rollback point, and then judge whether your version falls within the affected range. These two steps are not completed before the upgrade, and the most common result is that faults and vulnerabilities coexist.
Why do we have to handle this on the same day?
The environment released a security version outside the regular cycle, Picus Security organized PHP2Shell very clearly: 'PHP shipped an out-of-cycle security release on October 21, 2026, for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which its security team rated CVSS v4.0 9.2 (Critical).' The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The reminder on the ecological side is also direct. The Drupal official wrote in the security alert on October 20, 2026,
| Inspection items | Judgment basis | The approach when it does not pass |
|---|---|---|
| Is the backup available | Can a recoverable accessible site be restored in an isolated environment | Rebackup and perform a recovery drill |
| Current version | Compare the affected version range in the announcement | Even if not in the range, upgrades can be scheduled later |
| Expansion and dependencies | Whether there are modules dependent on old interface behaviors | Verify each one in the test environment |
| Business regression items | Form, login, upload, payment callback | Fill in the test cases before going online |
| Observation window | Time periods with someone on duty after going online | Adjust the release time and execute again |
Three backups before upgrading
First is the database export, second is a complete site backup including static files, third is a clear rollback point: record the current version number, deployment method, and configuration file location to ensure that the entire system can be rolled back in case of problems. Sites that only back up the database will find that the theme and uploaded files do not match when rolling back.
AnQiCMS's backup and recovery support data along with static files, and can be restored with the same backup during rollback. Don't rush to upgrade after the backup is done, first sample confirm that the files are readable, the size is reasonable, and unverified backups are equivalent to none in emergency scenarios.
Check the environment version first before taking action
Check in two layers. For the runtime environment layer, use the version query command to confirm the current baseline and compare it item by item with the affected range in the announcement; for the site program layer, confirm the supported runtime environment range to avoid a mismatch between the program and the runtime after the upgrade.
Some sites are container deployed, the host has changed the version, but the container is still on the old baseline. In this case, it should be rebuilt at the image level, not just change the host. Also read the upgrade instructions of the content management system itself, especially the minimum requirements for the runtime environment version and changes in configuration items.
Gray release and regression checklist
Run the complete process in the test environment before going to production, regression test should at least cover: home page and list page rendering, article page and pictures, in-site search, comments and form submission, backend login and permissions, file upload, payment or order-related callbacks. For multi-site and multi-language sites, it is also necessary to additionally confirm whether the path and language jump after the site switch is normal.
Leave a period of observation with someone on duty after going online, focusing on error logs, abnormal requests, and sudden changes in traffic volume. The handling of out-of-plan security versions often involves temporary mitigation measures. If the announcement provides transition configuration options, they should be uniformly recovered after the upgrade to avoid temporary configurations remaining in the production environment for a long time.
AnQiCMS in v3.6.6 (2026-10-08) fixed two high-risk issues: list sorting parameter injection and the site switching login credentials being forgeable. The upgrade instructions also suggest rotating the site signature key and changing the administrator password - this is a typical example of 'finishing up outside of the patch version': fixing a vulnerability does not mean the credentials are already secure. Within the system's own protection, JWT authentication, content sensitive word filtering, and anti-crawling interference codes belong to the daily defense line, and after an emergency upgrade, it should be confirmed that these configurations have not been temporarily changed.
Common questions
Can we just do a temporary mitigation first, and upgrade in the next cycle?Mitigation items can reduce the exposed area, but the announcement clearly states the version of the fix; mitigation should not replace the upgrade; temporary configurations must be registered and recycling time set.
Should multiple sites be upgraded together?It is recommended to batch by site, first verify the regression list for the site with the smallest traffic, and then push the main site, to avoid affecting all business entry points with one operation.
Should the administrator's password be changed after the upgrade?In cases involving forged credentials or injection issues, related keys should be rotated and the administrator's password should be changed; this is part of the fix cleanup and does not belong to redundant actions.