PHP two high-risk vulnerabilities scored 9.2 points, what steps should the site take after the patch is released?
Fix for two high-risk vulnerabilities rated 9.2 in PHP was released on October 21, 2026, along with 8.5.12, 8.4.27, 8.3.36, and 8.2.35. After the site upgrades to the new version, it still needs to complete three steps: confirm that the actual running process has been updated to the new version, investigate the high-risk entry points related to vulnerability exploitation, and check that the internal defense configuration within the site is still effective. The patch release is just the starting point of this window.
The three hard facts that can be read from the announcement
The first is scoring and nature. The scores of the two vulnerabilities are both 9.2, belonging to the high-risk segment, which means that the conditions for exploitation are relatively relaxed and the impact is relatively large, and cannot be handled according to the regular vulnerability schedule.The second is the coverage range. The fix enters four supported branches simultaneously, indicating that the affected versions span multiple major versions, and sites still in 8.2 and 8.3 are on the list.The third is the distribution of the fixed version: the 8.5 branch is upgraded to 8.5.12, the 8.4 branch is upgraded to 8.4.27, the 8.3 branch is upgraded to 8.3.36, the 8.2 branch is upgraded to 8.2.35, each branch is patched locally, and no major version change is required for this.
The specific vulnerability number can be found in the announcement and the vulnerability entries of various countries, and only the number should be left as a search clue when discussing publicly, no need to repeat the exploitation details in the site articles.
Verify what first after the upgrade.
The easiest illusion is that 'I have executed the upgrade command, so it is fixed.' The actual running status needs to be verified separately.
Check the version. Confirm in the site environment that the actual effective interpreter version has fallen into one of these four fixed versions. Sometimes, package manager upgrades and panel switches only change the available version, without changing the one being used on the site. Next, look at the processes. Processors running in a resident mode (such as fpm or the corresponding worker processes) need to be restarted to load the new version, and it is common for some processes to remain running on the old version, which is also the most difficult to discover. Finally, look at the regression. After version switching, run the main links such as login, upload, form submission, and observe the error logs to confirm that no new faults have been introduced due to compatibility issues.
Restrict the exposed surface outside the runtime environment
The patch fixes the interpreter, but the actual risk of the site also depends on the upper application and configuration.
Firstly, entry convergence. Check whether the background entry, debugging interface, and unused components can be closed or restricted in access. Most exploits of high-risk vulnerabilities require an accessible entry point, reducing the entry point is to reduce the exploit surface.The second is online verification and data validation. AnQiCMS is built-in with JWT authentication and content sensitive word filtering, anti-capturing interference code, used for defense against SQL injection and XSS attacks;This built-in protection within the station belongs to a layer of defense in depth and cannot replace runtime environment patches, but it can reduce the impact after exploitation when the patches are not applied in time.Three credentials side finishing. AnQiCMS fixed the issue that the login credentials of the site switch could be forged in v3.6.6, and the official recommendation was to rotate the site signature key and change the administrator password at the same time;The principle is universal - once a type of certificate can be forged, after patching, it should be assumed that the old certificate has been exposed.
Regularized action
The frequency of high-risk vulnerability occurrences determines that temporary response is not enough. It is recommended to fix three things: include the supported runtime environment version and its expiration date in the asset list; establish the minimum exercise path from the patch to production, so that the upgrade does not require setting up an environment temporarily; and write the rotation of background passwords and signature keys into the upgrade process, rather than waiting for an incident to occur before addressing it.
Common questions
Question: What if the hosting environment used by the site cannot change versions on its own?Answer: Confirm with the service provider whether these four versions have been applied and request the actual effective time; if unable to confirm, turn off the high-risk features that can be turned off independently first to reduce the exposure during the waiting period.
Question: Can only the command line version be upgraded?Answer: Not enough. The site is provided by a resident process, and the process is still using the old version without restarting, so the Web service must be handled together with all the working processes.
Question: How can you confirm that it hasn't been hacked?Answer: Check for requests with suspicious parameters during abnormal periods in the access log, check for new unfamiliar files and abnormal scheduled tasks, and verify background accounts and login records; handle suspicious signs according to the intrusion response process, isolate first and then collect evidence.