Home › Insights › The Night Japan's Prime Minister Took Her Website Offline, So Did We: Responding to a Critical PHP Vulnerability and Rebuilding Our Site in a Day

The Night Japan's Prime Minister Took Her Website Offline, So Did We: Responding to a Critical PHP Vulnerability and Rebuilding Our Site in a Day

· 日本語版はこちら

The site you are reading right now runs on a different foundation than it did one article ago.

A critical vulnerability in the PHP programming language was disclosed on the evening of October 21, 2026 (Japan time). That same night, we took our firm’s website offline. By the evening of October 22, we had rebuilt it from the ground up on an architecture that uses no server and no PHP at all.

An analogy may help. Our old site worked like a building with plumbing: every time someone opened a page, a program (PHP) ran on the server to fetch and assemble it. Where there is plumbing, a defect in the plumbing is a problem. The new site has no plumbing. The pages are built in advance and simply placed where visitors can read them. We kept only the part where a defect of this kind cannot occur.

This article records what happened, what we did and in what order, and why I believe a lawyer must be able to respond to events like this personally and immediately.

What happened

PHP is one of the languages the web is built on. WordPress, which powers a large share of corporate sites and blogs, runs on PHP.

On October 20, 2026 (UTC), the PHP project announced a security release fixing two vulnerabilities rated 9.2 on the CVSS scale—close to the maximum severity. The fixed versions were published at 23:00 Japan time on October 21. The flaws allow remote code execution without authentication and have come to be known as “php2shell” (CVE-2026-109618 and CVE-2026-109619).

What was unusual was that national authorities moved before the release. CERT-EU, the UK’s NCSC and Australia’s ACSC issued advisories. In Japan, the Information-technology Promotion Agency (IPA) published a “request for advance preparation” on October 21, and the National Cybersecurity Office urged administrators to prepare to apply the patch immediately. The Office also stated that temporarily suspending a website is a valid risk-reduction measure where a fix cannot be applied quickly.

And that is what happened. A Ministry of Health, Labour and Welfare system, universities, a railway company, an e-commerce platform, game companies: dozens of Japanese organizations suspended sites or services on October 21. Prime Minister Sanae Takaichi took her own website offline that evening and posted: “Is everyone’s website all right? We’ve shut ours down.” The policy chief of the ruling party announced that he had immediately suspended his site because it ran on WordPress.

A head of government shutting down her own website. That is the scale of the event.

The following afternoon, October 22, it was reported that the Supreme Court of Japan had suspended parts of the courts’ website—judicial statistics and the case-law search—since that morning. The case-law search that lawyers use every day was down. Fortunately, the civil e-filing system “mints” was unaffected and court proceedings were not disrupted. By the time that report came out, our firm had already completed the previous night’s shutdown and was in the final stage of switching over to the new site.

What we did, step by step

Like most law firms, our site ran on WordPress on a shared hosting server—that is, on PHP.

Evening of Tuesday, October 21 As soon as I saw the IPA and National Cybersecurity Office advisories and the news of the fixed release, I blocked all external access to the four domains our firm manages. Until I could confirm that the fixed version had been applied to our own server, taking the site offline was the only reliable measure.

Morning of Wednesday, October 22 I tried to confirm whether the hosting provider had applied the fix. Their control panel was overwhelmed by traffic from across the country and barely usable, and the PHP version it displayed differed from screen to screen. I switched to connecting to the server directly, bypassing the control panel, and checked the PHP version actually running from inside WordPress. It had not reached the fixed version. I decided to keep the site offline.

I also checked for signs of intrusion before the shutdown: file modification times on the server, the list of administrator accounts, the list of installed plugins. Nothing was out of place.

Midday to evening, Wednesday, October 22 Here I changed the decision. Instead of “wait for the fix and restore,” I chose to move to an architecture that does not use PHP at all.

Our site consists of firm information and articles like this one. Apart from the inquiry form, nothing needs to be computed on the fly. If we stop running programs on a server and instead serve pre-generated static pages, the “server-side program that must be patched” simply ceases to exist. This is what “from a dynamic site to a static site” means. The next time something like this happens, there will be nothing to take offline.

We exported every article and page from the old site, converted them to the new format, moved the images, set up redirects from the old URLs to the new ones, rebuilt the inquiry form separately, and repointed the domain. All of this was done in dialogue with AI. The domain switch was completed shortly after 3 p.m. on October 22, and the new site was live shortly after 4 p.m.

The old WordPress installation was never restored. Whether the fix eventually arrived there is no longer our concern.

Not “waiting” but “changing the structure”

Two distinct decisions were involved.

The first was the immediate shutdown. When the severity is clear and you cannot apply the definitive fix yourself, you shut it down. There is nothing to deliberate. It is the same decision the Prime Minister made about her own site.

The second was the structural review. Thinking only about “when can we turn it back on” is passive. Why should a law firm’s website be in a position where it cannot be safe until a third-party provider applies a patch? Ask that question, and cut the dependency. The reason we could carry out this second step within a single day is that AI compressed the work of rebuilding a site by an order of magnitude.

What “information sensitivity” means for a lawyer

This is the part I most wanted to write.

Our practice covers real estate transactions, corporate matters, civil litigation, international family law, employment and product safety. In every one of these areas, our clients’ rights are shaken daily by changes in the outside world: amendments to the law, shifts in case law, changes in a counterparty’s circumstances, and technical events like this one. An infringement does not wait for us to finish preparing.

Protecting a client’s rights takes more than knowledge of the law. It takes the sensitivity to grasp what is happening in the world the moment it happens, judge how it affects the client, and act the same day. This time I put that into practice on my own firm’s website. If I cannot do it on my own ground, I cannot credibly claim to do it on a client’s matter.

