After the release of the high-risk patch, the official said there were no complete mitigation measures, and which temporary configurations can be changed.
PHP officially stated that when there are no complete mitigation measures for two high-risk vulnerabilities, the sites that cannot be upgraded immediately can only temporarily adjust a limited number of configurations: release memory limit, adjust the size of the request body according to whether there is upload business, close session upload progress, and close fatal error backtracking on the latest branch. These changes only shorten the exposure window and cannot replace the upgrade, and all work processes must be restarted to take effect.
Why does the official emphasize the lack of complete relief?
On October 21, 2026, PHP released fixed versions simultaneously in four supported branches: the 8.5 branch was upgraded to 8.5.12, the 8.4 branch to 8.4.27, the 8.3 branch to 8.3.36, and the 8.2 branch to 8.2.35. Both issues were rated 9.2, and the nature was unauthorized remote code execution.The official statement on temporary disposal is very direct: without complete mitigation measures, upgrading is the safe approach. The actual meaning of this statement is that any configuration change is changing the exploitation conditions rather than eliminating them, and when scheduling, they should be treated as actions to gain time rather than as completed disposal.
The four items that can be temporarily adjusted and their respective costs
The first item is the memory limit. One issue is related to the memory exhaustion path, and the official recommendation is to set the memory limit to unlimited and write it first in the service pool or Web service configuration to avoid triggering the exhaustion branch;The cost is that out-of-control scripts are more likely to consume the entire machine, and it needs to be used with process-level quotas. The second item is the request body limit, which is tightened according to the business: sites without upload functionality are set to 8M, and those with upload functionality are set to 32M, while ensuring that the single file limit is lower than the request body limit, otherwise the upload feature will be unavailable directly.The third item is the session upload progress switch, set it to off. The fourth item is only needed for the latest branch, disable fatal error traceback to prevent traceback information from entering the response content.All four items must fall into the configuration source file, changes at runtime are often ineffective for long-running processes.
The three things that must be verified after modification
The first is the effective version. In the site environment, confirm that the interpreter actually running is already one of the four fixed versions, and the package manager upgrade and panel switching often only change the available version, but not the one being used on the site.Compare systems like AnQiCMS that provide Docker images and Baota panel deployment routes more intuitively: the running environment in the container image and the version of the panel installed are two separate things, and a re-deployment is required to truly replace them.The second is the process status. All working processes running in a resident mode must be restarted, and as long as one process remains on the old configuration, the attack surface is still exposed. The third is the fallback path.Temporary configurations usually sacrifice business limits, backup before making changes, confirm that it can be restored, and write these items into the recovery list after the patch is in place, to avoid running with restrictions that have been tightened for a long time.
Temporary configurations also need to leave records
The greatest隐患 of temporary measures is not invalid, but forgotten. After tightening the request body limit, users uploading large attachments will fail directly; after closing the session upload progress, the form relying on chunked upload will lose progress feedback.It is recommended to write each change into the change record: what was changed, why it was changed, which announcement triggered it, who is responsible for undoing it after the patch is in place, and set a clear review date.Keep the export of the configuration before and after the change, it is not necessary to infer which lines were changed at that time when rolling back. This step, like backup, is a sign of completion of the operation, not additional documents;When the upgrade truly takes effect, the final step is to cancel each item according to the records.
Common questions
Question: Do I need to restart the database after modifying the configuration?Answer: No. These items belong to the script engine and Web service layer configurations, which affect the working process, and the database is not involved.
Question: Can I only modify it in the user-level configuration of the site directory?Answer: It is not stable. Some commands are ineffective for runtime overlay and user-level files, and it is easy to leave the illusion that the modification has not taken effect. After modification, use the actual effective value to review instead of looking at the file.
Question: How long can the temporary measures last?Answer: Plan from hours to days, not weeks. It only reduces the trigger conditions, the official statement has already explained that there is no complete mitigation, and the scheduling goal should be to fall into the fixed version as soon as possible.