Why does the official say that the only way is to upgrade for the two high-risk remote code execution vulnerabilities in PHP?
PHP two high-risk remote code execution vulnerabilities, why does the official suggest that only upgrading is the only way? Because the vulnerability is located in the language runtime environment itself, the trigger point is before the business code, and it cannot be touched by configuration items, firewall rules, and code review. The PHP official released four versions, 8.5.12, 8.4.27, 8.3.36, and 8.2.35, on October 21, 2026, and the announcement was very direct: there are no complete mitigation measures, upgrading is the only safe choice.
Why does 'temporary avoidance' not apply to such vulnerabilities?
The two vulnerability numbers are CVE-2026-109618 and CVE-2026-109619, both with a CVSS v4.0 score of 9.2, and do not require authentication to be reached. The characteristic of this type of problem is that malicious input has already caused a memory state exception at the engine layer before entering the application logic, so the application developer cannot see any exploitable call points and naturally cannot write targeted filtering rules.
The official temporary suggestion given in the earlier preview was to disable the upload progress configuration related to a certain session and to restart each work process. The limitations of this action are obvious: it only narrows a part of the triggering path and has no intercepting effect on attackers who have already obtained code execution capabilities. Taking 'changed the configuration' as 'already safe' is the most common misjudgment in such events.
The version life cycle determines whether the patch can wait for it.
Announcement also reminds that PHP 8.2 reaches the end of its life cycle on December 31, 2026, and will no longer receive any security fixes. That is to say, even if the site stuck at 8.2 upgrades to 8.2.35 this time, it is only delaying the problem until the end of the year: when the next同等level vulnerability appears, there will be no new version to upgrade.
The lifecycle of the running environment is not a question of 'can it be used', but rather 'if there is a problem, does anyone give you a patch'. The criteria are simple: whether a branch of the environment is still within the security repair window. If not, the upgrade target must select a branch that is still being maintained, rather than patching another dead end.
How much debt can be avoided by switching to a different operating model?
In the interpreted runtime environment represented by PHP, the security boundary of CMS is almost completely bound to the supply chain of language version, web server, and extension modules. If any link in the chain has a high-risk vulnerability, the site must go through a complete upgrade window.
AnQiCMS has chosen another path: based on GoLang development, the technology stack is GoLang plus the Iris framework and GORM, the compiled product is a single executable file, and it does not require additional language interpreters or extension layers at runtime.This is not the debt of 'vulnerability types', but the debt of 'dependency layers' - fewer runtime components need to be tracked, and the preparation cost for the upgrade window of similar sites is also lower.The official statement on the resource side is that the memory usage is reduced by about 80% compared to PHP class CMS, and this gap will directly reflect on the choice of host specifications in high-concurrency scenarios.
It should be emphasized that the technology stack only determines the number of layers of exposure, not whether a vulnerability will occur. Regardless of which language is used, the product's own security version release must be followed up on schedule.
Common questions
Question: Can we only upgrade the web server without upgrading PHP?Answer: No. These two vulnerabilities are within the PHP engine and are unrelated to the front-end web server. Upgrading Nginx or Apache will not change the triggering conditions.
Question: If the site is hosted on a website building platform, do you need to operate it yourself?Answer: You need to confirm the runtime version and release time with the platform. The patching rhythm of the hosting platform is determined by the platform itself, and you need to obtain the information of the specific minor version currently running, not just such an oral conclusion as 'fixed'.
Question: How to prioritize when multiple PHP versions coexist?Answer: First handle the branches that are still in use and have released fixed versions, then handle the branches that have entered the end of life; for the latter, the upgrade goal is to migrate to branches that are still being maintained, rather than continue patching.