# Why Did Prime Minister Takaichi Ask Everyone to Act Tonight? PHP2Shell Explained

> PHP, the backend language powering most of the web, has two critical vulnerabilities that could let attackers run arbitrary code on a server without logging in. Affected versions trace back fourteen years. Researchers used AI to find them; word of the flaws leaked before the patch was out, and Cloudflare observed hundreds of thousands of exploitation attempts within two hours of disclosure. Here is a plain-language account of what happened, why Japan's Prime Minister spoke up, and what you need to do.

- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-22
- Pillar: Intelligence & Order
- Tags: PHP2Shell, PHP Vulnerability, AI Security, Vulnerability Disclosure, Sanae Takaichi, WordPress, Cloudflare
- Canonical: https://paulkuo.tw/en/articles/php2shell-patch-tonight/
- Language: English
- Translation: AI-translated from the zh-Hant (Traditional Chinese) original
- Original (zh-Hant): https://paulkuo.tw/articles/php2shell-patch-tonight.md
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

> **TL;DR:** PHP powers most of the web's backend. Researchers using AI found two serious vulnerabilities inside it, with affected versions stretching back fourteen years. An attacker needs no login to potentially run arbitrary code on a server. Details leaked before the patch was ready, exploitation attempts were already underway, and Japan's Prime Minister Sanae Takaichi posted on X asking everyone to act that evening, noting that a temporary shutdown was one option if a patch couldn't be applied in time. Ordinary users don't need to panic. If you run a website, confirm that the PHP on your server has been updated.

