PHP's Critical Flaws Drew a Prime Minister's Call. What Happened, and How to Prepare

Hello, this is Ryuta Hamamoto from TIMEWELL.

On the evening of 21 October 2026, Japan's National Cybersecurity Office and Prime Minister Sanae Takaichi were each reported to have posted on X, urging people to act on two critical PHP vulnerabilities. The Prime Minister's post reportedly opened with the words "an urgent request."¹² According to the press, it came before the fixed release was due out. A government asking people to prepare before a patch exists is not something I have seen often.

In this article I first lay out what happened, keeping what the PHP project itself confirmed apart from what the press reported about the government. Then, on the assumption that this will happen again, I describe what a company can set up in peacetime. I also include what we checked on our own side for Node.js, limited to facts. Figures and dates are those I could confirm by the morning of 22 October 2026.

What happened, in order

Date	Event	Source
20 October	The PHP security team announces that fixes for two critical vulnerabilities will ship on 21 October at 14:00 UTC (23:00 the same day in Japan). It reserves the right to move the date earlier if details leak or exploitation is seen	3
21 October	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released. The flaws may allow unauthenticated remote code execution; users are strongly urged to update immediately	345
Evening of 21 October	Press reports say Prime Minister Takaichi posted on X around 10 p.m., and that the National Cybersecurity Office's official account also urged prompt application of the update	126
From that night	Press reports say game, illustration-sharing, banking, railway and hosting companies carried out precautionary emergency maintenance	7

I have not viewed the Prime Minister's post myself. According to reports by Nippon TV and the Mainichi Shimbun, she asked people to prepare so the fix could be applied as quickly as possible, and said that temporarily taking a website offline is one effective option if patching is difficult.¹² The National Cybersecurity Office's posts were reported to carry the same message.⁶ So this is confirmation through the press, not from the original posts.

What the vulnerabilities are

According to the PHP project's own announcements, two flaws were fixed. Both are rated 9.2 on CVSS v4.0, in the Critical band.³⁴⁵

The first, CVE-2026-109618, concerns out-of-memory handling. If PHP is interrupted partway through setting up a request, internal data can be left only partly initialized, and later cleanup code may treat that bad data as valid.⁴ The second, CVE-2026-109619, concerns internal state that outlives the memory behind it. When the same worker handles the next request, it can reuse that stale state.⁵

Both can allow an unauthenticated attacker to gain the privileges of the web worker. The project says every environment that handles web requests is affected: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed and others. It considers mod_php the riskiest, because an exploit has been demonstrated that works with an unauthenticated request before any application code runs.³

The key point is that the project itself says there is no complete mitigation and that updating is the only safe option.³ Settings such as removing the memory limit or disabling session upload progress only reduce exposure to particular attack paths; they do not make a system safe.³⁵ Before release, some had suggested that a single setting might help, but further research reportedly showed that it does not.⁸

Which versions you run also matters. Fixed releases exist for the 8.2 to 8.5 lines. PHP 8.1 and earlier no longer receive project updates. For 7.4, 8.0 and 8.1, the project published minimal source backports for people who build from source, but the basic advice is to check what your distribution or support vendor offers, or to move to a supported version.³ The 8.2 line itself reaches end of support on 31 December 2026.³ Even after this update, a migration plan is a separate job.

Why the government moved

This part is my own view.

One reason is how widely PHP is used. According to W3Techs, 69.3% of sites whose server-side language is known run PHP.⁹ Japanese outlets reported it as "seven in ten websites." It sits in places you might not expect, from company sites and online shops to booking systems, municipal services and small businesses' WordPress installs.

A second reason is that an attack may succeed without authentication. There is no login wall to help.

A third is the gap between the advance notice and the release. This time, the existence of two critical flaws and the release time were announced before the fixes were. If there is time to prepare, use it. I read the government's call as an attempt to use that window.

One thing should not be confused. A government call does not mean damage has been confirmed. As of the morning of 22 October 2026, I could not find any official confirmation of exploitation. It has been reported, though, that the identifiers spread before release, that code claiming to exploit the flaws is circulating, and that a security company executive pointed to early signs of attacks. The circulating code is unverified, and readers are warned that some may contain malware.⁹ Whether or not damage has occurred, those who defend have to act as if attacks are coming.

It will happen again

I do not think this was the last time. The reason is in a government document.

On 18 May 2026, the National Cybersecurity Office and other bodies issued a notice to critical infrastructure operators. It says that advanced AI is expected to speed up the discovery and fixing of vulnerabilities. It also warns that if attackers misuse such AI, "the time from discovery of a vulnerability to its exploitation will become extremely short, and a large number of vulnerabilities will need to be handled."¹⁰ It therefore asks organizations to re-examine known unaddressed vulnerabilities, to maintain a thorough asset inventory, to gather vulnerability information actively, to prioritize, and to respond quickly. It also recommends building the process and structure in advance.¹⁰

The notice is addressed to critical infrastructure operators, but I think the thinking applies to every company. When vulnerabilities multiply and the time to exploitation shrinks, scrambling after the event stops working.

On the same day, 21 October 2026, Node.js also shipped fixes. According to the official announcement, the security releases are v26.12.1 for the 26.x line, v24.22.1 for 24.x and v22.23.4 for 22.x. They address ten vulnerabilities in total: four High, three Medium and three Low. The High ones include an out-of-bounds write in the Brotli decoder that can lead to remote code execution, and flaws that let TLS certificate hostname checks be bypassed.¹¹ It did not make the headlines PHP did. For those who use it, it is the same kind of day: a day when an update is needed.

