Why Japanese websites went dark over PHP2Shell: AI finds flaws at machine speed, people fix them at human speed

Introduction#

On October 21, 2026, government agencies, railway companies, e-commerce services and others in Japan took their websites and services offline one after another. Most of these appear to have been precautions against two critical vulnerabilities (flaws in software that attackers can exploit) found in the PHP programming language itself, nicknamed "PHP2Shell." Prime Minister Sanae Takaichi also posted on X what she called "an extremely urgent request to act tonight," asking organizations to be ready to apply the fixed versions quickly. Where that was difficult, she said, temporarily taking a website offline was "one effective way to reduce the risk."

The incident has mostly been reported as "vulnerabilities found by AI." As someone who builds AI systems, what caught my attention was what happened after they were found.

My argument is this. What AI has sped up is finding vulnerabilities and reconstructing attacks from clues. Deciding how to fix them, and getting every organization to apply the fix to its own servers, still move at human and organizational speed. On October 21, many Japanese organizations had no way to close that gap except by shutting down. What follows is based on information published as of October 25, 2026 (quotations are my own translations and may not match the original wording).

If you only want the countermeasures, skip to "7. Narrowing the speed gap."

Summary#

• Finding: Three organizations independently reached the same problem through AI-assisted research. One company is said to have rediscovered it on its own, using an advance warning as a clue.
• Fixing: In 2024 a PHP developer had already noticed signs of one of the two flaws, but no concrete attack method was found at the time, and the security team then spent months unable to settle on how to fix it.
• Applying: In Japan, for about 23 hours between the CVE numbers circulating and the fixed versions coming out, most organizations had nothing to apply. Even after the fix was out, reopening services and applying the fix took anywhere from a little over an hour to more than half a day, and many sites still run on old, unsupported versions of PHP.
• What to do: Know who applies fixes for you, decide in advance when to shut down, write fix deadlines into your maintenance contracts, and change your passwords and API keys.

1. What happened on October 21#

PHP2Shell consists of two bugs in PHP's internals. Their identifiers in the worldwide vulnerability catalog (CVE numbers) are CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 out of 10 on the common severity scale. An outside party could run arbitrary programs on a server without logging in, and according to PHP's advisory, the second flaw could also leak the contents of memory.

PHP that handles web requests is affected no matter how it is run, and PHP says that "updating is the only safe option." According to Google Cloud, a wide range of versions from PHP 5.4 onward is affected. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; earlier versions in each of those branches are affected. On October 23, a related vulnerability (CVE-2026-115560) was disclosed that affects even the fixed versions under certain settings. It is scheduled to be fixed in the next regular release (see "Notes for technical staff" in section 7).