And the tool that made “acting immediately” possible was having AI built into daily practice. In a previous article (in Japanese), I described AI as the ultimate associate—a tool that raises the density of thinking per unit of time. This time it took the form of shutting down, inspecting, rebuilding and migrating a website within one night and one day. By hand, that would have been a matter of weeks.

A lawyer’s core work is not building websites. But the posture of “grasp it yourself, judge it yourself, put your own hands on it and verify”—that is the core work. I hope clients will choose a lawyer who approaches their matters that way.

A practical request

If your own or your company’s website runs on WordPress or anything else built on PHP, ask whoever manages it to confirm that the fixed version of PHP (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later) has been applied. PHP 8.1 and earlier are end-of-life and will not be patched. Until you have that confirmation, temporarily suspending the site is—as Japan’s National Cybersecurity Office has said—a valid measure.

If a website or system failure leads to a dispute with a vendor or business partner over responsibility, the technical sequence of events has to be sorted out legally. We handle those consultations as well, in English and Japanese.

Technical notes for fellow practitioners: what we actually did

The rest of this article is a memo for lawyers and other professionals running their firm’s site on WordPress. It is written at a level of detail that should let you hand this section to an AI assistant (Claude, ChatGPT or similar) and say “I want to do the same thing.”

1. Emergency shutdown (evening of Oct 21)

  • Added a single line, Require all denied, to the top of the .htaccess file in the WordPress root, returning HTTP 403 for all domains at once. The goal is to stop PHP from executing, so this is done at the server level, not inside WordPress.
  • Then allowed only my own fixed IP address with Require ip <my address> for maintenance, keeping everything else blocked.
  • Scope: the firm’s main domain (Japanese and English) plus two legacy domains, four in total.

2. Verifying whether the provider had applied the fix (morning of Oct 22)

  • The hosting provider’s control panel was unusable under load and showed inconsistent PHP versions, so I stopped trusting it.
  • Created an FTP (FTPS) account and switched to a direct connection with an FTP client (Cyberduck). Even when settings saved through the control panel were not taking effect, .htaccess could be edited directly.
  • The PHP version actually running was confirmed in the WordPress admin under Tools → Site Health → Info → Server → PHP version. This was the only trustworthy display. Result: below the fixed version (8.3.36).

3. Checking for intrusion

  • Confirmed no suspicious files in the public directory root; wp-config.php and index.php modification times untouched; only the expected administrator account; only legitimate plugins.
  • Incidentally found a typo in the WordPress admin email address and fixed it during migration.

4. Exporting the material

  • Exported both the Japanese and English sites in WXR (XML) format via Tools → Export.
  • Pages assembled by the theme and absent from WXR (home, practice areas) were saved as plain text separately.
  • Images and PDFs: downloaded wp-content/uploads in full via FTP.

5. Building the new site (static site generation)

  • Adopted the static site generator Astro. Articles and pages live as Markdown files under src/content/ and are compiled to HTML at build time. No program runs on the server.
  • WXR-to-Markdown conversion was done in one pass with a short Python script written by AI (body text, dates, original URLs, image path rewriting).
  • Built a mapping from old WordPress-style URLs (?p=105, ?page_id=72) to new URLs and implemented it as 301 redirects. This preserves search rankings and avoids broken links; do not skip it.
  • Structured data (LegalService / Person / BlogPosting), Japanese-English hreflang, Open Graph tags, sitemap and RSS are generated as standard.
  • Our policy on AI crawlers (allow search and answer engines, disallow training) is stated in robots.txt and llms.txt.

6. Hosting and publishing

  • The source lives in a private GitHub repository connected to Cloudflare Pages. Any change to the main branch is built and published automatically within one to two minutes. Adding an article means uploading one Markdown file.
  • Cost: within the free tier. The very concepts of a server contract, server maintenance and PHP version management disappear.
  • The GitHub and Cloudflare accounts are protected by passkeys on hardware security keys (YubiKey), not passwords.

7. The inquiry form

  • The only dynamic function, the inquiry form, is handled by Cloudflare Pages Functions (serverless) and relayed through an email API (Resend) to the firm’s mailbox. Sending-domain authentication (DKIM) is configured and Reply-To is set to the inquirer’s address.
  • Spam protection: Cloudflare Turnstile (a CAPTCHA alternative) plus a honeypot field.
  • The function is TypeScript, not PHP, and Cloudflare manages the runtime, so it is not something we patch ourselves.

8. The DNS switch (afternoon of Oct 22)

  • Changed the nameservers at the domain registrar to Cloudflare. Cloudflare imports the existing DNS records (MX, SPF, DKIM, DMARC) automatically, so email is unaffected.
  • Replaced the site’s A record with CNAME → <project>.pages.dev; Cloudflare issues the HTTPS certificate automatically.
  • Also pointed the old nameserver’s zone at the new destination so that paths with lingering DNS cache still reach the new site.
  • The two legacy domains host nothing and redirect (301) to the main domain via Cloudflare Redirect Rules.

9. The old server

  • The old WordPress installation stays blocked and will be cancelled after a short observation period. Before cancelling, remove the old provider’s include: entry from the SPF record.

Time and division of labour

  • My own hands-on work—creating accounts, uploading files to GitHub, operating the DNS switch, comparing old and new sites—came to roughly two hours. The design, conversion, implementation and verification were done in dialogue with AI.
  • A solo practice with no dedicated IT staff can migrate a site of this size in a single day. That is the lesson of this episode.

References (official notices and press coverage, in Japanese)

← Back to Insights