Japan's Prime Minister Posted an "Urgent Request" Over PHP2Shell: The Night Japan Switched Off, and What to Check on Your Site

At 9:55 p.m. on October 21, Japan’s Prime Minister posted on X.

It was labeled “大至急のお願い” — roughly, “an extremely urgent request.”

Check whether your public websites use PHP, she wrote, and apply the fix as soon as it’s out. If you can’t patch right away, temporarily taking your site offline is one valid way to reduce the risk.

A head of government telling people it’s fine to switch their websites off, over one programming language. By then, a lot of Japan already had: Uma Musume, Granblue Fantasy, niconico, pixiv, and the e-commerce platform BASE were all down.

The cause: PHP2Shell, two critical vulnerabilities in PHP itself — the language a huge share of the web runs on.

Japan went into lockdown overnight, while most of the world barely noticed. I read through the Japanese coverage to piece together what happened that night, and what anyone running a website should actually check.

Information as of October 22, 2026.

October 21: Japan’s night

PHP2Shell timeline from the October 20 pre-announcement to services resuming early October 22

All times are Japan time.

Oct 20: The PHP team pre-announces a “critical security release.” Details are withheld, but reports say they leaked before release
Oct 21: Japan’s IPA (its national IT security agency) asks site operators to “prepare in advance,” warning attackers could strike “within an extremely short time”
Oct 21, afternoon: E-commerce platform BASE and childcare service Codmon (all services, including the parent app) go into maintenance. Xserver, one of Japan’s largest web hosts, suspends access to its control panels as a precaution (sites and email keep running)
After 8 p.m.: Uma Musume, Granblue Fantasy, Shadowverse, niconico, pixiv, DMM and more pause or enter emergency maintenance
9:55 p.m.: Prime Minister Takaichi’s “urgent request” on X
10:00 p.m.: Online-shop service Color Me Shop takes down shop pages and its admin panel
10:30 p.m.: Even the official site of the band Sakanaction goes offline, “following the announcement of a PHP vulnerability”
11:00 p.m.: PHP releases the fix
Early Oct 22: pixiv and others come back. Codmon resumes at 3:22 a.m. (minus one feature)

Some banks, a railway company and local government systems reportedly paused services too. Not every shutdown was officially attributed to PHP — many just said “emergency maintenance.”

Why go that far?

Because the moment a patch ships is the most dangerous moment.

A patch also reveals what was fixed, which hands attackers a map. And this time, details had reportedly leaked before the release.

The bugs themselves are nasty:


CVEs	CVE-2026-109618, CVE-2026-109619
Severity	Both CVSS v4.0 9.2 (Critical)
Risk	Running code on your server without logging in
Where	Not in apps like WordPress — in PHP itself

Clean application code doesn’t help. If your PHP is outdated, you’re exposed. Per the official PHP announcement, Apache mod_php setups are at highest risk.

And the scale is huge: Palo Alto Networks (Unit 42) counted over 22.6 million potentially vulnerable instances. One European government reportedly took its website down as a precaution.

So Japanese services decided: close the doors until the patch is in. Losing a night of traffic is cheaper than getting breached. As a developer, I think that was a pretty sound call.

For the record, the US agency CISA said on October 21 that it had “not observed exploitation,” and Codmon said no unauthorized access or data leak was confirmed. They shut the door before anyone got in.

The flaws were reported by researchers from Wiz, Calif and OpenAI, and reports say AI was used to find them. One AI-found bug, one country’s services dark for a night.

Green apple character holding a shield

Meanwhile in Korea

I live in Korea, so I checked here too. KISA (Korea’s internet security agency) issued an advisory on October 21. Cafe24, Korea’s largest web host, acted in three steps that day: a temporary setting change in the morning, tighter php.ini limits in the evening, and the official patch late at night — for PHP 8.2+ servers only. It stated plainly that 8.1 and older were not covered. Gabia patched its PHP hosting between midnight and 3 a.m. on October 22.

As far as I could find, Korea didn’t see the same wave of big-name shutdowns.

So, what about your site?

PHP2Shell decision flow. On shared hosting, check your PHP version: 8.2+ means confirm your host patched it, 8.1 or older means upgrade. On a VPS or your own server, update and restart yourself

Your branch	Safe from this version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 or older (incl. 7.x)	No official fix → upgrade to 8.2+

1. Check your PHP version

On WordPress:

Tools → Site Health → Info tab → Server → PHP version

Green apple character peering at a PHP version on screen with a magnifying glass

Not on WordPress? Your hosting control panel or support can tell you.

2. Shared hosting + PHP 8.2 or newer

Your host patches it. Just confirm in their announcements.

3. PHP 8.1 or older ← the real problem

There is no official fix. Your host can’t patch what doesn’t exist — that’s exactly why Cafe24 left 8.1 out. Upgrading is the only way.

Upgrading can break old plugins or themes, so go in this order:

Back up
Update plugins and themes
Switch PHP version

One more thing: PHP 8.2 reaches end of security support on December 31, 2026. If you’re upgrading anyway, go to 8.3+. Unless you want to do this again in two months.

4. Installed PHP yourself (VPS / cloud)?

Nobody’s doing it for you.

Update your OS packages, then restart PHP-FPM or Apache
php -v in the terminal shows the CLI version — your web server may be running a different PHP. Check the web side too (e.g., a phpinfo page — delete it afterward)
The official PHP announcement lists temporary settings if you can’t update yet, but says itself they’re not a complete fix. Update first

FAQ

Isn’t updating WordPress enough?

No. The bug is in PHP itself, underneath WordPress. Check your PHP version regardless.

Are static (HTML-only) sites at risk?

If PHP isn’t handling web requests, this doesn’t apply. This blog is a static site with no PHP, so it wasn’t affected.

Summary

PHP2Shell = two flaws in PHP core, unauthenticated remote code execution, severity 9.2
On the night of Oct 21, major Japanese services went dark as a precaution — and the Prime Minister posted an “urgent request”
Fixed in 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
Shared hosting + 8.2+ → your host handles it
PHP 8.1 or older → no official fix; upgrade to 8.2+ (ideally 8.3+)

Sources

Checked October 22, 2026.

Official

Coverage