The main events were as follows (times are Japan time; Amazon's observation date is as given in its report).

Below, I break this sequence into four steps: (1) finding the flaw, (2) building an attack, (3) deciding how to fix it and producing the fixed versions, and (4) each organization applying the fix.

2. Finding: AI made searching and retracing cheap#

Calif's research was part of "Patch the Planet," an initiative OpenAI launched in June 2026 to examine important open-source software with AI. According to OpenAI, Calif found the critical flaws using the company's "GPT-5.6 Sol" model. Calif says it used only publicly available models and no special tools. According to the PHP Foundation, OpenAI itself also independently reported the same root cause (the report date has not been disclosed). Wiz says it found the flaws on August 19 using its own tools, Google's "Gemini 4 Argon" and GPT-5.6 Sol, and reported them on the 24th (OpenAI describes this as an independent discovery too).

From where I sit, building AI agents, it is clear why vulnerability hunting suits AI. Whether a given input makes an attack succeed can be checked immediately by trying it. Work whose answers can be checked automatically gets faster, and runs in parallel, the more computers you add.

That speed also helps when retracing a problem someone else has found. Chainguard published its full set of patched software more than six hours ahead of schedule. Its CEO is reported to have said that, after receiving a warning the previous Friday, the company reached the vulnerability on its own using frontier AI models and other tools. Chainguard says it published early because it judged that attacks had begun; the PHP Foundation criticized it for undermining the coordinated disclosure. What the warning said is unknown, but I see this as an example of how, given a clue, a vulnerability can sometimes be reached in a short time. Amazon also points out that AI-assisted analysis has lowered the cost of building exploit code from fixes and security advisories.

This time, human slip-ups were added on top: the leak of the CVE numbers and the mistaken publication of an attack video. According to the PHP Foundation, Calif published the video by mistake (copies spread even after it was deleted), and this was one reason exploit development sped up. Now that reconstruction has become cheap, I think slip-ups like these cost more than they used to.

That does not mean AI alone can find anything. Calif says that "at least for now" no model can dig up "all the bugs" from a simple instruction. It points to its decision to focus on PHP, a target whose history of vulnerabilities it knew well, and says that "knowing the target" still matters. Even so, OpenAI expects similar discoveries to surge over the coming months.

3. Fixing: what stalled was the decision#

According to the PHP Foundation, signs of one of the two flaws, the problem in handling out-of-memory conditions, were caught in 2024. A developer under contract with the foundation noticed it while fixing a different problem pointed out in an external audit. At the time, though, while exploitation was flagged as theoretically possible, no concrete attack method was found, and other problems with clearer impact took priority.

Several candidate fixes were written, but each had drawbacks: one broke compatibility with existing sites, one opened new room for attacks that take sites down, and one forced changes on the many extensions bolted onto PHP. The security team, which decides by consensus, could not pick one, and the work stopped and restarted over several months. The PHP Foundation calls the delay a "structural failure" and acknowledges that its decision-making process and a lack of resources were to blame.

After the August 11 report, the fix became the top priority, and several developers worked on it full time. It took about ten weeks to release the fixed versions. Including the step of handing the fix to distributors and others in advance, that is within the 90-day guideline commonly used for coordinated disclosure, and I consider it a standard timeline for a fix of this size.

Two points strike me as important. The first is that, unlike finding a flaw, deciding how to fix it has no right answer you can verify by trying it. The PHP Foundation also writes that what tools cannot do is "decide the right fix for long-standing design decisions in the engine." The foundation uses AI to verify reports and the like, but it says people make every decision.

The second is that the fix was postponed in 2024 because "no concrete attack method had been found." In 2026, AI-assisted research found that very attack method. Thanks to AI, the judgment "there's no attack yet, so it can wait" is becoming harder to defend. The same applies to companies that keep running old PHP "because nothing has gone wrong so far."

The more flaws are found, the heavier the load on the people who decide. The PHP Foundation says it has published 15 CVEs since July and handled more than 100 reports that turned out to be invalid, duplicates and so on. The foundation is reworking its decision-making and adding staff, and it is asking companies, governments and others that depend on PHP for financial support.

4. Applying: Japanese organizations bought time by shutting down#

Before the fix: there was nothing to apply#

What Japanese organizations faced on October 21 was not a problem of being slow to apply a fix. For about 23 hours, from around midnight when the CVE numbers circulated until around 11 p.m. when the fixed versions came out, most organizations had no fixed version to apply at all. Even counting from around 11 a.m., when what Amazon says was the first exploit code (PoC) appeared, that is about 12 hours (the PHP Foundation says it had not confirmed any working exploit code at the time of release).

The one reliable move during this window was to shut down. The security blog "piyolog" lists 246 organizations, confirmed from their own notices, that took services or sites offline or announced emergency maintenance (as of the 25th; the list includes organizations whose notices did not mention PHP, some of which the press reported as responding to PHP). BASE went offline from 3:50 p.m., and the Ministry of Health, Labour and Welfare's long-term care service information system from 4 p.m. (the latter's notice cited "emergency vulnerability response"). According to press reports, the shutdowns also reached some services at regional banks and securities firms.

