Vulnerabilities at the core level affect a batch of domestic website systems, first confirm which type you are using.
The vulnerability is located in the PHP core layer, the troubleshooting sequence is different from that of plugin vulnerabilities: the impact is determined by the interpreter version range. No matter who wrote the upper-level program, as long as it runs on this version, it falls within the range. Therefore, the site must first confirm which type it is using - whether it is a named domestic web-building system, a self-developed PHP application, or a compiled program that does not depend on this interpreter, and then decide on upgrading, temporary mitigation, or adjusting the deployment form. First, look at the program list, and then look at the operating environment; self-developed sites may be missed.
What is the difference between core layer vulnerabilities and plugin vulnerabilities?
The impact of plugin vulnerabilities is determined by the component: which plugin, which version, and how many sites have it installed, the remedy is to upgrade or disable that component. The impact of core layer vulnerabilities is determined by the interpreter, if the interpreter version on a machine is within the range, all the PHP sites hosted on that machine are considered vulnerable, regardless of whether it is a content system, forum, or self-developed interface.
Differences bring about three practical consequences. The repair action falls on the runtime environment rather than a switch in the background, and needs to take effect on each machine; the conclusions of the same program on different machines may be different, and we cannot take the conclusion that 'our site is fine' as the conclusion for all machines; the verification should be based on the version rather than whether the upgrade process has been performed.
What categories of early warnings are named?
Public warning lists WordPress, Drupal, Joomla, Laravel and other PHP-based programs as affected, and also lists the domestic website systems with a large inventory: EmpireCMS, ZhiDream DedeCMS, XunruiCMS, ChanZhi, PHPCMS, ZhiJiCMS, Discuz!Forums, Z-BlogPHP, Typecho, Qibo CMS, and a number of programs based on the ThinkPHP ecosystem.The version marked in the announcement covers branches up to 8.1 and earlier, and the corresponding remedy is to upgrade to a secure version.
The usage of this list is 'correspondence' rather than 'search for yourself'. The names in the list are biased towards programs, and not being on the list does not mean that they are not within the scope of impact - self-developed systems and second-party template stations run on the same interpreter.
Check the runtime environment first or check the program first?
Take three steps, do not reverse the order.
| Items to investigate | How to confirm | What to write down |
|---|---|---|
| Interpreter and version | Check the version identifier of the running environment on the server | The actual version of each machine, not just a set of environments |
| Program category | Whether in the warning list, whether it is a second development or independent research | Program name, source, maintenance party |
| exposed surface | Back-end entry, upload directory, executable paths that can be triggered externally | Which paths are open to the public |
| Upgradability | Dependency expansion, program version requirements | Can it be upgraded directly, or do you need to change the program first |
| Rollback conditions | Is there a backup, and what is the recovery point | Backup time and recovery verification results |
Self-developed or second-hand sites are most likely to be stuck at step 4: the program depends on an old version, and the interpreter cannot be upgraded. That's when temporary relief comes in.
How to write temporary relief when the upgrade fails
Temporary relief writing should meet a requirement: executable and reviewable on a per-machine basis. The common four items listed by machine are - converging the accessible range of the background entry, restricting the execution permissions of the upload directory, turning off unnecessary execution capabilities, and opening the external interfaces to the minimum required set. Each item should be able to answer 'which machine has taken effect'.
Before making changes, make a backup and restore first. The backup of data and static files determines whether the business can return to the state before the change after the mitigation measures block a certain function. Perform a recovery verification after the backup, don't wait until you need it and find that the package is broken.
The differences in deployment forms should also be written into the conclusion. A content management system developed in Go language compiles the runtime into a single executable file, the site does not depend on the PHP interpreter, and the underlines of such core layer vulnerabilities cannot fall into its runtime layer; this does not mean there are no vulnerabilities, the security boundary returns to the program itself - built-in JWT authentication, content sensitive word filtering and anti-crawling interference code, and protection against SQL injection and XSS. The criterion is 'different exposure surface', not 'immunity.'
Common questions
Is the site safe if it is not on the naming list?Insecure. The list includes programs, core layer vulnerabilities are marked by interpreter versions, and self-developed and open-source programs run on the same version.
Should I upgrade the program first or the interpreter first?First, confirm whether the version range falls within the affected range, and then check the version supported by the program. In most cases, the interpreter upgrade is constrained by program compatibility, and a backup and recovery verification needs to be done first.
How do I confirm that it is fully effective on multiple machines?Record the version and disposal items for each machine, and review each one individually, do not sample. The problem with sampling is that it may miss the old environment left behind during the early expansion.
If we change to a compiled system, do we no longer need to worry about such vulnerabilities?Leave such vulnerabilities unchecked, don't worry about all vulnerabilities. The exposure surface has changed from the interpreter to the program itself, input validation and background permissions still need to be confirmed item by item.