> 皆様に、今夜に対応して頂きたい大至急のお願いです。
>
> 多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。
>
> 公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。
>
> 修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。
>
> 国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。
> 国家サイバー統括室(注意・警戒情報)（[@cyber_forecast](https://x.com/cyber_forecast)） / X

> There is something extremely urgent I would like to ask everyone to address tonight.
>
> Regarding PHP, which is used by many websites, the PHP security team has issued an alert about two critical vulnerabilities.
>
> Please check whether any of your publicly accessible websites use PHP, and prepare so that the patch to be published tonight, October 21 at 11 p.m. Japan time, can be applied as quickly as possible.
>
> For those who find it difficult to apply the patch promptly, temporarily taking a website or similar service offline is one valid measure for reducing risk.
>
> The National Cybersecurity Office is also publishing relevant information on its X account; please refer to that as well.
> National Cybersecurity Office (Alerts and Warnings) ([@cyber_forecast](https://x.com/cyber_forecast)) / X

The text above is the full post that Japan's Prime Minister Sanae Takaichi published on [X](https://x.com/takaichi_sanae/status/2112890642590564386) at 9:55 p.m. Japan time on October 21, 2026 (8:55 p.m. Taiwan time).

At 1:30 p.m. Taiwan time on October 22, I was scrolling the X recommendations feed when I came across that post. The platform had auto-translated it into Chinese. The timestamp showed it had been live for sixteen hours; the like count stood at 320,000.

A sitting prime minister using her personal account to ask the public to address a single programming-language vulnerability the same night is not a common sight. Japanese tech outlet [ITmedia](https://www.itmedia.co.jp/news/article/2610/22/2000002483/) noted that a prime minister speaking directly on X about a specific software vulnerability was unusual.

I forwarded the screenshot to an AI, asked it to first check whether the sites I manage were affected, then trace the whole story from the beginning. This piece is that trace, written for people who don't code but spend their days online.

## What Is PHP2Shell, and Why Could Two Vulnerabilities Shut Down Websites Across Multiple Countries?

PHP2Shell names two vulnerabilities in PHP: CVE-2026-109618 and CVE-2026-109619. No account or password is required. An attacker needs only to send a specially crafted request to a website, and execution of arbitrary code on that site's server becomes possible.

PHP is a programming language for building websites. Many of the blogs you read and the online shops you order from run on PHP underneath. WordPress is the most familiar example. According to [W3Techs](https://w3techs.com/technologies/details/pl-php), among websites whose backend language can be identified, 69.3 percent use PHP.

The name breaks down simply: from PHP, you get a shell. A shell is the command window of a server. With it, an attacker can issue instructions to that machine under the identity of the web application. How much damage that allows depends on what permissions the application has been granted.

Both vulnerabilities received a severity score of 9.2 out of 10 from the PHP team. Security researcher Kevin Beaumont described them as among the most significant vulnerabilities of recent years, predicting a large wave of security incidents.

According to [Wiz](https://www.wiz.io/blog/php2shell-php-rce) and [Calif](https://calif.io/php2shell/), the earliest version researchers found to be affected is PHP 5.4 from 2012, and the problem runs through every version up to 8.5.11. Every version in that span is affected by at least one of the two vulnerabilities. The oldest of these issues had been present in PHP for at least fourteen years.

## How Do the Two Vulnerabilities Work? A Restaurant Kitchen Analogy

Think of a website as a restaurant. You click a button on a webpage and you are handing in an order slip. PHP is the kitchen: it reads the slip and produces the page you see. Each order is handled on a single workstation, cleared when done, and the workstation is ready for the next ticket.

The first vulnerability appears when a job runs out of ingredients mid-task. When PHP processes a request and runs out of memory, it is forced to abort, and some data ends up only partially written. The cleanup routine then treats that incomplete data as if it were valid and processes it accordingly. An attacker can deliberately trigger this abort and arrange for the cleanup routine to follow their doctored half-ticket.

The second vulnerability appears when the previous ticket wasn't fully cleared. After a request is handled, that block of memory is released, but PHP retains a pointer to it. When the same workstation takes the next order, it reaches back to that stale pointer. Researchers exploited this gap to achieve remote code execution.

Researchers also demonstrated that this combination of vulnerabilities can be used to read residual contents from server memory, which may include passwords, session credentials, and API keys (see [Qualys's writeup](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities)).

The [official PHP announcement](https://www.php.net/archive/2026.php#2026-10-21-5) notes that under an Apache and mod_php setup, an attack can be triggered before the web application's own code even begins to execute. PHP lists this configuration as the highest-risk deployment. It means that no matter how carefully a site's application code was written, the problem lies in the kitchen equipment itself.

![Four-panel comic: Why Did Prime Minister Takaichi Ask Everyone to Act Tonight? PHP2Shell Explained; Think of a website as a restaurant. You click a button on a webpage and you are handing in an order slip. PHP is the kitchen: it reads the slip and produces the page you see. Each order is handled on a single workstation, cleared when done, and the workstation is ready for the next ticket. The first vulnerability appears when a job runs out of ingredients mid-task. the problem lies in the kitchen equipment itself.](/images/articles/php2shell-patch-tonight/02-kitchen-en.svg)

## How Did AI Find Vulnerabilities That Had Been Hiding in PHP for Years?

On August 11, security testing firm Calif and OpenAI independently reported the same underlying issue to PHP on the same day. Calif was participating in OpenAI's "Patch the Planet" program, using the GPT-5.6 Sol model. On August 24, Google's security subsidiary Wiz independently reported it as well, using their AI agent Wiz Atlas together with [Gemini 4 Argon](/en/articles/gemini-4-argon-dashboard-admission/) and GPT-5.6 Sol (sources: [PHP Foundation statement](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/), [TechCrunch](https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/)).

All parties followed responsible disclosure: notify the PHP team privately, give them time to prepare a patch, then agree on a release date at which both the fix and the vulnerability details become public simultaneously. The original target was 14:00 UTC on October 22. According to [Fortune](https://fortune.com/2026/10/21/ai-tools-discovered-the-php-vulnerability-that-could-take-down-70-of-the-internet-now-the-race-is-on-to-patch-it-before-ai-powered-hackers-attack/), OpenAI brought in Cloudflare and several US government agencies in the lead-up to publication.

The vulnerability was not entirely unexamined territory. The PHP Foundation noted that as early as 2024, a core developer working under a Foundation commission had spotted early signs of the out-of-memory condition underlying the first vulnerability. Someone had speculated it might be exploitable, but no concrete attack path was found. Several remediation approaches were explored, each with tradeoffs, and work stalled and restarted over several months. The Foundation acknowledged that "the delay was a structural failure, caused by both the security team's decision process and its lack of resources." The August reports clarified the severity, and patching became the top priority.

Converting a vulnerability into a working exploit that holds across different versions and configurations has traditionally required considerable expertise. Wiz wrote on their blog that frontier AI models have significantly lowered that barrier, turning a bug that had existed for years into a working exploit. OpenAI made the same point: the same capability that finds vulnerabilities also helps attackers build exploit tools faster.

## The Patch Wasn't Out, but the Attacks Arrived First: Leaks and a Race Measured in Hours

The information seal didn't hold. On October 20, someone posted to the tech forum Hacker News, naming both CVE numbers and claiming a maximum severity score. The post was later deleted, but security firms quickly confirmed both vulnerabilities were real ([Infosecurity Magazine](https://www.infosecurity-magazine.com/news/critical-php-vulnerabilities-leaked/)). The [PHP Foundation later clarified](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) that what leaked were the identifiers, accompanied by an incorrect release time and an incorrect score (the official score is 9.2); the technical details did not leak at that stage. After that post appeared, the PHP team moved the release date forward by one day, to 14:00 UTC on October 21, which is 10:00 p.m. Taiwan time and 11:00 p.m. Japan time.

Two more leaks followed. A few hours after the Hacker News post, Calif accidentally made a demonstration video public; it showed their proof-of-concept working against multiple targets, and revealed some limited additional details. Then, on the afternoon of October 21 (Taiwan time), security vendor Chainguard published a patched build ahead of the agreed embargo. From that point, the Foundation said, attackers could analyze the patch's contents while every other PHP user was still waiting for the official release.

Amazon's honeypot infrastructure had already picked up something earlier. Amazon operates a fleet of decoy servers called MadPot, designed specifically to attract attackers. [According to Amazon's report](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/), MadPot logged a single exploitation attempt against this vulnerability on October 17, four days before public disclosure. How that actor obtained advance knowledge remains unclear. Amazon also recorded multiple proof-of-concept tools appearing around 10:00 a.m. Taiwan time on October 21, twelve hours before official publication, though Amazon noted it could not yet confirm whether those attempts would succeed against real production systems. The PHP team stated that at the time of publication, no confirmed working exploit had been verified.

Cloudflare CEO Matthew Prince [posted on X](https://x.com/eastdakota/status/2113079352682570051) with what their network was seeing: in the ten hours before disclosure, a few thousand attempts; forty-five minutes after publication, tens of thousands; within two hours, hundreds of thousands; by the time he wrote, millions.

Amazon's report contained one sentence worth holding onto: "An embargo protects defenders only until someone else finds the same bug." Their recommendation: for critical vulnerabilities on public-facing systems, measure patch and mitigation timelines in hours.

![Timeline: Researchers traced the earliest affected version to PHP 5.4, released in 2012, meaning the problem had existed for at least fourteen years. In August 2026, researchers using AI discovered and reported the vulnerabilities. On October 17, Amazon's MadPot honeypot recorded an exploitation attempt, four days before public disclosure. On October 20, the CVE identifiers leaked. On October 21 at 10:00 p.m. Taiwan time, the patch was published. Within two hours, Cloudflare observed hundreds of thousands of exploitation attempts. The decisive question in security has shifted from who finds a vulnerability first to who fixes it first.](/images/articles/php2shell-patch-tonight/01-timeline-en.svg)

> **Key figures**
> - **Affected versions:** PHP 5.4 through 8.5.11, as traced by researchers (every version is affected by at least one vulnerability)
> - **Severity:** CVSS v4.0 score of 9.2 for both vulnerabilities
> - **Patched versions:** 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
> - **Earliest recorded exploitation attempt:** October 17, 2026, four days before public disclosure (Amazon MadPot)
> - **Within two hours of disclosure:** hundreds of thousands of exploitation attempts (Cloudflare)

## Why Did Japan's Prime Minister Step In? Taking a Site Offline Is Like Calling a Typhoon Day Off

Japan's government body responsible for cybersecurity, the National Cybersecurity Office, posted warnings on X. Prime Minister Takaichi published her own post at 9:55 p.m. Japan time on October 21, directing people to that office's account. The patch arrived an hour later, at 11:00 p.m.

Through that afternoon and into the night, Japan time, a large number of Japanese services went offline voluntarily. The e-commerce platform BASE posted a public notice specifying that it was taking maintenance forward to 3:50 p.m. from the originally planned 10:00 p.m., citing a critical PHP vulnerability. Cygames took down games including Uma Musume: Pretty Derby for emergency maintenance, also naming the PHP vulnerability. The illustration community pixiv, the video platform niconico, and the official Sapporo city government site all suspended service that evening, though their notices did not name PHP specifically (compiled from [Webセキュリティ診断センター](https://websec-center.com/blog/kokunai-kigyou-taiou/)). Financial institutions followed: [Reuters reported](https://www.thestar.com.my/tech/tech-news/2026/10/22/cloudflare-sees-millions-of-exploit-attempts-after-php-disclosure) that Mitsubishi UFJ Financial Group suspended parts of its online services, and the Ministry of Finance took portions of its web presence offline. Takaichi's own official site [was taken down that same evening](https://www.nikkei.com/article/DGXZQOUA221J60S6A021C2000000/) and came back online around midday the following day.

ITmedia gathered reactions from engineers who observed that the Prime Minister's direct statement gave corporate leadership a reason to take the risk seriously. ITmedia also noted that downtime has business costs, which causes patching to be deferred; by describing a temporary shutdown as one effective way to reduce risk, the Prime Minister could give operators the push they needed to make that call.

The framing is familiar to anyone in Taiwan: it is the logic of a typhoon day. Local governments announce work and school suspensions before a typhoon makes landfall, keeping people in safe places before the damage arrives. Japan's shutdown wave that evening was the internet equivalent.

The following day, October 22, cybersecurity stocks on the Tokyo Stock Exchange moved upward. [Investing.com reported](https://jp.investing.com/news/stock-market-news/article-1720674) that markets expected demand for security services to rise. Trend Micro closed up 8.69 percent, FFRI up 9.62 percent. [サイバーソリューションズ](https://www.cybersolutions.co.jp/) (Cyber Solutions, ticker 436A), which provides corporate email and email security services, closed at 2,000 yen, up 20.85 percent, on volume of approximately 6.27 million shares, 8.7 times the prior day's figure ([Kabutan closing data](https://kabutan.jp/stock/kabuka?code=436A)). On October 6, the company announced a launch promotion for its AI email security service; its shares closed up 21.38 percent that day, and FFRI and Trend Micro also rose 6.38 percent and 2.76 percent. As of the afternoon of October 22, the company had published no statement on PHP2Shell; the October 22 move looks more like the entire security sector being bought up together. (Disclosure: I hold shares in this company. This paragraph summarizes market activity only and does not constitute investment advice.)

![Bar chart: closing gains on the Tokyo Stock Exchange on October 22, 2026. Trend Micro up 8.69 percent, FFRI up 9.62 percent, Cyber Solutions up 20.85 percent. Source: Kabutan.](/images/articles/php2shell-patch-tonight/security-stocks-1022-en.svg)

Other countries acted as well. The US Cybersecurity and Infrastructure Security Agency (CISA) [called for immediate patching](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching). The UK's National Cyber Security Centre (NCSC) [urged British organizations to update at once](https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/) and to take systems offline if they could not. Reuters also reported that government websites in Europe went temporarily dark.

In Taiwan, the Administration for Cybersecurity under the Ministry of Digital Affairs published a [press release on October 22](https://moda.gov.tw/ACS/press/news/press/21134), asking government agencies, schools, and businesses using PHP to verify their versions and complete the update as soon as possible, and to review system logs afterward for any signs of unusual access.

## Did My Sites Get Hit? How I Checked

Back to my own situation. An AI spent a few minutes checking the sites I manage from the outside: it requested common PHP-associated paths on each site and observed how the servers responded, then inspected the page source for traces left by platforms like WordPress. PHP showed up nowhere. paulkuo.tw, for instance, serves pre-generated static files from Cloudflare's edge network, with anything requiring backend computation handled by Cloudflare Workers.

I wrote about a security-audit experience [in an earlier post](/en/articles/ai-security-audit-ground-truth/): an AI saying something is fixed is not the same as verifying it from outside with curl. The same logic applies here. The basis for my assessment was what the servers actually returned.

The reason my sites weren't affected is simple: the architecture I use doesn't include PHP as a component. When the next vulnerability turns up in something I do use, I'll face the same set of questions: do I know what software my sites are running, and can I patch within a few hours if needed?

## Once Vulnerabilities Can't Hide, What Does Security Come Down To?

Spread the timeline out. The oldest of these issues sat inside PHP for at least fourteen years. In August 2026, researchers using AI brought it to light. Proof-of-concept code appeared twelve hours before the patch was published. Within two hours of disclosure, exploitation attempts had reached hundreds of thousands.

AI makes it impossible for vulnerabilities to stay hidden. The decisive question in security has shifted from who finds them first to who fixes them first.

Fixing fast requires preparation that happens before the alarm sounds. You need to know what software your site is running. You need someone with the authority and access to apply updates immediately. And you need someone willing to say "take it offline" when that's the right call. None of those things can be arranged after the alert arrives.

Takaichi's [second post](https://x.com/takaichi_sanae/status/2113118173818224932), published at 1:00 p.m. Japan time on October 22 (noon in Taiwan), addressed exactly this. She described how her own office contacted the site and server managers the previous evening to take the site down, handle the update, and bring it back online only after the work was done. She also noted that some site operators may face situations requiring overnight action and may not catch warnings in time; if the person responsible for a site, or the contracted web or server manager, sees the alert first, they can act sooner. Her suggestion: if every manager in that position followed the government's cybersecurity alert account [@cyber_forecast](https://x.com/cyber_forecast), response times would improve ([ITmedia coverage](https://www.itmedia.co.jp/news/article/2610/22/2000002512/)).

Ezekiel 33 describes the watchman's responsibility: if the watchman sees the sword coming and sounds the trumpet, the people are warned; those who hear it and do nothing bear the consequences themselves; but if the watchman sees the danger and does not sound the trumpet, the blood of the fallen falls on the watchman.

What Takaichi did that evening was sound the trumpet. Her second post the next day told everyone where to stand and listen for it next time.

## After the Trumpet Sounds

If you are an ordinary user of websites and you have noticed services going into maintenance over the past few days, there is no need for alarm. That is almost certainly operators responding to the warning. What you can do: don't reuse the same password across sites, and be skeptical of any email arriving in this window that claims to be a security update and asks you to click a link or enter credentials.

If you run your own blog or online shop, ask your hosting provider one direct question: has the PHP on my server been updated to a patched version? The patched versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, whichever matches your branch. If you are still on PHP 8.1 or older, the PHP project no longer provides regular updates. It released minimal patches covering branches from 7.4 through 8.1, and some Linux distributions will backport fixes as well, but the most stable path is upgrading to a supported branch. If that isn't immediately possible, take the site down for now. The official PHP announcement is direct: "There are no complete mitigations, updating is the only safe choice."

The next alarm may not come with a prime minister's post the evening before. When it arrives, will your organization know what to patch, and will someone be ready to call a shutdown?

For more on how AI is reshaping the order of things: [Intelligence and Order](/en/topics/ai/).