This was not a uniquely Japanese reaction. In the Netherlands, the National Cyber Security Centre (NCSC) was reported to have temporarily taken its own website offline as a precaution, with government portals and others following. Japan's IPA (Information-technology Promotion Agency) also asked organizations, in its October 22 alert, to decide whether blocking outside access or temporarily suspending services was necessary when effective interim measures were difficult. On the 23rd, the NCSC said exploitation was complex and large-scale exploitation was less likely than first thought. But that became clear only after the fixed versions were out. I think the decision to shut down as of the 21st was reasonable. At the same time, the fact that many organizations had to make that call in the few hours before the release shows how much it matters to set your criteria for shutting down in advance.

After the fix: a little over an hour to more than half a day#

Once the fixed versions were out, how fast organizations moved varied. Chatwork ran emergency maintenance from around 11 p.m. on the 21st and finished around 12:15 a.m. on the 22nd. CoDMON reopened its services, except for some features, at 3:22 a.m., saying it had finished applying the fix and checking safety. Xserver says it began applying the fix at 1:10 a.m. on the 22nd and finished applying it to all affected servers running PHP 8.2 to 8.5 at 6:45 a.m. (7.4 to 8.1 were done at noon, and 5.6 to 7.3 at 2 p.m.). For this provider, which runs a large number of servers, that means about 8 hours from the release just to cover the supported versions, and about 15 hours including the older ones.

The sites left behind#

The real problem is the sites left outside all this. GMO Prime Strategy surveyed the official, group and affiliated websites of 3,941 companies listed on the Tokyo Stock Exchange (about 25,000 sites) in April and published the results in June 2026. Of the 2,654 sites whose PHP version could be identified from outside, 70.1% were running a version that was no longer supported. The same survey found that about a week after a WordPress fix was released, 17.7% of sites on the supported 6.x line had not applied the latest minor update.

Worldwide, too, W3Techs' figures as of October 25 show that among sites using PHP, 26.8% run PHP 7 and 7.7% run PHP 5. Adding the unsupported PHP 8.0 and 8.1, about half (about 48% by my estimate) run unsupported versions. Support for PHP 8.2 also ends on December 31. This time a minimal fix was published for 7.4 to 8.1 as well, but there are no regular fixed versions for them, so you either build it in yourself or wait for your distributor or provider.

Attacks and patching also move in different units of time. Among the high-severity vulnerabilities that Rapid7 newly confirmed as exploited in July to September 2026 (43 of them), exploitation followed public disclosure by three days on average. Meanwhile, according to data Trend Micro collected from environments using its products, Japanese organizations took 27.5 days on average to apply patches (February to December 2024), the second fastest region after Europe. In the company's figures for the first half of 2024, the average was 36.4 days, said to be the longest of any region, so the ranking depends on the dataset. The targets and methods differ, so the numbers cannot be compared directly, but attacks move in days while patching moves in weeks. I see this less as a Japan-specific problem than as a structural one.