What we checked

Our website is built with Next.js, a framework that runs on Node.js. Here is what we checked for both PHP and Node.js, limited to facts.

PHP. I checked the website's repository, where the source code lives. I found no PHP code, no PHP dependency configuration and no configuration that builds a PHP runtime. As far as I could confirm, no affected setup exists there. That covers only what is inside the repository. External services, contractors and rental servers cannot be judged from the repository, so we treat them as a separate item for a person to check.

Node.js. After the 21 October security release, we checked the Node.js version in the environment the site runs on (Vercel). The build log shows it running on v24.22.1, the fixed release for the 24.x line. We also changed the build so that the Node.js version appears at the top of every build log. Next time, anyone can open the log and see at once which version ran.

I do not mean to say that we are fine. Whether or not we are affected, being able to confirm within minutes which version our own environment runs when a fix ships is what lets us avoid scrambling. I think that small mechanism makes the difference.

What to do tonight and this week

For those responsible for PHP at their company, in order:

1. List the PHP you use. Your own sites, WordPress, shop systems, anything built by contractors, rental servers, and what runs inside external services. Even if you think you do not use PHP, a contractor or affiliate may.
2. Check the version. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older needs an update.³
3. Update, or ask your provider. For your own servers, update to a fixed version and restart the workers. For rental servers or Linux packages, check the updated packages from your provider or distribution. For 8.1 and earlier, ask whether a backport (a fix ported to an older version) exists.³
4. If you cannot update right away, weigh stopgaps and a shutdown together. The settings the project lists, such as memory limits and disabling upload progress, are not complete.³ As the government's call said, taking the site offline temporarily belongs among the options.¹
5. Verify after the update. If you changed settings, restart the workers and confirm the settings took effect. The official advisory warns that an absence of log entries is not proof of safety.⁵
6. Tell the people who need to know. Decide early whether management, contractors and customers must be informed.

What to build in peacetime

This is the main point. Let me narrow it to four things to decide before the next time.

First, an inventory. What software you run, at which version, where, and when support ends. Without a list, the first hour goes to working out whether you are affected at all. This is why the government's notice presses for thorough asset management.¹⁰

Second, a source and an owner. For PHP, the official announcements. For Node.js, the official security page. For each thing you use, decide who watches. In a case like this one, where notice comes first, whether anyone saw the notice changes how much time you get to prepare.

Third, a decision rule. Do you rush the update, take the site down, or wait? Decide in advance who chooses, using severity, whether authentication is needed, exposure, and the impact on the business. The government notice likewise says rapid risk assessment and response can come down to an overall judgment that includes business continuity, and recommends building the process and structure beforehand.¹⁰

Fourth, a contact chain. If a shutdown is needed, whom do you tell, and in what order? Can you act at night or on a holiday? The fixed release was announced for 11 p.m. in Japan.

Of these four, I think the inventory matters most. The other three start to work only once it exists.

Summary

For two critical PHP vulnerabilities, the project said updating is the only safe option, and the National Cybersecurity Office and the Prime Minister were reported to have called for preparation before the release. That is a precautionary move, separate from confirmed damage. And as the government's own document indicates, the time from discovery to exploitation is shrinking while the number of things to handle keeps growing.

Once the PHP matter settles down, please set aside time to build your inventory. It need not be perfect. Writing down ten pieces of software you run is enough to start. If you would like to talk about an internal review or how to set update decision rules, please reach out through the consultation form for WARP SECURITY. My article on managing equipment in the power grid takes a similar approach. I will update this article when new information comes out.

References

Footnotes

1. Expert explainer: Companies and municipalities start emergency maintenance; Prime Minister Takaichi issues a call (in Japanese) — Nippon TV News NNN — 21 October 2026 ↩ ↩² ↩³ ↩⁴

2. "An urgent request": Prime Minister Takaichi on the PHP vulnerability (in Japanese) — Mainichi Shimbun — 21 October 2026 ↩ ↩² ↩³

3. Announcements of the PHP security releases of 20 and 21 October 2026 — The PHP Group — 20 and 21 October 2026 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

4. GHSA-w8hw-w9fx-j79w (CVE-2026-109618) RCE via OOM corruption — PHP security advisory — 21 October 2026 ↩ ↩² ↩³

5. GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) RCE via stale global state — PHP security advisory — 21 October 2026 ↩ ↩² ↩³ ↩⁴ ↩⁵

6. Fix for serious PHP vulnerabilities released; National Cybersecurity Office urges prompt application (in Japanese) — Den Fami Nico Gamer — 21 October 2026 ↩ ↩²

7. Emergency-level PHP vulnerabilities: the developers release fixed versions and urge an immediate update (in Japanese) — ITmedia NEWS — 22 October 2026 ↩

8. Two fatal PHP vulnerabilities, with an emergency security release late on the 21st in Japan; updated at 15:20 (in Japanese) — Mado no Mori — 21 October 2026 ↩

9. php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ — Tenable — 21 October 2026 ↩ ↩²

10. Strengthening cybersecurity measures in light of advancing AI capabilities (notice to critical infrastructure operators; in Japanese) — Cabinet Secretariat National Cybersecurity Office and others — 18 May 2026 ↩ ↩² ↩³ ↩⁴

11. Node.js Security Releases, October 2026 — Node.js — 21 October 2026 ↩