Japan's PHP crisis shows why the language still runs the internet

When a language nobody talks about breaks everything

Start your typical English-language tech newsletter and you will hear almost nothing about PHP. It is treated as legacy code — something the grandparents of the internet run on. Then a Tuesday hits and half of Japan’s consumer-facing digital services go dark to patch it.

That is what occurred over the weekend. Multiple high-profile Japanese platforms, including the preschool management SaaS Kodomon, the social card game Shadowverse: Worlds Beyond, the rental server provider Sakura, and the e-commerce builder BASE, all entered emergency maintenance following the disclosure of two critical vulnerabilities in PHP. X Server, the online auction service pictSQUARE, the recycling marketplace Kinburu, and the crowdsourcing platform Tsunagu were all expected to follow the same path. Several of these confirmations came through company statements and ITmedia News reporting.

For an outside reader, this looks like a routine security incident. It is not. It is a stress test of an assumption that Western tech media carries around without ever stating out loud: PHP is already dead.

It is not dead. It is invisible, and invisibility is dangerous.

The numbers behind the disruption

According to W3Techs, approximately 70 percent of websites with a identifiable server-side language still run PHP. That figure includes WordPress, which powers roughly 43 percent of all websites globally. The two vulnerabilities at the center of this incident both score a 9.2 on the CVSS v4.0 scale. Anything above 9.0 is classified as Critical — the same tier occupied by the Log4Shell exploit that shook the Java ecosystem in 2021, or the MOVEit transfer flaw that crippled governments and corporations in 2023.

The PHP development team scheduled a security update for 11 p.m. on the 21st, at which point they will publish the full technical details, the affected versions, and the patched builds. They are also urging all PHP users to prepare in advance so they can deploy the fix immediately once it is available. Japan’s National Cybersecurity Strategy Headquarters issued a parallel call for rapid response.

The timing is notable. Emergency maintenance across dozens of independent companies on the same day suggests coordinated urgency rather than organic discovery. That typically means the vulnerability information was shared through a coordinated disclosure process before the public patch dropped — a scenario where the window between awareness and exploit is razor-thin.

What Western readers miss about this moment

There are at least three things that get lost when this story crosses the Pacific.

First, the density of PHP in Japan’s digital infrastructure is higher than the global average in several sectors. Shadowverse: Worlds Beyond alone operates on infrastructure that depends heavily on PHP-backed backend services. BASE, which serves as the primary storefront platform for hundreds of thousands of small Japanese sellers, runs on PHP. Sakura and X Server are rental hosting providers — the kind of company that hosts not one but thousands of smaller sites, many of them running unpatched PHP installations. When these providers pause operations for maintenance, they do not just affect their own users. They affect every site they host that has not already applied a patch or moved off PHP entirely.

Second, the word “emergency maintenance” means something different in Japan than it does in Silicon Valley. It is not a placeholder for “we will ship a hotfix next sprint.” It is a visible, coordinated shutdown that customers see as a status page and a push notification. For Kodomon users — parents and administrators relying on a scheduling and communication tool for childcare centers — that downtime has a human texture that a purely technical article cannot convey.

Third, the global ripple effects are real but poorly understood. Every WordPress site running on a server provided by Sakura, X Server, or any of the other affected hosting companies shares the same attack surface. If a given instance has not been updated since PHP 8.2 or earlier, it is exposed. A botnet operator scanning the internet does not care about national boundaries. The same vulnerability that knocks out a Japanese e-commerce platform is available to anyone who knows how to script an exploit.

Who wins, who loses, and what happens next

The winners in this scenario are the organizations that already ran PHP inventory audits and automated patch pipelines. For most small businesses and individual developers, the answer is nobody. They simply hope they are on a patched version and did not miss the announcement.

The losers are the services that were forced offline and the users who lost access to tools they depend on — whether that is a game account, a storefront, or a childcare management system. The longer-term loser is the public perception that PHP is a solved problem. It is not. It is a live wire sitting inside the plumbing of the modern internet, and the fact that most people cannot see it does not make it safe.

What happens next is predictable. The patch will drop. Most responsible operators will apply it within hours. A significant minority will not — either because they are running legacy applications that cannot tolerate the upgrade, or because they are simply unaware they are on PHP at all. Those orphan instances will remain exposed until the next wave of exploitation or the next emergency.

The deeper lesson is that the tech industry’s ongoing love affair with rewriting infrastructure in modern languages coexists uneasily with a deployment reality where PHP still runs the majority of the web. Until that gap closes — and there is no signal it will close soon — incidents like this weekend’s will remain the new normal. Not because the vulnerabilities are unusual. Because the dependency is invisible, and that invisibility makes the next outage easier to trigger than anyone wants to admit.