2026年10月22日、PHPの重大な脆弱性への対応が、ウェブサイトの運営者にとって差し迫った課題となっています。
PHP開発元は10月21日、認証なしで外部からコードを実行される可能性がある2件の脆弱性「CVE-2026-109618」「CVE-2026-109619」への修正版を公開しました。IPAも10月22日に対策情報を公表しています。PHP公式発表、IPAの対策情報
今回の問題はWordPress固有のものではなく、PHPでウェブリクエストを処理する環境に関わります。WordPress本体の更新だけでは解消されず、PHPへの対応が必要です。WordPress公式案内
まず必要なのは、利用環境への影響と、サーバー会社や保守担当者の対応状況を確認することです。ただ、今回の対応だけで終わるとは思えません。今後も、サイトを支えるソフトウェアに脆弱性が見つかれば、影響の調査、更新、動作確認が求められます。修正が提供されるまでの間や、適用を終えるまでの間にも、リスクは残ります。
そこで考えたいのが、必要な機能を維持しながら、攻撃される可能性のある箇所と、緊急対応が必要になる仕組みを減らせないかということです。この記事では企業案内、事業紹介、お知らせなどを掲載するサイトを中心に、構築方法と運用体制の選び方を整理します。
1．今回の修正と、今後の構築方法の見直し
今回、PHP開発元が修正版として案内しているのは、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。OSやサーバーの提供元が、既存のバージョンに修正を取り込んだパッケージを提供する場合もあるため、番号だけで判断せず、提供元の対応情報を確認します。暫定的な緩和策を修正の適用と同じものとして扱わないことも必要です。PHP公式の更新案内
- 利用環境が今回の問題の対象か
- 修正が適用済みか、適用予定はいつか
- 適用後の動作確認を誰が行うか
- 直ちに対応できない場合、公開制限や一時停止をどう判断するか
将来の移行を検討していても、現在のサイトへの対策は必要です。そのうえで、今回のような対応が繰り返されることを前提に、公開環境で動かす機能やソフトウェアの構成を見直します。
2．HTMLファイルとFTPで公開していた時代
1990年代から2000年代初頭には、HTMLファイルをパソコンで作成し、FTPというファイル転送の仕組みでサーバーに送る制作方法が広く使われていました。HTMLは文章や画像、リンクなどの構造を記述する言語です。あらかじめ作成したファイルを配信する構成を「静的サイト」と呼びます。
更新時には手元のファイルを編集して再びアップロードします。共通メニューの変更で複数ページを修正するなど、制作方法によってはページ数とともに手間が増えました。その後、WordPressなどのCMSが普及し、管理画面から文章や画像を登録して更新できるようになりました。CMSは、ウェブサイトの内容を管理するシステムです。
当時もCGIなどの動的なサイトは存在しました。また、HTMLは現在もページ表示の基礎です。HTMLがPHPやWordPressに置き換わったのではなく、ページの作り方と管理方法が変わったと捉えると分かりやすくなります。現在ファイルを転送する場合は、通常のFTPではなく、SFTPやFTPSなどの暗号化された転送方法を選びます。
3．3つの構築方法は、いつページを作るかが違う
静的サイトは配信方式、WordPressはCMS、Astroはサイトを作るフレームワークです。同じ分類の名称ではないため、ここでは①HTMLを直接編集する静的サイト、②一般的な動的WordPress構成、③AstroとヘッドレスCMSで静的生成する構成に条件をそろえて比較します。
静的サイトは用意済みのページを配信します。一般的なWordPressは、閲覧要求に応じてPHPがデータベースの情報からページを作ります。ただし、キャッシュにより生成済みのページを配信する場合もあります。Astro＋CMSの静的生成構成は、記事の更新後などにページを作っておき、閲覧時にはそのファイルを配信します。
Astroは標準では公開前にページを生成しますが、アクセス時にサーバーで処理する方式も選べます。採用しただけで公開側の動的処理がなくなるわけではありません。Astroのページ生成方式
4．それぞれのメリットとデメリット
HTML中心の静的サイト
メリット：ページ配信のためのPHPやデータベースが不要な構成にでき、公開環境を小さくできます。公開済みファイルを保管しておけば、ファイルの差し戻しで内容を戻せる構成も作れます。
デメリット：直接編集にはHTMLなどの知識が必要です。ページ数や担当者が増えると、編集ミスや作業の重複を防ぐ工夫が必要になります。フォーム、会員機能、予約などには別の処理やサービスが必要です。
PHP＋WordPress
メリット：管理画面から更新でき、複数担当者の編集や必要な追加機能を組み込みやすい構成です。既存の運用や保守担当者の経験を生かせる場合もあります。
デメリット：PHP、本体、テーマ、プラグインなどの更新と互換性確認が必要です。障害時にはファイルとデータベースを整合する状態へ戻す必要があります。サーバー会社と運営者の担当範囲は契約によって異なります。WordPressのセキュリティ対策
Astro＋ヘッドレスCMSで静的生成
メリット：管理画面で記事を編集しながら、公開側では生成済みファイルを配信できます。共通部品からページを作れるため、各HTMLを個別に修正する手間も減らせます。
デメリット：CMS、ページ生成、公開配置の連携が必要です。保存から公開反映までの時間、生成失敗、プレビュー、予約公開などをどう扱うか設計します。開発用ソフトウェア、APIキー、公開処理の権限も管理対象です。
Astro公式にはmicroCMS、Storyblok、Strapiなどとの連携案内があります。CMSをサービスとして利用する場合と自社で運用する場合では保守分担が変わります。例えばStrapiを自社でホスティングする場合、実行環境やデータベースも保守対象です。AstroのCMS連携、Strapiの運用形態
公開側を単純にできても、制作・管理・公開の仕組み全体が必ず簡単になるとは限りません。別の技術や知名度の低いCMSへ替えるだけで安全になると判断せず、全体の管理対象と保守体制を比較します。
5．静的化で減るリスクと、残る管理
会社概要や事業紹介が中心なら、公開環境でPHPやデータベースを動かし続ける必要があるか見直せます。不要な実行機能を取り除くことは、攻撃に利用できる入口を減らす考え方に沿っています。OWASPの攻撃対象領域に関する指針
| 減らせる可能性があるもの | 引き続き管理するもの |
|---|---|
| 公開側のPHPなどの実行環境 | ホスティング、ドメイン、DNS |
| 公開側のCMS管理機能 | 公開用アカウント、権限、認証 |
| 公開側のデータベース | 制作・公開環境、バックアップ |
| それらに依存する追加機能 | JavaScript、フォーム、外部サービス |
HTMLを置いても、同じ環境で古いPHPやCMSが外部から利用できる状態なら、その部分のリスクは残ります。不要になった動的処理を停止し、外部から実行できなくするところまで確認します。ホスティング基盤を共有する場合の分離や保守については、提供元の責任範囲も確認します。
6．データベースと管理環境も攻撃対象になる
データベースには記事や設定に加え、利用者情報や業務データが保存される場合があります。プログラムの不備を利用するSQLインジェクションなどの不正操作と、接続設定や認証の不備を利用した直接的なアクセスの両方を考慮します。接続元の制限、ネットワーク上の分離、必要最小限の権限などが対策になります。OWASPのデータベース保護指針
管理環境と配信環境を分けても、CMSそのものの保護は必要です。CMSや公開処理のアカウントが侵害されれば、公開内容が改ざんされる可能性があります。非公開情報を生成ファイルへ含めれば、静的サイトでも情報は流出します。
データをどこに保存し、どの経路で取得し、何を公開するかまで設計します。生成処理で使う秘密のAPIキーを、閲覧者へ配るJavaScriptや公開ファイルへ含めない確認も必要です。
7．機能・費用・運用体制から選ぶ
| 条件 | 候補 | 確認したい負担 |
|---|---|---|
| ページと更新が限られ、制作担当者へ依頼できる | HTML中心の静的サイト | 更新費用、対応時間、引継ぎ |
| 共通部品を使い、制作環境を管理できる | Astroなどの静的生成 | 依存ソフトウェア、生成・公開処理 |
| 管理画面で更新し、CMS基盤の運用を提供元へ任せたい | 静的生成＋サービス型CMS | 料金、権限、契約条件、データ出力 |
| 独自要件がありCMSも保守できる | 静的生成＋自社運用CMS | CMS・実行環境・データベース |
| 編集や追加機能が業務に合い、継続保守を確保できる | WordPress | PHPを含む更新責任、互換性、復元 |
更新が頻繁でも静的生成＋CMSが適する場合はあります。更新が少なくても、担当者の操作性や既存の保守契約を考えるとWordPressの継続が合理的な場合もあります。会員機能、予約、決済などは、処理をどこで行い、誰が管理するかを別途検討します。
制作費だけでなく、更新作業、保守、サービス利用料、障害対応、移行・引継ぎまで比較します。「静的だから安い」「CMSが無料だから運用も安い」とは限りません。既存サイトを維持する案と移行する案を、同じ機能と保守範囲で見積もります。
参考：公開先にもさまざまな選択肢があります。例えば、Vercelは、Astroなどで作るサイトの生成・公開に利用できるサービスです。CMSや制作フレームワークとは役割が異なります。ほかにもNetlify、Cloudflare、GitHub Pagesなどの選択肢があります。対応する公開方式や機能はサービスごとに異なるため、用途、料金・利用条件、運用体制から選びます。Astro公式の公開先一覧
8．AIは選択肢を広げるが、運用責任は残る
AIによるコード作成や修正の支援を使えば、これまで取り組みにくかった構築方法を試しやすくなります。手順書や引継ぎ資料の作成にも活用できます。ただし、コードを生成できることと、担当者が安全に運用できることは別に確認します。
認証、権限、フォーム、秘密情報、データベース、公開処理には人による確認や検証が必要です。顧客情報や認証情報を未加工のままAIへ入力しない扱いも必要です。機能を追加しやすくなった結果、管理対象を増やし過ぎないようにします。
9．導入前に、更新と復旧まで試す
- 現状を把握する：ページ、機能、保存データ、更新頻度、ソフトウェア、契約、管理者を整理します。
- 必要な機能を絞る：使っていない追加機能や管理画面、不要なデータ保存を確認します。
- 代表的なページで試作する：実際の担当者が更新、確認、公開まで操作し、更新反映までの時間も測ります。
- 失敗時の扱いを試す：公開失敗時に旧版を維持できるか、誤公開を戻せるか、バックアップから復元できるかを確認します。
- 移行条件を決める：URL、転送設定、画像、フォーム、表示、データの引継ぎを確認し、切替えと復元の手順を決めます。
日常の更新担当、セキュリティ情報の確認担当、障害対応の連絡先を明確にします。契約終了時に制作物とデータを取り出せるかも確認します。不要なCMSや実行環境は、必要なバックアップや記録を確保してから停止・撤去します。侵害が疑われる場合は、調査に必要なログなどを先に保全します。
導入効果は更新時間、保守費用、外部から利用できる機能、復旧時間などで確認します。ただし、ソフトウェアの数が減っただけで安全性が確定するわけではありません。残した機能の権限や扱うデータも含めて評価します。
今回のPHPへの対応は必要です。そして、その対応を終えたあとにも、構築方法を考える余地があります。必要な機能を絞り、公開環境で動かす処理と保管するデータを減らす。残した仕組みには、更新と復旧を続けられる体制を用意する。
脆弱性が見つかるたびに対応することと、対応が必要になる範囲を小さくすること。その両方を、これからのウェブサイト構築に含めたいと考えます。
脆弱性と製品仕様の確認日：2026年10月22日。実際の対応では、利用しているサーバーやサービスの最新案内を確認してください。