1. 守るより、置かない。『静的サイト化』という脆弱性対策――PHPの重大脆弱性から考える攻撃面の減らし方

1. 導入：また、PHPか......。

朝、セキュリティ系のニュースを開く。

「PHPに緊急パッチ」

またか、と思った方も多いのではないでしょうか。

2026年10月20日、PHPのセキュリティチームが異例の予告を出しました。翌21日の14:00 UTC（日本時間23時）に、重大な脆弱性2件の修正を緊急リリースするというものです。

CVE-2026-109618とCVE-2026-109619。

CVSS v4.0のスコアはどちらも9.2。

公開前に情報が漏れたため、前倒しで告知されたと報じられています。

通称は「php2shell」。

Use After Freeの脆弱性で、認証なしに任意のコードを実行される恐れがあります。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHPはすべて対象です。

特にmod_phpは、アプリケーションのコードが動く前の段階で攻撃が成立する実証まで示されています。

つまり、こういうことです。

WordPressやDrupalのプラグインをいくら丁寧に更新していても、

その下で動いているPHPそのものが穴になる。

今年はこれだけではありません。5月にはSOAP処理のUse After Free、7月にはPHP-FPMのプールを落とすDoS。パッチ当ての通知が、もはや季節の便りのようになっています。

この章の結論：アプリを守るだけでは足りない時代になった――。

2. なぜ「静的サイト」なのか

泥棒対策で一番確実なのは何か。

鍵を増やすことでも、警報機をつけることでもありません。

盗まれるものを家に置かないことです。

Webサイトも同じです。

公開サーバーでPHPが動いている限り、PHPの脆弱性とは縁が切れません。DBがあればSQLインジェクションの心配がつきまといます。CMSがあれば、本体とプラグインの更新に追われます。

でも、サイトの中身が「読ませるもの」中心なら、話は変わります。

ページは事前にHTMLとして作っておき、公開サーバーにはそのHTMLだけを置く。

これが静的サイトです。

もちろん、万能ではありません。

会員機能やECのように、本質的に動的なサイトには向きません。お問い合わせフォームやサイト内検索も、外部サービスや静的検索（Pagefindなど）で補う必要があります。

それでも、企業サイトやブログ、技術ドキュメントの多くは「読ませるもの」です。

この章の結論：守るより、置かない――。

3. 提案する構成：CMSは手元に、公開はHTMLだけ

「静的サイトにしたいけど、今さらHTMLを手書きするのはちょっと......」

現場でよく聞く声です。

大丈夫です。CMSは捨てなくていい。

CMSを、インターネットから見えない場所に引っ込めるだけです。

私が検討しているのは、今使っているDrupalを活かす次の構成です。

• Drupal：ローカルPCで動かす。編集はこれまで通り管理画面から
• JSON:API：Drupal 8.7以降はコアに同梱。記事データをJSONで取り出す
• Next.js または Nuxt：ビルド時にJSON:APIを叩き、静的HTMLを生成する
• AWS S3＋CloudFront：生成したHTMLだけを置いて配信する

ポイントは、Drupalが一度もインターネットに顔を出さないことです。

APIを叩くのはビルドのときだけ。それも手元のPCの中で完結します。

公開側にあるのは、HTMLと画像のファイルだけ。

PHPに今回のような脆弱性が見つかっても、読者が触れるのは「ただのファイル」です。攻撃者が狙うべきプログラムが、そもそも存在しません。

NextとNuxtのどちらを選ぶかは、正直なところ好みで構いません。静的生成という目的なら、どちらも十分な機能を持っています。

チームがReactに慣れていればNext、Vueに慣れていればNuxt。それだけで決めて良いと思います。

この章の結論：CMSを捨てるのではなく、隠す――。

4. 実装で気をつけるポイント

構成図はシンプルです。

でも、実際に手を動かすと「あれ？」がいくつか出てきます。先回りして並べておきます。

① S3は直接公開しない

S3の「静的ウェブサイトホスティング」を直接使うと、HTTPSが使えず、バケットも公開設定にする必要があります。

バケットは非公開のまま、CloudFrontのOAC（Origin Access Control）経由で配信するのが今の定番です。HTTPS、独自ドメイン、キャッシュがまとめて手に入ります。

② /about/ が開けない問題

これは、ほぼ確実にハマります。

CloudFront＋非公開S3の構成では、トップページ以外で /about/ にアクセスしても、/about/index.html を自動で返してくれません。

CloudFront Functionsで、末尾が / のリクエストに index.html を付け足す。数行のコードで解決します。既存のDrupalのURLを維持したい場合も、この方法が扱いやすいです。

③ 画像はビルド時に取り込む

JSON:APIが返す画像のURLは http://localhost/sites/default/files/... です。

そのままHTMLに埋め込むと、公開サイトでは当然表示されません。ビルド時に画像をダウンロードして出力フォルダに含め、HTML内のパスも書き換える。

実装の手間が一番かかるのは、実はここです。

④ バックアップが生命線になる

DrupalのDBと sites/default/files が、そのPCにしか存在しなくなります。

PCの故障は、そのまま全コンテンツの消失を意味します。

定期的なDBダンプと、ファイルのバックアップ。これは仕組みにしておくべきです。DockerやDDEVで環境を作っておけば、別のPCでの復元も楽になります。

⑤ この構成の向き・不向き

編集作業がPC1台に縛られるので、基本は一人か少人数での運用向けです。下書きプレビューも、Drupal標準のプレビューで割り切ることになります。

なお、Drupal 7を使っている場合は、2025年1月にサポートが終了しています。ヘッドレス化を機に、10/11への移行もあわせて検討してください。

この章の結論：落とし穴は「画像」と「バックアップ」に集中している――。

5. 明日からできる対処

静的サイト化は、明日すぐには終わりません。

だからこそ、順番が大事です。

1. まずPHPにパッチを当てる
   • 静的化を待たずに、今すぐ。PHPチームは修正版を公開済みです
   • レンタルサーバーなら、事業者の対応状況を確認してPHPのバージョンを切り替える
2. 自分のサイトが「読ませるもの」か棚卸しする
   • フォーム、検索、コメント、会員機能。動的な機能を書き出してみる
   • 外部サービスで置き換えられるか、ひとつずつ確認する
3. JSON:APIを有効にして、データを眺めてみる
   • Drupal 8.7以降ならコアのモジュールを有効にするだけ
   • /jsonapi/node/article を開けば、記事がJSONで返ってくる
4. 小さく試す
   • 記事一覧と記事詳細の2種類だけを、Next/Nuxtで静的生成してみる
   • 動けば、あとは同じパターンの繰り返しです
5. バックアップの仕組みを先に作る
   • DrupalをローカルPCに移す前に。順番を逆にしないこと

この章の結論：パッチは今日、静的化は計画的に――。

6. 結論

脆弱性対策というと、私たちはつい「どう守るか」を考えます。

パッチを当てる。WAFを入れる。監視を強化する。

どれも大切です。

でも、今回のphp2shellのように、土台そのものに穴が開くこともある。

そのたびに夜中のパッチ当てに追われるのか。

それとも、そもそも公開サーバーにPHPを置かないのか。

Drupalのヘッドレス化と静的サイト化は、「守る」から「置かない」への発想の転換です。CMSの使い勝手はそのままに、攻撃される場所だけを消す。

もちろん、すべてのサイトに当てはまるわけではありません。

それでも、「読ませるサイト」を運営している方には、一度検討してみる価値があると思います。

あなたのサイト、本当にサーバーでプログラムを動かす必要がありますか？