PHP の脆弱性で、1000 社以上がサイトを止めた#

2026 年 10 月 21 日に、PHP の重大な脆弱性「php2shell」（CVE-2026-109618、CVE-2026-109619）が公表されました。外部からサーバー上で任意のコードを実行されるおそれがあるもので、PHP 5.x から 8.x まで広く影響しうるとされています。詳しくは GMO Flatt Security の解説がまとまっています。

• PHP の重大な脆弱性「php2shell」の概要と対応指針（GMO Flatt Security Blog）

報道によると、10 月 26 日の時点でサイトやサービスの停止が確認された企業は累計 1090 件で、そのうち約 4 割は再開が確認できていません。長引いている理由のひとつは、どこで PHP を使っているかの確認に時間がかかっていることだそうです。

• PHP 脆弱性で 1000 件超のサイトなどサービス休止　約 4 割の企業が再開できず（テレビ朝日系 ANN / Yahoo!ニュース）

WordPress は PHP で動いています。この脆弱性の深掘りはしませんが、ポイントは 1 つだけです。この脆弱性は、アクセスのたびにサーバーで PHP が動いていることが前提です。 Astro で作った静的サイトには、その「動いている PHP」がありません。

WordPress と静的サイトは何が違うのか#

たとえるなら、WordPress は注文が入るたびに厨房で料理を作る店です。誰かがページを開くたびに、サーバーで PHP が動いて、データベースから記事を取り出して、ページを組み立てて返します。

静的サイトは、完成品を棚に並べておく店です。ページはあらかじめ HTML ファイルとして作っておき、サーバーはそれを渡すだけです。厨房がないので、厨房を狙った攻撃はそもそも成立しません。

Astro は、この「完成品の HTML を作る」ための道具です。

下から 2 行目は正直に書きました。書くのは WordPress のほうが圧倒的に楽です。その代わり、守る手間がずっと続きます。Astro は書くのが少し面倒な代わりに、本番に守るものがほとんどありません。この交換をどう考えるかです。

全体の地図#

Astro のブログで記事が公開されるまでの流れは、これだけです。

自分の PC                    GitHub                  Netlify
───────────                ─────────              ──────────────────
① .md を書く
② 手元で見た目を確認
③ push  ───────────────▶  ④ ファイルを保管  ──▶  ⑤ HTML を作る（ビルド）
                                                   ⑥ 世界に公開

登場人物は 3 つです。

• 自分の PC：記事を書いて、公開前に見た目を確認する場所。WordPress の管理画面とプレビューにあたります
• GitHub：ファイルを保管する場所。push が「公開ボタン」の代わりになります
• Netlify：GitHub に新しいファイルが届くと、自動で HTML を作って公開してくれる場所。WordPress でいう「サーバー」の代わりです

Netlify が自動でやってくれるので、push した後に人がすることはありません。

NOTE

「フロントエンド」という言葉が出てくると身構えてしまいますが、ブログを書くだけなら、ここで言う ①〜③ しか触りません。デザインや仕組みはテーマ（このブログは Fuwari）が最初から用意してくれています。

必要な環境#

最初に一度だけ準備するものです。このブログは Mac で書いているので、Mac の手順で説明します。

xcode-select --install

git --version

brew install node
brew install pnpm

node -v
pnpm -v

実際に 1 本書いてみる#

テーマ（Fuwari）を自分の GitHub にコピーして PC に持ってきたら、最初に一度だけ部品を入れます。

pnpm install

あとは、記事を書くたびに次の流れです。

pnpm new-post -- my-first-post

---
title: はじめての記事
published: 2026-10-28
description: "記事の説明"
tags: ["日記"]
category: "雑記"
draft: false
---

ここから本文です。**太字**や[リンク](https://example.com)は Markdown で書きます。

pnpm dev

git add .
git commit -m "はじめての記事を追加"
git push

更新は、急がなくていい#

Astro にも更新はあります。ただ、WordPress の更新とは性質がまったく違います。

• WordPress の更新は急ぎの仕事です。本番のサーバーで PHP やプラグインが動いているので、脆弱性が出たら直すまで危険です。今回のように、サイトを止めて直すことになります
• Astro の更新は自分の都合でやれます。Astro が動くのは、HTML を作る（ビルドする）ときだけです。更新に失敗しても止まるのはビルドで、公開中のサイトは前の HTML のまま動き続けます

実際、このブログの Astro は、テーマを取り込んだときの 5.1.6 のままです。最新は 7 系ですが、本番のサイトは何事もなく動いています。更新は、来るたびに急いでやる必要はなく、自分のタイミングで選べます。

とはいえ、放っておいていいという意味ではありません（ビルドのときに動く部品の話は、次の節で書きます）。急がなくていいし失敗しても本番が壊れないので、Claude Code のような AI にバージョンアップを任せて、手元で確認してから push する、という進め方ができます。

あ、そうなんだ。じゃあ後でバージョン上げてその作業もブログにするかな

静的サイトでも気をつけること#

「Astro なら絶対安全」ではありません。正確には「静的に出力したサイトなら、狙われる場所が少ない」です。

• Astro にもサーバーで動かすモード（SSR）があります。 その場合はサーバー側でプログラムが動くので、WordPress と同じように守る必要が出てきます。この記事の話は、HTML を作って置くだけの使い方（静的出力）の場合です
• 部品（npm のパッケージ）は、手元やビルドのときに動きます。 本番サイトには影響しなくても、自分の PC やビルド環境が狙われる可能性はあります
• GitHub のアカウントが鍵です。 前述のとおり、2 段階認証は必須です

向いているサイト、向いていないサイト#

ブログ、会社案内、ドキュメントのように、書いたものを読んでもらうだけのサイトには静的サイトがよく合います。

お問い合わせフォーム、会員ログイン、ネットショップのように、訪問者が何かを送ってくるサイトは、静的サイトだけでは作れません。外部のサービスを組み合わせるか、サーバーで動くしくみが必要になります。

また、エンジニアではない人が記事を書く体制なら、Git の上に管理画面をかぶせる Decap CMS のようなツールもあります。

まとめ#

• WordPress は「注文ごとに作る店」、静的サイトは「完成品を並べておく店」
• 今回の PHP の脆弱性は、サーバーで PHP が動いていることが前提。静的サイトにはその PHP がない
• Astro のブログは「.md を書く → GitHub に push → Netlify が自動で公開」の 3 段階
• 書くのは WordPress より少し面倒。その代わり、守る手間がほとんどなく、更新も急がなくていい

まあ、ショップサイトのだとか中小企業のサイトの請負はしにくいとは思うけどastroはスッキリしていて表示速度も速いしおすすめですね