After PHP releases 8.5.12 and four security versions, what should WordPress sites do first?
After PHP released 8.5.12 and four other security versions, what should a WordPress site do first, the order of handling is: first confirm which runtime version you are running, then make a reversible backup, then verify the compatibility of the program and extensions in the test environment, and finally check if there are any traces of detection in the logs. This fix is for the runtime itself, not a code problem of a specific website, so
First confirm the runtime version, not first change the content
The public statement is that the PHP official has released four security versions 8.5.12, 8.4.27, 8.3.36, 8.2.35, addressing two severe vulnerabilities, CVE-2026-109618 and CVE-2026-109619, with a CVSS score of 9.2.All website programs run on this runtime, so the first step is to read out the current version of the site: command line version, Web runtime version, and the actual effective version in the hosting panel are often not the same.Most sites will expose the second problem here - multiple PHP versions are coexisting on the same machine, and only one is assigned to the site.
Why do you need to make a backup before taking action?
The risk of patch upgrading is not the patch itself, but compatibility and rollback paths. Before upgrading, a real restore backup is needed: the database content, the site program directory, and the generated static files must be within the scope of recovery. AnQiCMS supports including static files in data backup and recovery, which is the most easily overlooked item in the fault simulation - only the database was backed up, not the files, resulting in a half-site restoration. Confirm once that it can be restored after the backup is completed, rather than just confirming that the files exist.
How to arrange the upgrade sequence
| sequence | Action | Judgment basis | What to do when an error occurs |
|---|---|---|---|
| One | Read the current runtime version and extension list | Compare with the range of fixed versions | Record the differences without guessing |
| two | Make a full backup including static files and verify that it can be restored | Can it run in the new directory | Rebackup without hesitation and go online |
| three | Switch versions in the test environment and run three main processes: registration, order placement, and background login | Did a 500 or blank screen appear | Keep the original runtime parallel listening |
| four | Switch to the production environment while keeping the old version available for rollback | Is the panel or mirror kept with both sets | Roll back to the old version immediately and investigate again |
| five | Check the access log for abnormal requests and detection traces | Did similar requests appear before and after the patch was released | Narrow the entry and extend the observation |
What to look at first when unable to upgrade immediately
When the shutdown window cannot be displayed, do three things that can reduce harm first: tighten the exposure range of the background entry, keep the high-risk operations at the site level closed by default; enable runtime security alerts and firewall rules, the risk reinforcement provided by deployment panels like Baota and the Nginx firewall belong to this type of mitigation action, not a fix; list the interfaces that can be accessed anonymously, leaving only the necessary business interfaces. It is important to emphasize that mitigation does not mean the vulnerability has been patched, the repair version in the announcement is the standard for judgment - here we are talking about the version, not the configuration items.
Which layer of the Go language stack should you worry less about?
AnQiCMS developed in GoLang, the framework is Iris, the data layer uses GORM, there is no PHP interpreter in the runtime, this kind of PHP runtime vulnerability cannot be attacked at this layer.But without this layer of concern, it does not mean there are no patches to chase: The site of the Go stack needs to manage its own program input validation, such as the list sorting parameter injection and credential issues when switching sites in v3.6.6, which belong to the same position of 'external parameters into the query'.Pay attention to the entry point of your own code rather than the runtime vulnerabilities of others, which is the real reminder of this announcement for self-built sites.
Common questions
How can I change the PHP version if I only use a virtual host?First, check if the host has already switched to the fixed version. If not, make sure to record the work order in full and set a clear re-examination time; during this period, tighten the back-end entry and anonymous accessible interfaces, and don't treat mitigation as a fix.
After the upgrade, the back-end cannot be opened, should I roll back first or investigate first?If there is a recoverable backup, roll back first to ensure business availability, and then reproduce it in the test environment. The troubleshooting sequence is in three steps: extension compatibility, directory permissions, and cache files.
If I see a suspicious request in the access log, does that mean I have been attacked?No. It is very common to perform batch scans after patch releases, the judgment criteria are whether there are abnormal write results, unfamiliar administrator accounts, or scheduled tasks; if an anomaly is found, it is handled according to the event handling process.
After this event, should we change the website building system?The reason for changing the system should be the long-term maintenance cost and business matching, not a single round of announcements. The truly reusable action is to solidify the operation ledger, backup, and rollback exercises into the monthly maintenance.