On October 21, 2026, Japanese companies announced temporary suspensions and even shutdowns of services in response to a critical PHP vulnerability, and Prime Minister Sanae Takaichi urged organizations that evening to prepare "as a matter of urgency." But the party that releases PHP fixes, the provider that updates the PHP actually running on a server, and the operator that maintains an application are not necessarily the same. In some cases, service providers completed the fix with no action required from users. In others, operators decided to end their services because they could not take sufficient measures on older systems. Why does the path from a published fix to a resumed service vary so much?
Suspending service while waiting for the 23:00 fix
In a post on X on the evening of the 21st, Prime Minister Takaichi asked organizations to check how they use PHP and to prepare so they could apply promptly the patch scheduled for release at 23:00 Japan time that day. She explained that if a patch cannot be applied immediately, temporarily suspending a site is also a way to reduce risk. In effect, she urged organizations to prioritize reducing exposure to external attacks over keeping services running in an unpatched state.
The problem is serious because a site can be attacked from outside without any login. According to the PHP developers' announcement, exploiting the vulnerability could allow code to be executed remotely on the server without authentication, and PHP configurations that handle web requests are affected. PHP is the runtime environment that runs web applications and similar software on a server. Changing a site's passwords or updating visitors' browsers does not eliminate a vulnerability in PHP itself. On the 21st, the PHP developers released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and strongly recommended updating immediately. Organizations cannot finish the job with application-level fixes alone; the fix has to be applied to the PHP that is actually handling web requests.
In Japan, Nomura Investor Relations announced a service suspension starting at 22:00 on the 21st. The affected services were "MIR@I" and its IR information distribution service for institutional investors and analysts. The company said it would apply the fix and verify safety in response to the critical PHP vulnerability. It set no restart time and said the suspension would continue until safety was confirmed. Halting a service before a fix is released is not contradictory: it reduces the chance of attack until the fix and its verification are complete. Nor does a suspension alone show that a break-in has already occurred or that an update has failed.
The US Cybersecurity and Infrastructure Security Agency (CISA), in its alert of the 21st, urged organizations that cannot update immediately, or that use end-of-support versions of PHP 8.1 or earlier, to take systems running PHP offline until fixes or updates are complete. It also said it had not observed exploitation of the vulnerability at the time of the announcement. In other words, a service suspension does not necessarily mean damage has occurred; it can be a precaution to prevent it. However, the individual notices do not show whether each company decided to suspend because of the prime minister's post. Even if the appeal and the suspensions came on the same night, a direct causal link between the two is not certain.
Same suspension, different causes
Some companies had already suspended services before the PHP fixes were released. According to SoftBank's announcement dated the 19th, the company confirmed attempted unauthorized access by a third party to some of its systems and temporarily suspended websites including "My SoftBank" from 8:00 a.m. on the 17th. It said the app version remained available. The stated reason was attempted unauthorized access; no connection to the PHP vulnerability was indicated.
Monex Securities also suspended some account-opening applications from the 19th after finding signs of attempted unauthorized access to an account-opening system managed by an external contractor. A notice published on the 20th and updated on the 21st said the suspension was limited to new applications for general securities trading accounts submitted through that system. According to the company, the system that handles account-opening applications and paperwork is separate from the system that manages account information, balances and trading after an account is opened. It would therefore be inaccurate to treat the suspension of new account applications as a halt of the entire securities trading service. Monex's notice likewise does not link the matter to the PHP vulnerability, and the announcement date differs from the date the suspension actually began.
There is also a case in which an initial explanation about the vulnerability was corrected. In its correction notice, Valtec states plainly that its first report, which attributed an information leak to an attack targeting the PHP vulnerability, was erroneous. In reality, the incident exploited a vulnerability in the company's own service, and it had confused this with separate work it was carrying out in response to PHP. This case therefore cannot be treated as damage from exploitation of the PHP vulnerability.
These cases have one thing in common: companies restricted access to their services to contain risk. But responding to attempted unauthorized access that has already been confirmed is different from suspending in preparation for a newly published fix, and the work needed to resume differs accordingly. The former requires investigating access logs and the scope of impact; the latter centers on applying the fix and verifying safety. In light of Valtec's correction and the SoftBank and Monex announcements, service suspensions occurring around the same time cannot be lumped together as damage from the PHP vulnerability. Nor is it appropriate to judge a company's update response as slow based on the number of suspensions alone, since some services became temporarily unavailable precisely because of an early decision to halt them.
Who handles PHP updates differs on rental servers
Under Sakura Internet's PHP provision policy for its rental servers, even when a new PHP series is offered, the older series a user has configured is in principle left in place. This is because switching PHP series may cause existing applications to stop working properly. The company asks users to check their application's recommended operating environment and confirm which PHP series is supported. Compatibility concerns like these are why PHP updates cannot be pushed through uniformly.
A distinction matters here: applying a security fix to the PHP currently in use is different from changing the PHP series itself. The former fixes a vulnerability in the existing runtime; the latter means migrating the application to a different PHP series. A policy of keeping older series does not mean users must manually apply every emergency security fix. In the status update Sakura published on the 22nd, the company states that it has completed its response for all PHP versions selectable from the control panel and that no urgent action is required from users. It also advised users to consider moving to the latest supported version to stay secure going forward. In other words, fixing this vulnerability is kept separate from migrating from an old version to a new series.
Similarly, the response for Movable Type differs by delivery format. According to Six Apart's notice dated the 21st, for the cloud version the provider will perform the update after the PHP fix is released, while for the software and AMI versions it strongly recommends that users update PHP. Comparing the Sakura and Movable Type notices shows who is responsible for updating PHP itself in this response.
| Delivery format | Who updates PHP itself | What users are asked to do |
|---|---|---|
| Sakura rental server | Provider announced completion for all selectable PHP versions | No emergency action needed this time. However, application testing is needed when migrating to a new PHP series |
| Movable Type cloud version | Provider said it will update after the fix is released | No user action needed for this update. Environments with automatic updates disabled are also covered |
| Movable Type software and AMI versions | Users update PHP themselves | Users must arrange updates to suit their own operating environment |
This table summarizes the division of responsibilities each company announced for this incident; it does not apply to all hosting services. Sakura's completed response shows that rental server users do not necessarily need to perform an emergency update themselves, and that updates are not necessarily delayed. If the provider applies the fix across the board, there is no need for each user to update PHP itself.
On the other hand, even within Movable Type, users' roles differ between the cloud version and the software and AMI versions. The product name alone does not tell you who updates PHP; you need to check which delivery format you contract for and what the provider manages. For the cloud version, environments with automatic updates disabled are also covered by this response, which shows that normal update settings and the scope of an emergency response do not necessarily match. Moreover, completing the server-side fix does not guarantee that an application will run correctly on any PHP series. The PHP runtime the provider manages and the compatibility of the applications users operate are related, but they must be maintained separately.
A fix for EOL versions does not restore normal maintenance
The PHP developers announced that they had prepared minimal source code fixes even for PHP 7.4, 8.0 and 8.1, which are no longer under normal support. The measure is meant to help people who build PHP from source themselves and those who cannot use a provider of long-term support. It is therefore inaccurate to understand that no fix at all is provided for old, unsupported PHP. However, publishing fixed source code is a separate matter from providing an update package that can be applied as is to a contracted server. Building from source requires someone to carry out that work and deploy the result to the production environment. Shared server users and others without permission to manage PHP itself cannot apply the fix just by obtaining the source code.
Under the PHP developers' support policy, each series receives two years of regular support, followed by two more years of fixes for critical security issues. When this total of four years ends, the series reaches EOL (End of Life). PHP 8.1 and earlier series are already outside this regular update coverage. However, the PHP developers also explain that some Linux distributions and long-term support providers may backport security fixes to older versions. The content of this fix was provided in advance to distributors, and users were advised to check each vendor's update packages.
Therefore, the fact that PHP developer support has ended does not mean one can conclude a given server is unpatched against this vulnerability. What matters is which provider supplies the PHP actually running and whether this fix has been applied to that environment. Migrating to a newer upstream PHP series and having a distributor backport the fix to an older series involve different update mechanisms. It is necessary to check not just the PHP version number but whether the fix has been applied in the environment you use.
On the other hand, the fact that source fixes were specially provided this time does not mean normal support for older series has resumed. There is no guarantee that the same measure will be taken when another vulnerability is found. Reducing immediate danger with this emergency fix and migrating to a continuously maintained PHP series are separate tasks that should proceed independently. Sakura's PHP provision policy likewise explains that older versions whose security support has ended may continue to be offered, but that it may end their provision without notice if a serious vulnerability emerges. Even if the period during which old applications can run is extended, there is no guarantee of a means to fix future vulnerabilities.
Who keeps maintaining old systems?
World Quest announced on the 21st that it would end its service that same day. It explained that, following the announcement of the serious PHP vulnerability, it could not take sufficient measures because the service runs on an old architecture, and it prioritized protecting users' information. This is a case where the operator gave up on continuing the service itself rather than suspending it and resuming after a fix. However, the notice does not disclose the PHP version, the server contract or the status of any maintenance contract. It cannot therefore be concluded that the use of a particular old PHP version or rental server, or the expiry of a maintenance contract, was the direct cause. All that can be gleaned from the published information is that the operator judged it could not take sufficient measures with its existing system.
The maintenance status of an application must be checked separately from support for PHP itself. For example, Movable Type's product lifecycle policy states that for products that reach EOL, all support ends, including maintenance, bug fixes and security patches. Except for the cloud version, continuing to use a product after EOL is itself possible, but security risks remain, so the company strongly recommends migrating to a current version before EOL. The company also distinguishes between EOM (End of Maintenance), when regular maintenance ends, and EOL, when all support ends. After EOM, the company may still address critical security issues at its discretion, but once EOL is reached that response also ends. That a site is currently running normally does not tell you whether the product is still maintained.
The policy also states that customers who keep up annual maintenance can receive upgrade support even if they use a version that has reached EOM. A maintenance contract therefore matters not only for continuing to use the current version but also for support when moving to a newer one. How much support one can actually receive must be checked against both the product's support deadlines and the contract terms.
When the maintenance deadlines for PHP itself and for an application differ, the required response changes too. Even when a PHP fix is available, if the application needs to be modified to work with a newer PHP series, the PHP developers do not take on that work. Sakura asks users to check their application's operating environment before changing PHP series precisely because users must verify this compatibility themselves. In other words, the PHP security fix and the application modification may involve different people and different work.
The term "out of maintenance" also needs to be broken down: the end of PHP developer support, the end of support for an application product, and the end of an individually signed maintenance outsourcing contract are different things. Support deadlines for PHP and application products can be checked in the developers' public information, but individual maintenance contracts can only be understood by examining the contract itself. It cannot be assumed across the board that such contracts had lapsed at the companies that suspended services this time.
Publishing an emergency patch does not automatically resolve the migration of old systems or application modifications. Even if the person responsible for updating PHP itself is decided, if it is unclear who will modify and test the application, deciding to restart a service safely becomes difficult. Although the details of World Quest's internal circumstances cannot be inferred from its case, it shows that when an operator judges it cannot take sufficient measures, giving up on continuing the service is one possible choice.
What information is needed to decide on restarting
In its advance notice, the Information-technology Promotion Agency, Japan (IPA) explained that PHP may be used not only in web applications but also inside software products and network equipment. For such products, users may not be able to tell whether PHP is in use. IPA asks organizations to check manuals and product vendors' security information and to identify usage as far as they can. However, it does not require checking every product in use individually for PHP, and advises watching vendors' information for those that cannot be determined. This draws a line between what users can check themselves and what must await the product provider's response.
Even when companies move to respond, compiling a list of systems that use PHP is not enough. As the Sakura and Movable Type examples show, who handles updates differs by delivery format even for the same PHP. For each system, organizations need to identify the provider supplying the runtime environment and the organization or person actually doing the update work. They then need to decide whether applying this fix is sufficient or whether migration to a different PHP series is also needed. Completing the PHP fix does not necessarily mean the application compatibility checks that come with changing series are also done. Conversely, in environments such as Sakura's, where the provider has explicitly stated that it has completed the emergency response, users do not need to fix PHP itself on their own.
What management needs to grasp is not only the number of suspended sites but also what remains to be done to restart each service. Is it waiting for the PHP fix to be applied? Does the application need migration and testing? Or is a separate attempted unauthorized access being investigated? Even for the same suspension, the work that determines restart and the responsible organization differ. The prime minister's appeal conveyed widely the need to hurry update preparations, but it does not change the management authority over individual systems or the scope of maintenance contracts.
What matters is not just obtaining the fix but making clear who handles the update of PHP itself and the checking of applications, and what conditions must be met before a service can restart. Rather than looking up who is responsible and what the contracts cover for the first time in an emergency, organizations need to define the division of responsibility for updates and testing in normal times. Whether the next "urgent" response can be carried out reliably depends on this everyday maintenance structure.