How fast a fix is applied also depends on whom you have outsourced to. Some organizations said they would wait for their server company to finish before reopening (according to the Web Security Diagnosis Center's roundup).

5. The speed gap in summary#

Steps (1) finding and (2) building an attack have become fast and cheap thanks to AI. Steps (3) deciding the fix and (4) each organization applying it still move at human and organizational speed. Attack attempts move at the speed of step 2 and get going before the fixed versions. Figure 4 lays out the events of October 21 in three tracks.

Of the roughly 23 hours without a fix, about 12 were hours in which what was said to be exploit code (PoC) was already circulating. Unless this gap is closed, I think nights like October 21 will happen again.

6. Common questions#

Q1. Was AI used in the attacks this time?

A. Public information does not let us say for sure. According to The Record in the US, watchTowr said it was observing attack attempts using PoC tools built with the help of AI, but also said that as of the 21st "no one has succeeded yet." In Rapid7's report for July to September 2026, too, only 8% of threat reports cited AI as an operational factor, and in the recorded cases it was people who chose the targets and goals. AI use on the attacking side this time is suggested but unconfirmed.

Q2. If AI found the flaws before attackers did, doesn't that give defenders the advantage?

A. OpenAI says that "to the best of our knowledge, frontier AI found these vulnerabilities before attackers," but no third party has verified this. And at least for the problem in handling out-of-memory conditions, the first signs were caught in 2024 by a human developer. The roughly ten weeks of lead time defenders gained went into preparing the fix, and in the end, partly because information leaked before release, the release was brought forward by a day. Whether that lead time pays off depends on how fast fixes are made and applied.

Q3. Has there been any damage in Japan?

A. According to the Web Security Diagnosis Center's roundup (as of the 25th), no organization in Japan has announced damage that it attributes to PHP2Shell. The Dutch NCSC also said on the 23rd that it knew of one report outside the Netherlands suggesting possible exploitation, but that no successful attack had been confirmed. Some of the organizations that shut down, such as CoDMON, also said at the time of their notices that they had found no unauthorized access or data leaks. Valtec, which announced on the 22nd that it had suffered unauthorized access through a "cyberattack targeting the PHP vulnerability," later corrected this as a "false report" and explained that a vulnerability in its own service had been exploited. And because reading memory contents is thought to leave few traces, "not confirmed" does not necessarily mean "did not happen."

7. Narrowing the speed gap#

Companies cannot change how fast flaws are found (step 1) or how fast attacks are built (step 2). What they can change is how fast they apply fixes (step 4), and how prepared they are for when step 4 cannot keep up.

To do this week (no dedicated staff needed)#

1. List your company's websites and systems (including booking, e-commerce and business systems) and write one line for each on who manages it (a hosting company, a web agency, a cloud service, or you)
2. If you run WordPress on a rental server, check your provider's notices and check your PHP version under Tools → Site Health → Info → Server in WordPress. If it is 8.1 or earlier, back up and update WordPress and your plugins before switching (support for 8.2 also ends on December 31)
3. If a web agency or cloud service handles it for you, ask them using the message below
4. Change the passwords for your admin screens and databases and the API keys for outside services such as generative AI (strings that work like a duplicate key for using those services), and set a spending cap on your API keys

Sample inquiry:

Subject: Request for the status of your response to the PHP vulnerabilities (disclosed October 21)
Please tell us the status of your response to the PHP vulnerabilities disclosed on October 21 (CVE-2026-109618 and CVE-2026-109619) for the 〇〇 service we use.
1. Does 〇〇 use PHP? If so, which version?
2. When did you finish applying the fixed version? (If not yet, when do you plan to?)
3. Have you investigated unauthorized access since October 17 and changed passwords, API keys and other credentials?

To decide this month (for the next emergency)#

5. Set three levels for shutting down: shut everything down / shut down only the parts that handle personal information (such as contact forms and member logins) / keep watching. Also decide who makes the call and who stands in for them
6. Put on one page your after-hours and holiday contacts (your server company's and web agency's emergency lines) and the sources you will check (IPA, JPCERT/CC, your providers' status pages)
7. Write into your maintenance contracts that "fixes for urgent vulnerabilities will be applied and reported within ○ hours"
8. Consider a WAF (a system that stops traffic that looks like an attack before it reaches your site) to buy time until a fix comes out. This time, Cloudflare automatically applied protective rules for its WAF users, including those on the free plan, from around noon on the 21st, before the fixed versions were released (it is not a complete defense, though, and you still need to update PHP)

Notes for technical staff#

• Restart your PHP workers after applying the fixed version
• Check your logs, at least from October 17 onward, for POST requests containing "PHP_SESSION_UPLOAD_PROGRESS," suspicious processes started by the web server, and changed files (as recommended by Amazon and Huntress)
• Because a leak of memory contents is thought to leave few traces on disk, consider rotating database credentials, API keys, framework session secrets and cloud credentials
• After applying the fixed version, if your application switches the session serialization format (session.serialize_handler) at runtime, set session.upload_progress.enabled to 0 until the next regular release (this addresses the related vulnerability CVE-2026-115560 disclosed on October 23, which also affects the fixed versions)
• Temporary configuration changes alone (changing memory_limit or session.upload_progress.enabled) do not make you safe from PHP2Shell. Consider disconnecting environments that cannot be patched from outside access

For individuals#

The main responders this time are the businesses that run websites. If you are a general user, keep the following in mind.

• If you are asked to change a password or the like, do it from the official app or website, not from a link in an email (watch out for fake emails posing as services)
• If you reuse the same password, take this chance to use different ones
• If you run your own blog or website, check item 2 of "To do this week"

Closing#

PHP2Shell is being reported as a case of "AI finding vulnerabilities." But what happened in Japan on October 21 showed how much the steps after discovery are bound by the speed of people and organizations. Discoveries by AI will keep growing, and most of them are good news for defenders. Still, a problem that has been found becomes protection only once it has been fixed and the fix has been applied.

The target is AI itself rather than web servers, but at Elith, where I work, we too offer AI security services that combine red teaming, which uncovers weaknesses in AI systems with inputs that simulate attacks, with guardrails that control the inputs and outputs of AI in production, as well as the AI safety platform "GENFLUX." Protecting AI likewise means treating finding, fixing and applying as one continuous job rather than stopping at discovery.

The next time a night like this comes, who decides to shut down, whom do you ask for the fix, and what do you check? I recommend writing it down on a single sheet of paper while the memory is still fresh.

References#

• The PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026年10月21日）
• PHP「News Archive 2026」（2026年10月20〜23日の告知・修正版・勧告）
• PHP「Security advisory GHSA-6wmf-4rv5-p3rp」
• PHP「Supported Versions」
• Tenable「php2shell (CVE-2026-109618, CVE-2026-109619) FAQ」
• Google Cloud「Responding to core PHP vulnerabilities」
• Amazon Threat Intelligence「PHP2Shell exploitation prior to public disclosure in MadPot」
• Huntress「php2shell, Leaked Critical PHP Vulnerabilities」
• Socket「PHP Foundation Says Chainguard Broke Security Embargo」
• Wiz「PHP2Shell」（2026年10月21日）
• Calif「PHP2Shell」（2026年10月21日）
• OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」（2026年10月21日）
• OpenAI「Patch the Planet」（2026年6月22日）
• ITmedia NEWS「PHPの「重大」脆弱性はAIが見つけた」
• ITmedia NEWS「高市総理「大至急、PHPパッチ適用を」Xで異例の要請」
• The Record「Hundreds of websites taken offline」
• ロイター（KSL掲載）「Cyber agency warns websites may go dark as PHP prepares critical fix」
• Cloudflare「Cloudflare deploys protections against php2shell vulnerability」（2026年10月21日、23日更新）
• ASCII.jp「PHPの脆弱性を狙う攻撃、数百万件に急増」
• IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日）
• NCSC（オランダ）「Update: PHP vulnerabilities remain a reason for immediate patching」（2026年10月23日）
• piyolog「修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた」
• Webセキュリティ診断センター「PHP脆弱性で停止・メンテ中の国内サービス一覧」
• エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」（2026年10月22日）
• コドモン「サービス再開のお知らせ」（2026年10月22日）
• バルテック「不正アクセスによるお客様情報流出の可能性および一部サービス停止のお知らせ」（2026年10月22日、23日訂正）
• GMOインターネットグループ（GMOプライム・ストラテジー）東証上場企業Webサイト調査（2026年6月24日）
• W3Techs「Usage statistics of PHP」
• Rapid7「Q3 2026 Threat Update」
• トレンドマイクロ「年間サイバーリスクレポート2025年版」（2025年4月16日）
• Safeguard「After PHP2Shell: how to check if your server was already compromised」
• トレンドマイクロ「世界サイバーリスクレポート2024年版」（2024年11月13日）