On October 20, 2026, the PHP security team announced that it will release fixes for two critical vulnerabilities at 14:00 UTC on October 21 (23:00 Japan time). Both are rated 9.2 on CVSS v4.0, and the team is urging all PHP users to be ready to update as soon as the releases become available. Japan's IPA has also asked organizations to take inventory in advance. The scope covers not only in-house web applications but also software products and network devices that bundle PHP. While waiting for the release, the key questions are where PHP is used and who updates it, and by what route.
Both rated 9.2; details and affected versions to be disclosed at release
The official PHP announcement states only that both vulnerabilities are rated Critical, with a CVSS v4.0 score of 9.2. The team plans to publish the vulnerability details, the affected versions, and the fixed version numbers at the same time as the releases.
In other words, at the pre-announcement stage you cannot check whether your own setup is affected against an official list. The announcement also does not describe the affected features, operating systems, or the configurations required for an attack to succeed, so it would be premature to conclude from the score alone that an attack works in every configuration.
There is also a caveat about the release time. The PHP team indicated that it may move the schedule up if details of either vulnerability become public or if evidence of actual exploitation emerges. Waiting until 23:00 to start preparing would make it harder to respond to an earlier release.
However, the fact that the team laid out conditions for an earlier release does not mean attacks have been confirmed. IPA's alert states explicitly: "IPA has not confirmed any attacks exploiting the two vulnerabilities covered by this information at this time." A request for precautionary preparation should be kept separate from reports of actual damage.
Can a configuration change alone block attacks?
CERT-EU published an advisory identifying the vulnerabilities as CVE-2026-109618 and CVE-2026-109619. It cites the possibility of arbitrary code execution without authentication and of impact on PHP 5 and later. Arbitrary code execution means a remote attacker can run their own code on the server.
That said, CERT-EU's assessment draws on multiple sources, including leaked information, and PHP's pre-announcement does not give the CVE numbers or this broad range of impact. The "PHP 5 and later" information is useful for thinking about what to watch, but it should be distinguished from an officially confirmed list of affected versions.
In Japan, GMO Flatt Security has published response guidance based on its own research. The company believes that, as long as the issue it found in its own research matches the vulnerability known as "php2shell," a feature that records file upload progress in the session is involved. It says, however, that it was not part of the disclosure coordination for this case.
A later addition deserves attention. In an update at 14:00 Japan time on October 21, the company said that changing the session.upload_progress.enabled setting alone would be only a mitigation and is expected not to prevent the attack itself. Judging that disabling the feature, as suggested early on, is enough would be risky. In the company's assessment, a patch is fundamentally necessary.
The company also points out that code claimed to exploit the vulnerability has begun circulating on the internet. The circulation of such code is a reason to hurry preparations, but it does not by itself mean that attacks on production environments have been confirmed. Leaked technical information, the feasibility of an attack, and observed real-world attacks are each distinct pieces of information.
Check products that embed PHP, and hosting as well
Preparing for the PHP update means splitting where you check across three areas: runtime environments you manage yourself, products that embed PHP, and environments managed by hosting providers.
IPA explains that PHP is sometimes used inside software products and network devices in ways users cannot see. The UK NCSC's recommendations likewise advise continuing to check update information from third-party vendors, including for devices and services that embed PHP. The point of contact for preparation differs between PHP that a site operator can update directly and PHP that is updated through the provider of a product or service.
Organized by who manages the update, drawing on both agencies' recommendations and the response notice that KAGOYA updated at 18:20 Japan time on October 21, the items to check are as follows.
| Environment using PHP | What to check before release | Basis |
|---|---|---|
| Runtime environments you manage | Inventory of PHP use and update procedures; prioritize internet-facing systems | IPA overview and recommended actions; NCSC recommendations |
| Products and devices that embed PHP | Manuals, vendors' security information, and notices about fixes | IPA overview; NCSC recommendations on third-party vendors |
| Provider-managed hosting | Your plan and the response policy for each PHP series, plus the update schedule | KAGOYA's plan-by-plan notice |
This table classifies the pre-release information available that day by who manages the environment. It does not compare the risk level of each environment or whether fixes are complete. Some categories overlap, as with products and hosting, and it does not cover every form of delivery.
In KAGOYA's case, for the PHP 8.2, 8.3, 8.4, and 8.5 series on its rental server plans, it plans to update in sequence after confirming the fixed versions scheduled for release. For plans such as managed dedicated servers, shared servers, and WordPress-dedicated servers, it says it is still adjusting its response policy. Even with the same provider, you cannot tell when updates will arrive without checking your specific plan.
This is KAGOYA's schedule and not information about other companies' responses or completed updates. IPA also adds that it is not asking organizations to individually check every product, including those where internal PHP use is unknown. Its guidance is to start with the uses you already know about and public information, then follow up on updates from providers.
From release to applying fixes and testing
After release, the next step is to compare the affected versions and fixed versions published by the PHP team against the environments you have identified. For PHP embedded in products or services, you also need to check information from the developer or provider, as IPA urges. The PHP release itself and the point at which fixes reach the products you use should be confirmed separately.
Flatt Security recommends confirming in advance not only the update procedure but also the procedure for verifying application behavior afterward. It also lists as preparation items checking the communication flow for cases involving downtime, and limiting data and privileges on servers to what is necessary. Whether logs are being recorded and preserved in a form resistant to tampering is another item to check.
If you cannot update immediately, CERT-EU recommends considering isolating internet-facing applications from the public network, and the NCSC offers the option of taking systems offline until they can be adequately mitigated. This is advice for deciding whether to keep running until you update, not for continuing operations on the assumption that changing a single setting makes you safe.
Using the 23:00 Japan time schedule as a guide, check the affected and fixed versions from the official PHP release and the responses announced by your providers. Before release, line up the people and procedures so that this information can be turned into actual updates and behavior checks.