PHP issues urgent fixes for two critical flaws as Kyoto pauses some online services
Security updates are available for four supported PHP branches. Kyoto has temporarily suspended several municipal forms while it checks its systems; the PHP Foundation has also acknowledged why one of the fixes took years to deliver.
Two critical flaws in PHP, the programming language behind many online services, have prompted urgent updates and precautionary shutdowns. The PHP project released fixes on Wednesday, October 21. The following day, the city of Kyoto said it had temporarily suspended some online forms and services while it checked its systems and applied the patches.
The warning concerns anyone responsible for a PHP server, including public agencies, businesses and hosting providers. Under certain conditions, the flaws could let an attacker run code on a server without first signing in. A password on the administration panel is therefore not enough: the vulnerable software processes web requests beneath the site visitors see.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, each belonging to a different supported branch. The project's advisory urges operators to update immediately. Temporary steps to reduce exposure are not a substitute for a complete fix.
Kyoto pauses forms; no breach has been confirmed
Kyoto said the interruption affects inquiry forms, event registrations and surveys on its Kyoto City Information Center website. The affected channels include the mayoral correspondence form and municipal inquiries. Other parts of the city's online services may also remain unavailable while their security is checked.
As of 3 p.m. Japan time on October 22, the city had not confirmed tampering, a data leak or unauthorized access to the servers it manages. It described the shutdown as a precaution to protect information, not as evidence that a breach had already occurred. The affected services were to remain offline until the city could confirm they were safe to restore.
That decision illustrates the trade-off facing many organizations. Taking a form offline temporarily prevents people from submitting requests, but leaving it online during a security check could prolong its exposure. Administrators first need to establish which PHP version runs the service and how the relevant update can be applied.
The vulnerable component sits behind the web page
PHP runs on the server. It may generate a page, receive a form or retrieve information even though its name never appears to the visitor. Taiwan's Administration for Cyber Security noted on Thursday that PHP underpins content-management systems including WordPress, Drupal, Joomla and Magento. It can also be built into products that do not prominently identify it.
That does not mean every installation of those products has been breached. It means operators need to check the underlying component. Updating an application and updating the environment on which it runs are related tasks, but they are not necessarily the same task.
The PHP advisory covers sites handling requests through different server setups, including PHP-FPM and Apache with mod_php. The developers describe the risk as particularly high in the latter configuration. The flaws involve memory handling and the internal state of requests: in certain circumstances, the server can treat data as valid after it should no longer do so.
The identifiers are CVE-2026-109618 and CVE-2026-109619. Taiwan's cybersecurity authority assigns both a severity score of 9.2 out of 10. That score describes technical risk; it is neither a count of victims nor an estimate of how many sites have been compromised.
Why one fix took years
The PHP Foundation says early signs of the problem that led to one vulnerability emerged in 2024 during work connected to an external audit. A possible route to exploitation was discussed then, but no concrete way to carry it out had yet been found.
Fixing the underlying defect proved difficult. Some proposals threatened compatibility, risked creating other ways to disrupt services or required changes across numerous extensions. The foundation says delays in decision-making and a shortage of specialized resources caused work on the fix to stall and resume several times.
New reports received in August 2026 demonstrated the scope of the danger and made the fix a priority. The organization says it has changed its security team and decision-making process to reduce the risk that another serious problem remains unresolved for so long.
The episode also exposes an organizational challenge: many institutions rely on shared software, but keeping that infrastructure secure requires people who can investigate flaws, coordinate a response and distribute repairs.
What operators need to check
Organizations should identify the PHP version they use and confirm with their provider that the appropriate patch is available. PHP 8.1 and older branches no longer receive regular releases from the PHP project, although some distributors provide backported security fixes. Customers need to verify that coverage rather than relying on the version number alone.
Heroku, for example, announced the new releases and told customers to redeploy applications to pick them up. It also provided a fix for its older PHP 8.1 environment while recommending migration to a supported branch. The procedure therefore depends on the hosting service and on who manages the server.
Taiwan's cybersecurity authority advises operators to examine logs and unusual access after updating, and to check accounts and credentials if they find signs of suspicious activity. Installing the patch addresses the known flaws; on its own, it cannot establish what happened before the update. Visitors may see only a temporarily unavailable page. For administrators, the job is finished when the update has been verified and the service can safely be restored.
