WordPress・PHPのセキュリティ総合ガイド｜攻撃の仕組み・脆弱性・対策を解説

第1章

WordPress・PHPは危険？まず確認すること

最初に確認したいのは、すでに異常の兆候があるのか、重大な脆弱性への対応が必要なのか、それとも平時の管理状態を確かめたいのかです。どれに当たるかで、優先すべき行動が変わります。

この章でわかること

• WordPressやPHPを使うこと自体が危険なのか
• サイトのリスクを左右する更新・設定・認証・保守体制
• PHPの脆弱性ニュースを見たら最初に確認する項目
• サイトが正常に見えても安全と断定できない理由
• 改ざんが疑われる場合は通常の点検より初動対応を優先する

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

この表は、公式の注意喚起や対応案内を基に、行動の優先順位を整理したものです。複数に当てはまる場合は上の行を優先してください。異常を把握していないことや、影響が未確認であることは、安全を確認できたという意味ではありません。出典：IPAのPHPに関する注意喚起・インシデント対応手引き・WordPress公式の侵害対応案内

WordPressやPHPを使うこと自体が危険なのか

WordPressやPHPの利用だけを理由に、サイトの安全性を決めることはできません。WordPressはページや記事を管理するソフトウェアです。PHPはサーバー側で処理を行うためのプログラミング言語で、WordPressもPHPを使って動きます。サイトを動かすPHPの実行環境はWordPress本体とは別に管理するため、本体を更新してもPHPの更新まで自動的に済むわけではありません。出典：PHP公式の解説・WordPress公式のPHP更新案内

セキュリティで問題になるのは、たとえば、ソフトウェアに見つかった弱点が修正されずに残っていることです。こうした弱点を脆弱性（ぜいじゃくせい）と呼びます。攻撃者がその弱点を利用できる条件が揃うと、運営者が意図していない処理が行われるおそれがあります。必要な条件は問題ごとに違い、使っているバージョンだけでなく、機能や設定が関係することもあります。出典：PHP開発元による脆弱性と構成条件の説明

ただし、「影響を受ける脆弱性があること」と「すでに侵入されていること」は、別の確認事項です。 脆弱性の公表は、自社サイトの侵害を証明するものではありません。一方、まだ被害が見つかっていなくても、影響を受けると確認できた問題への対処は必要です。被害の発見を待ってから更新する、という判断にはしないでください。

画像を拡大する ＋

WordPress公式も、セキュリティを、複数の対策を通じてリスクを減らしていく取り組みとして説明しています。採用している技術の名前に加え、現在の更新状況や管理方法を見ることが、安全性を考える出発点になります。出典：WordPress公式「Hardening WordPress」

サイトのリスクを左右する更新・設定・認証・保守体制

管理状態を確認するときは、更新、設定、認証、保守体制の四つに分けると、担当者にも確認を依頼しやすくなります。

また、バックアップを取得していても、保存先や復元方法を担当者が把握していなければ、事故のときにすぐ活用できません。WordPressの復元には通常、画像やプログラムなどのファイルと、記事・設定などを保存するデータベースの両方が必要です。どこまで保存され、誰が戻せるのかも保守の確認に含めます。出典：WordPress公式のバックアップ案内

たとえば、制作会社は「WordPress本体を更新済み」と伝え、サーバー会社は「新しいPHPを利用できるようにした」と案内していても、対象サイトが新しいPHPに切り替わったかは別途確認が必要です。誰かが対応したという説明と、自社サイトへの反映が完了したという確認を取り違えないことが大切です。

PHPの脆弱性ニュースを見たら最初に確認する項目

PHPの重大な脆弱性が報じられたら、ニュースの見出しだけで判断せず、開発元の告知とサーバー提供元の案内に戻ります。IPAも、2026年10月のPHPの注意喚起で、PHPを使う製品やサービスについて、提供元に影響と対策を確認するよう案内しています。出典：IPAのPHP2shellに関する注意喚起

最初に整理したいのは、次の四点です。

1. 何のソフトウェアに見つかった問題か。 PHP本体、WordPress本体、テーマ、プラグインでは、更新する対象が違います。告知の製品名と、脆弱性を識別するCVE番号があれば、その番号も控えます。名前の似た別の問題を混同しないためです。
2. 自社サイトは影響する条件に当てはまるか。 実際に使っているバージョンと、告知が示すPHPの動かし方（実行方式）や設定などを照合します。構成がわからない場合は、サーバー会社や保守担当者に確認を依頼します。
3. 対象サイトに修正が適用されているか。 修正版が提供されたことと、自社の環境に反映されたことは別です。配布元が従来のバージョンに必要な修正を組み込んで提供する場合もあるため、表示される版番号だけで判断できないときは、提供元の修正情報と適用結果を確認します。
4. 誰が、いつまでに対応を終えるか。 未対応なら、更新を行う担当者と予定、すぐに更新できない場合の当面の措置を確認します。重大な問題については、通常の定期点検まで保留せず、公式案内に沿って優先的に対応します。

この確認で重要なのは、「自社はWordPressが最新版だから、PHPも大丈夫」と考えないことです。2026年10月21日にPHPで公表された二つの重大な脆弱性についても、WordPress公式はPHP側の更新を求め、この二件を修正するためのWordPress本体更新は予定していないと説明しています。出典：WordPress公式「Critical PHP Security Release」

また、このときPHP公式は、Webからの要求を処理する各種のPHP構成を更新対象として挙げています。攻撃が実証された構成と自社の構成が違うという理由だけで、更新不要と自己判断することはできません。提供元が示す適用範囲と修正方法を確認してください。出典：PHP公式・2026年10月21日の告知

影響するバージョンや修正版の詳しい整理は第7章、自社の情報をどこで確認するかは第9章で説明します。

サイトが正常に見えても安全と断定できない理由

トップページが普段どおり表示されていても、サイト全体に問題がないとは限りません。画面で確認できるのは、そのとき開いたページが、その閲覧条件でどう表示されたかです。管理者が普段見ている範囲に、異常が現れるとは限りません。

Googleは、正規のページを残したまま不正なページを追加する改ざんや、アクセスした経路・端末などによって転送先を変える改ざんを説明しています。たとえば、URLを直接入力したときは通常のページが表示されても、検索結果から訪れた人だけが別サイトへ転送される場合があります。管理者の確認結果と、訪問者が受けた被害が食い違うことがあるのは、このためです。出典：Google公式「ハッキングされたコンテンツ」

また、脆弱性が残っていても、普段の閲覧や投稿が正常に動くことはあります。正常な入力で動作することと、問題を起こす入力や条件に耐えられることは、確認する内容が違うからです。表示確認に加えて、ソフトウェアの修正状況や管理記録も確認する必要があります。

反対に、表示崩れや接続エラーだけで、侵害が起きたと断定することもできません。障害や設定の変更などとの切り分けが必要です。いつ、どの画面で、何が起きたかを記録し、保守担当者やサーバー会社に確認してください。出典：WordPress公式のサーバー管理者への確認案内

改ざんが疑われる場合は通常の点検より初動対応を優先する

見覚えのない管理者アカウントや、作成していないページ、不審な転送などに気づいた場合は、侵害の可能性を確認する対応に切り替えます。ここでいう侵害とは、第三者による不正なアクセスや操作によって、サイトや情報が損なわれることです。通常の更新作業だけで対処を終わらせないことが重要です。

まず、気づいた日時、対象のURL、起きている症状、直前に行った変更を、わかる範囲で記録してください。その情報を保守担当者やサーバー会社に伝え、被害の拡大を抑える措置と調査を依頼します。不正な転送などが続いている場合は、記録をすべて揃えるまで対応を待つのではなく、公開範囲の制限や一時停止などが必要かを担当者と並行して判断します。出典：WordPress公式の症状記録・連絡の案内・IPAの初動対応の説明

原因がわからないまま、ファイルを一括削除したり、バックアップで上書きしたりしないでください。 不正な変更の痕跡を削除・上書きすると、侵入経路や影響範囲を調べにくくなります。アクセスログなどの記録も含め、何を保全するかを担当者に確認してください。出典：IPAの初動対応・証拠保全の説明

WordPress公式も、除去作業の前に、問題が起きた状態の複製を取ることを勧めています。調査用の複製には、被害が疑われる状態を保存したものだと明記します。改ざんや不正なファイルが含まれていないことを確認し、復旧に使うバックアップとは区別してください。出典：WordPress公式の除去前の保全・被害を受けたバックアップの扱い

修正プログラムを適用したかどうかと、侵入後に残された不正なファイルやアカウントがないかは別の問題です。IPAも、2024年のPHPの脆弱性を狙う攻撃について、修正済みの場合でも通信ログなどで被害の有無を確認するよう案内しています。更新を終えたことだけで、侵害からの復旧が完了したとは判断できません。出典：IPA「PHPの脆弱性を狙う攻撃について」

具体的な初動と復旧の考え方は、第12章「改ざんや侵害が疑われるときの初動と復旧」で説明します。異常の兆候がなく、仕組みから理解したい場合は、続く第2章でPHP・WordPress・Webサーバーの関係を確認していきましょう。

関連する説明：脆弱性と攻撃成立条件／自社の版と構成の確認／侵害時の初動
この章の目次へ・全体の目次へ

第2章

PHP・WordPress・Webサーバーはどのように動くのか

WordPressのサイトは、閲覧の要求を受け付けるWebサーバー、プログラムを動かすPHP、記事などのデータを保存するデータベースが連携して動きます。WordPressは、その仕組みの上で記事の管理やページの生成を行うソフトウェアです。それぞれの役割を分けて理解すると、脆弱性のニュースがどの部分を指しているのか、何を更新する必要があるのかを整理しやすくなります。出典：PHP公式の動作環境の説明・WordPress公式のPHP更新案内・ファイルとデータベースの説明

この章でわかること

• PHPとは何か：サーバー側のプログラム
• WordPress本体・テーマ・プラグインの役割
• Webサーバー・データベースとページが表示されるまで
• PHPの実行方式（mod_php・PHP-FPM・CGI）とは
  • 方式の違いが脆弱性の攻撃条件に関係する理由
• 更新する対象と管理する担当者が異なる場合
• WordPressが普及する理由と保守上の注意点

PHPとは何か：サーバー側のプログラム

PHPは、Webサイトの処理などを書くためのプログラミング言語です。WordPressでは、PHPで書かれたプログラムを、サーバー上に用意されたPHPの実行ソフトウェアが動かします。「PHPを更新する」というときは、通常、この実行ソフトウェアを新しい版に更新することを指します。出典：PHP公式の入門解説・WordPress公式のPHP更新案内

たとえば、会社のお知らせを一覧にするページを考えてみましょう。WordPressのプログラムが、表示する記事を選び、タイトルや本文の一部を決められた形に並べる処理を行います。そのPHPのプログラムを実際に動かすのが、サーバー側のPHPの実行環境です。記事を追加するたびに、担当者が一覧ページのHTMLを手作業で作り直す必要はありません。出典：WordPress公式の記事表示の仕組み

HTMLは、見出し・段落・リンクなど、ページの構造を表すための記述です。PHPが正しく動作する通常の構成では、ブラウザが受け取るのは、PHPのプログラムを実行して作られたHTMLなどの結果です。閲覧者のパソコンやスマートフォンにPHPをインストールして、WordPressの処理を動かすわけではありません。出典：PHP公式のサーバー側処理の説明

このように、保存されたデータなどを基に、要求に応じてページの内容を組み立てる仕組みを動的なページ生成と呼びます。WordPressでは、同じ仕組みを使って、記事一覧、個別の記事、検索結果など、表示する内容の異なるページを作れます。PHPにはWeb以外の自動処理に使う用途もありますが、ここではサイトのページを作る役割を押さえておけば十分です。出典：PHP公式の用途の説明・WordPress公式のテンプレートの仕組み・記事表示の説明

WordPress本体・テーマ・プラグインの役割

WordPressは、文章や画像などを管理してWebサイトを運営するためのCMS（コンテンツ管理システム）です。管理画面から記事を作成し、下書きを保存したり、公開する日時を指定したりできます。サイトごとの見せ方や追加機能は、本体にテーマやプラグインを組み合わせて用意します。出典：WordPress公式の機能紹介

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

この表は主な役割を整理したものです。WordPress公式も、テーマは主に表示、プラグインは主に機能を担当すると説明しています。ただし、実際の機能には重なる部分があります。出典：WordPress公式のテーマ解説・プラグイン解説・機能紹介

テーマは、ページのひな形となるテンプレートや、文字の大きさ・色などを指定するCSSなどで構成されます。ブラウザ上の動作を制御するJavaScriptを含むこともあります。サーバー側で動くPHPの処理を含む場合もあり、デザインを担当する部品でも、プログラムとしての保守が必要です。プラグインもPHPを中心とするコードのまとまりで、CSSやJavaScript、画像などを含められます。出典：テーマを構成するファイル・プラグインの構成

たとえば、お知らせページの本文を管理するのはWordPress本体、一覧の見せ方を整えるのはテーマ、問い合わせを受け付ける機能を加えるのはプラグイン、という分担が考えられます。画面では一つのサイトに見えても、内部には役割の異なるプログラムが組み合わさっています。更新を考える際にも、本体・テーマ・プラグインをそれぞれ管理対象として扱う必要があります。出典：WordPress公式の更新対象の説明

Webサーバー・データベースとページが表示されるまで

では、訪問者が一つのお知らせ記事を開くとき、どのような処理が行われるのでしょうか。以下は、WordPressが動的にページを作る場合の基本的な流れです。

動的にページを生成する場合の基本的な流れ

画像を拡大する ＋

図の内容をテキストで読む

1. 01 ブラウザ（訪問者）

   URLのページを要求・応答を表示

   ブラウザからWebサーバーへ：ページを要求

   Webサーバーからブラウザへ：HTML等を返す

2. 02 Webサーバー

   要求を受信し、対象に応じて処理を振り分ける

   WebサーバーからPHP実行環境へ：PHPの処理へ

   PHP実行環境からWebサーバーへ：生成した内容

3. 03 PHP実行環境

   この中でWordPressのサーバー側処理を実行

   • WordPress本体
   • テーマ
   • プラグイン

   PHP実行環境からデータベースへ：問い合わせ

   データベースからPHP実行環境へ：必要なデータ

4. 04 データベース

   記事・コメント・多くの設定
   メディアの管理情報など

※各枠は役割を示す模式図（別々の物理サーバーとは限りません）。

画像・CSSの直接配信やページキャッシュでは、経路が異なる場合があります。

補足：画像等の管理情報（実画像は別）。WordPress本体・テーマ・プラグインは、別々の直列工程を表すものではありません。

WordPressが動的にページを生成する場合の基本的な流れ。PHP上のWordPressがDBの情報などを使って表示内容を組み立て、Webサーバーを通じてブラウザへ返します。静的ファイルの配信やキャッシュでは経路が異なる場合があります。

参考資料：PHP公式：PHPの概要／WordPress公式：テーマ／WordPress公式：バックアップ／WordPress公式：最適化

1. ブラウザがページを要求する。 訪問者がリンクを開くと、そのURLに対応するページを求める情報がサイト側へ送られます。
2. Webサーバーが要求を受け、PHPへ処理を渡す。 WordPressで処理するよう設定された要求に対して、PHPがWordPressのプログラムを実行します。
3. WordPressが必要なデータを取得する。 対象の記事や設定などをデータベースへ問い合わせ、返された情報を使います。
4. 表示する内容を組み立てる。 記事の内容とテーマのテンプレートなどを組み合わせ、ブラウザに返すHTMLを生成します。
5. Webサーバーが結果を返し、ブラウザが表示する。 ブラウザは受け取ったHTMLを読み、必要な画像やCSSなども取得して画面を表示します。

ここで、データベースが直接ブラウザへページを送るわけではありません。必要なデータを受け取ったWordPressの処理が表示内容を組み立て、その結果をWebサーバーが返します。処理の細かな順序や呼び出す回数は構成によって変わりますが、この役割分担が基本です。出典：PHP公式の処理と出力の説明・WordPress公式のテンプレートによるページ生成・記事表示の説明

また、すべてのアクセスで、この流れを最初から同じように実行するとは限りません。画像やCSSなどはWebサーバーから直接返す場合があり、キャッシュと呼ばれる、作成済みの結果を保存して再利用する仕組みもあります。ページ全体のキャッシュを返せばページを組み立て直す処理を省ける場合があり、データ取得結果のキャッシュはデータベースへの問い合わせを減らします。どの処理を省けるかは実装や設定によるため、「キャッシュがあるのでPHPは一切動かない」とも限りません。出典：nginx公式の静的ファイル配信の説明・WordPress公式のキャッシュ解説

PHPの実行方式（mod_php・PHP-FPM・CGI）とは

ここまでの「WebサーバーがPHPへ処理を渡す」という部分には、複数の実現方法があります。これがPHPの実行方式です。利用者に見えるページが同じでも、サーバー内部でPHPを動かす場所や、処理を受け渡す仕組みは異なります。

違いを理解するために、プロセスという言葉を押さえておきましょう。プロセスは、コンピューター上で実行されているプログラムの単位です。同じ一台のサーバーの中でも、WebサーバーとPHPを別々のプロセスとして動かせます。反対に、PHPをWebサーバーのプロセス内に組み込む方式もあります。出典：PHP公式のApache向け導入手引き・PHP-FPMの説明

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

mod_phpの「モジュール」は、Apacheに組み込む追加部品という意味です。CGIは、Webサーバーと外部のプログラムが情報を受け渡すための仕組みで、PHP以外にも使われます。出典：PHP公式のApacheモジュールの説明・Apache公式のCGI解説・PHP公式のプロセスの使われ方

FastCGIは、外部の実行プロセスを継続して利用しながら、Webサーバーとの間で要求や結果を受け渡すための通信方式です。PHP-FPMは、FastCGIで受け取った要求に応じてPHPを実行し、その実行プロセスを管理する仕組みです。FastCGIが受け渡しの方式、PHP-FPMがPHP側の実行・管理を担うもの、と分けて考えると整理できます。出典：Apache公式のFastCGI対応の説明・実行プロセスの継続利用の説明・PHP公式のFPM解説

PHP-FPMでは、実際の処理を受け持つプロセスをワーカーと呼びます。同じワーカーが複数の要求を順に処理する場合があり、毎回必ずPHPを起動し直す構成ではありません。これは通常の動作です。また、ApacheでもPHP-FPMを利用できます。ApacheというWebサーバーの名前だけを聞いて、mod_phpで動いていると決めることはできません。出典：PHP公式のワーカーと要求の関係・Apache公式のPHP-FPM連携例

2026年10月25日の確認時点で、PHP公式は、LinuxなどのUnix系の環境でApacheを新規導入する場合に、PHP-FPMを使うよう案内しています。既存サイトの構成変更を考える際には、その案内に加え、提供元の対応やサイトへの影響を確認する必要があります。実行方式の名前を見て、意味のわからないまま設定を切り替えることは避けてください。出典：PHP公式の新規導入に関する案内

方式の違いが脆弱性の攻撃条件に関係する理由

実行方式が違うと、WebサーバーからPHPへ情報を渡す方法や、処理を始めるときや終えるときの動き、プロセスの扱いが変わります。脆弱性がこうした特定の処理に関係する場合、同じPHPのバージョンでも、影響を受ける条件が同じとは限りません。出典：PHP公式の実行プロセスの説明・実行方式ごとの影響に言及したPHP公式告知

一方で、複数の実行方式に共通して影響する問題もあります。PHP公式の注意喚起にも、PHP-FPM、mod_php、CGIなどを広く更新対象とするものがあります。実行方式は影響を判断するための確認項目の一つであり、その名前だけで安全性を決めることはできません。出典：PHP公式の更新対象に関する告知

ニュースに書かれた方式と自社の方式を照合する際も、提供元の告知が示す範囲や設定条件を確認します。担当者へ問い合わせるときは、「PHPのバージョン」に加えて「どの実行方式を使っているか」を伝えられると、確認を進めやすくなります。攻撃成立条件の詳しい読み方は第4章、PHPの個別事例は第7章で説明します。

更新する対象と管理する担当者が異なる場合

ここまで見てきたように、一つのサイトでも、記事を管理するWordPress、その処理を動かすPHP、要求を受け付けるWebサーバー、データを保存するデータベースは役割が異なります。そのため、変更に必要な権限や、作業の担当者も分かれる場合があります。

たとえば、次のような分担が考えられます。これは役割を理解するための例であり、すべての契約に当てはまるものではありません。

• 自社の広報担当者WordPressの管理画面からお知らせや画像を更新する。
• 制作会社や保守担当者WordPress本体・テーマ・プラグインの更新や、サイトの動作確認を行う。
• サーバー会社やサーバー管理者PHP・Webサーバー・データベース管理ソフトウェアなど、サーバー側の環境を管理する。

実際の分担は、サーバーサービスの提供範囲や保守契約で決まります。WordPressの保守まで含むサービスもあれば、サーバー環境を用意するところまでが契約範囲のサービスもあります。WordPress公式も、ホスティング側とサイト運営者側の担当範囲を理解する必要があると説明しています。出典：WordPress公式のホスティングと管理責任の説明・サービス形態による管理範囲の違い

PHPを更新する際には、テーマやプラグインが新しいPHPで動くかを確かめる必要もあります。環境を変更する担当者と、サイトの表示や機能を確認する担当者が別なら、作業の時期と確認範囲を合わせて進めます。サイトを構成するプログラム同士が連携しているため、更新作業にも担当者間の連携が必要になるのです。出典：WordPress公式のPHP更新・互換性確認の案内

「サイトの保守」という一つの言葉で済ませず、対象と作業を分けて担当範囲を確かめることが大切です。 自社で構成を確認する方法は第9章、更新前後に必要な作業は第10章で整理します。

WordPressが普及する理由と保守上の注意点

WordPressの利点は、記事を管理する仕組みが用意されており、テーマやプラグインでサイトに必要な見せ方・機能を組み合わせられることです。企業サイトでも、公開後の情報更新を日常業務に取り入れやすくなります。出典：WordPress公式の機能紹介

• 内容を更新しやすい。 管理画面から文章や画像を編集でき、下書きや予約公開も利用できます。
• 担当者の役割を分けられる。 サイト全体を管理する人と、記事の編集・投稿を担当する人の権限を分けて運用できます。
• 必要に応じて拡張できる。 テーマで表示を整え、プラグインで機能を追加する構成を選べます。

これらはWordPress公式が案内する基本機能です。どこまで編集できるか、どの機能を使えるかは、採用するテーマ・プラグインや管理者から付与された権限によって変わります。出典：WordPress公式の公開・ユーザー管理・拡張機能の説明・テーマの機能と構成

ただし、記事を編集しやすいことと、運用中のソフトウェアを管理しなくてよいことは別です。追加した機能にも更新や互換性の確認が必要になり、提供元の対応が続いているかを把握する必要があります。PHPなどの動作環境、アカウント、バックアップも含めて、継続して管理する体制が求められます。出典：WordPress公式の更新・互換性確認の案内・セキュリティ管理の基本

必要な情報を自社で更新できる利点と、利用する構成を保守し続ける負担の両方を見て、運用方法を決めましょう。WordPressを継続する場合と別の構成を選ぶ場合の比較は、第13章で扱います。

ここまでで、ページを作る側の役割分担が見えてきました。次の第3章「攻撃はどこから届く？HTTP通信とサーバー処理の仕組み」では、ブラウザなどから送られた情報が、どのようにサーバーへ届き、処理に使われるのかを確認していきます。

関連する説明：HTTP通信の基本／PHPの実行方式と脆弱性の条件
この章の目次へ・全体の目次へ

第3章

攻撃はどこから届く？HTTP通信とサーバー処理の仕組み

Webサイトへの攻撃は、必ずしも管理画面へのログインから始まるわけではありません。普段のページ閲覧やフォーム送信と同じ、HTTPという通信の仕組みを通じて、サーバーへ入力が届くことがあります。 HTTPはWeb上で情報を要求し、結果を受け取るための取り決めです。攻撃専用の通信方式ではなく、通常の利用にも欠かせません。

この章でわかること

• HTTPリクエストとレスポンスの基本
• GET・POSTの違いと誤解しやすい点
• URL・クエリ・Cookie・ヘッダー・リクエスト本文
• ブラウザ以外のCLI・自動プログラムもHTTP通信を送れる
• 外部入力がPHPやWordPressで処理されるまで
• HTTPS/TLSで保護できること・できないこと

重要なのは、「外部から要求を送れること」と「その要求どおりに処理してよいこと」を分けて考えることです。公開ページの閲覧はログインせずに利用できても、記事の編集や設定の変更は、本人確認や操作権限によって制限されるべきものです。この章では、入力が届く入口と、その先の処理の関係を順に確認します。出典：HTTPの基本構造・HTTPの標準仕様・WordPress REST APIの権限設定

HTTPリクエストとレスポンスの基本

Webサイトでリンクを押すと、ブラウザはサイト側に「このページの情報を返してください」という要求を送ります。この要求がHTTPリクエストです。要求を受けたWebサーバーは必要な処理を行い、結果をHTTPレスポンスとして返します。ブラウザは返ってきたHTMLなどを使ってページを表示します。

たとえば、会社のお知らせを開く場面では、次のようなやり取りが起こります。

1. ブラウザが要求を送る。 開きたいページのURLを基に、取得方法を示すメソッドや、通信に必要な情報を添えてリクエストを送信します。
2. サイト側が要求に応じる。 Webサーバーが要求を受け、必要に応じてアプリケーションの処理へ渡します。
3. レスポンスが返る。 結果を表すステータスコード、ヘッダー、HTMLなどの内容が返されます。
4. ブラウザが画面を表示する。 ページに必要な画像やCSSなどを、別のリクエストで取得することもあります。

ステータスコードは、要求の結果を示す番号です。たとえば200は処理が成功した場合、404は対象が見つからない場合に使われます。閲覧を許可していない要求には、認証や権限に関係するエラーが返ることもあります。リクエストを送っただけで、必ず希望する情報が返るわけではありません。出典：HTTPの標準仕様・HTTP/1.1のメッセージ構造

ここでいうクライアントは、サーバーへ要求を送る側のことです。普段はブラウザが代表例ですが、クライアントは、人が画面を操作して使うものに限りません。この点は後ほど扱います。

GET・POSTの違いと誤解しやすい点

HTTPのリクエストには、サーバーへどのような処理を求めるかを示すメソッドが含まれます。代表的なのがGETとPOSTです。これらは送信先や通信経路の名前ではなく、同じHTTPの仕組みで使われる要求方法の違いです。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

HTTPの規格では、GETはサーバー上の状態を変更することを利用者が要求しない、「安全（safe）」なメソッドに分類されます。ただし、この「安全」は処理の意図についての技術用語であり、攻撃を受けない、あるいは脆弱性が存在しないという保証ではありません。 たとえばアクセスの記録が残ることまで禁止する意味でもありません。GETで受け取った値をサイト側が不適切に扱えば、問題の原因になり得ます。出典：RFC 9110：安全なメソッドとGET

POSTは、フォームの送信など、受け取った情報に応じた処理を求めるときによく利用されます。ただし、POSTなら必ずデータを保存するわけではなく、GETより危険なメソッドという意味でもありません。実際に何を行うかは、要求先のプログラムと、その利用者に許された操作によって決まります。出典：RFC 9110：POST

さらに、POSTで送れば自動的に暗号化される、という理解は誤りです。 通信を保護するかどうかは、GETとPOSTの違いではなく、主にHTTPS/TLSを利用しているかによります。GETでもPOSTでも、送信する情報の扱いとサーバー側の権限確認は必要です。

URL・クエリ・Cookie・ヘッダー・リクエスト本文

リクエストには、行き先の情報だけでなく、条件や入力値を載せる場所がいくつかあります。まず、次のURLを例に考えてみましょう。これは構造を説明するための架空のページ指定で、実在するWordPressサイトの動作を調べたものではありません。

https://example.com/news?category=notice

httpsは通信の方式、example.comは接続先のホスト名、/newsはページなどを指定するパスです。?以降のcategory=noticeはクエリと呼ばれ、表示対象を絞る条件などを渡すために使われます。クエリはGETだけの専用欄ではなく、POSTのURLにも付けられます。反対に、GETのURLに必ずクエリがあるわけでもありません。出典：URIの標準仕様・HTTPのメソッド仕様

リクエストに含まれる主な情報を整理すると、次のようになります。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

要求と応答は別方向／Cookieはヘッダーの一部

画像を拡大する ＋

図の内容をテキストで読む

ブラウザ・アプリなど

サイトのHTTP受信先

① リクエスト（要求）

ブラウザ・アプリなどから、サイトのHTTP受信先へ。

要求に含まれる情報

• メソッド

  GET・POSTなど

• 要求先

  URLのパスとクエリ

• ヘッダー

  Cookieはここ（任意）

• 本文

  必要な場合のみ

② レスポンス（応答）

サイトのHTTP受信先から、ブラウザ・アプリなどへ。

応答に含まれる情報

• ステータス

  例：200・404

• ヘッダー

  Set-Cookieは必要時のみ

• 内容

  HTML・JSONなど

注：HTTPの論理構成の図です。HTTP/2・HTTP/3の実際の通信形式を示すものではありません。

操作を許可するかどうかは受信側で判定します。URLのフラグメントは通常リクエストに送信されません。

Cookieが付かない通信もあります。

HTTPでは、クライアントのリクエストにメソッド・要求先・ヘッダーなどが含まれ、必要に応じて本文が付きます。サイト側は結果をレスポンスとして返します。Cookieはヘッダーで扱われ、すべての通信に必ず付くものではありません。

参考資料：RFC 9110：HTTP Semantics／RFC 9112：HTTP/1.1／RFC 6265：Cookie

Cookieはログイン状態の維持などに使われますが、Cookieが付いているだけで、その人が管理者だと証明されるわけではありません。サイト側でセッションが有効かを確認し、必要な操作権限も確かめる必要があります。WordPressのREST APIにもCookieを使う認証方法がありますが、認証できたことと、記事や設定を変更できることは別の判断です。出典：WordPress REST APIの認証・エンドポイントの権限設定

なお、URLの末尾に#sectionのような指定が付いている場合、その部分は通常ブラウザ内で位置を示すフラグメントで、HTTPリクエストの送信先情報には含めません。クエリとは役割が異なります。また、URLに付けたクエリはブラウザの履歴やサーバーのログなどに残る場合があるため、パスワードなどの秘密情報をURLに含めないことが重要です。出典：URIの標準仕様・RFC 9110：URIに含まれる機微情報への注意

ブラウザ以外のCLI・自動プログラムもHTTP通信を送れる

ページを見るとき、私たちは通常ブラウザの画面から操作します。しかし、HTTPの規格は「人がブラウザのボタンを押したときだけ要求できる」と定めているわけではありません。CLI（コマンドラインインターフェース）と呼ばれる文字入力中心の操作画面や、プログラムからもHTTPリクエストを送れます。

たとえば、curlはURLで指定した先と通信できるCLIツールです。Webサイトの監視サービスが正常にページを取得できるか確認したり、業務システムが許可されたAPIを通して情報を取得したりするのも、HTTPを使った正当な自動処理の例です。APIとは、ソフトウェア同士が決められた方法で機能やデータを利用するための入口を指します。出典：curl公式マニュアル・WordPress REST APIのリクエスト

一方、公開されているURLやAPIには、人が通常の画面から操作しなくても要求が届く場合があります。そのこと自体は、通信の仕組みとして不自然ではありません。画面にボタンが表示されていない、検索結果にURLが載っていない、といった理由だけで、サイト側が通信を受け付けないとは限らないのです。

だからこそ、ブラウザから送られたか、プログラムから送られたかだけで、正当な利用かどうかを判定することはできません。 必要な本人確認や権限の検査は、要求を受け取った側の処理で行う必要があります。公開されている閲覧用APIと、ログインや権限が必要な更新用APIを分けて設計するのも、この考え方に沿ったものです。出典：WordPress REST APIの認証・エンドポイントの権限設定

外部入力がPHPやWordPressで処理されるまで

では、届いた値はどこで使われるのでしょうか。第2章ではWebサーバーとPHP・WordPressの役割を説明しました。ここでは、リクエストに含まれた値が、プログラムで扱われるまでの流れに絞って説明します。

PHPには、URLのクエリ、フォームから送られた値、Cookieなどを受け取る仕組みがあります。たとえば、$_GETはクエリの値、$_POSTは対応する形式のPOSTフォームデータ、$_COOKIEはCookieの値を扱うためのものです。$_SERVERからはリクエストや実行環境に関する情報を取得できます。これらは、受け取った値が最初から正しいことや、利用者に操作権限があることを保証する仕組みではありません。出典：PHP公式：外部から渡る変数・PHP公式：定義済み変数

ここには形式による違いもあります。たとえば、POSTの本文をJSONというデータ形式で送った場合、通常のフォームデータと同じように自動で$_POSTへ入るとは限りません。PHPでは生の本文を読み取る方法があり、WordPressのREST APIでは、リクエストを表す仕組みを通じてメソッド・ヘッダー・パラメーターなどを扱います。どこに入力値があるかとアプリケーションがその値をどう取り出すかは、別々に確認する必要があります。出典：PHP公式：$_POSTの対象形式・WordPress REST APIのリクエスト

お知らせの表示条件を受け取る場合や、管理画面から記事の変更を求める場合を、概念的な処理順で整理すると次のようになります。

1. 要求が届く。 ブラウザや別のクライアントが、URL・メソッド・必要に応じたヘッダーや本文を送ります。
2. 要求先の処理が選ばれる。 Webサーバーの設定やWordPressのルーティング（URLなどから処理先を決める仕組み）によって、対応する処理へ進みます。
3. 入力が読み取られる。 クエリ、フォームの値、Cookie、ヘッダーなどから、必要な情報を取得します。
4. 入力と操作の妥当性が確認される。 値の形式が目的に合っているか、本人確認や権限確認が必要な操作か、その利用者に許可されているかを、処理に応じて確認します。
5. 許可された処理の結果が返る。 条件に応じて情報を表示・変更するか、受け付けられない要求としてエラーを返します。

これは理解のための概念図であり、すべてのサイトが五つの処理を独立して実装し、必ずこの順番で実行しているという意味ではありません。入力の検査方法も、実際に何を変更できるかも、処理ごとに異なります。また、画像などをWebサーバーから直接返す場合やキャッシュで応答する場合には、毎回PHPやWordPressが実行されるとは限りません。出典：WordPress REST APIのリクエスト・エンドポイントの権限設定・nginx公式のWebサーバー動作

WordPressのREST APIでは、URLの経路をルートと呼び、その経路とGET・POSTなどのHTTPメソッドに対応する処理をエンドポイントと呼びます。同じURLでも、情報を読む要求と変更する要求では、処理や必要な権限が異なる場合があります。独自のエンドポイントを作る際の公式資料でも、要求された操作を実行してよいか確認するpermission_callbackなどが説明されています。一般向けに情報を公開する処理なら認証を必要としない場合もありますが、記事の更新などには適切な権限確認が必要です。出典：WordPress公式：独自エンドポイントの作成

つまり、サイトに要求が届いたことは、処理の実行が許されたことを意味しません。 一方で、入力の扱い方や権限確認に不備があれば、意図しない処理につながる可能性があります。どの条件が揃うと脆弱性が実際の問題になるのかは、次の第4章で分けて考えます。

HTTPS/TLSで保護できること・できないこと

サイトのURLがhttps://で始まる場合、通常はTLS（Transport Layer Security）という技術を使って通信が保護されます。TLSは、通信内容を第三者に読まれにくくする機密性、途中での改変を検知する完全性、接続先の正当性を確認する仕組みを提供します。HTTPSは、その保護された通信の上でHTTPを利用するものです。出典：TLS 1.3の標準仕様・HTTPの標準仕様

たとえば、HTTPSでフォームを送信すると、その通信区間では、通常、リクエストの本文だけでなく、URLのパスやクエリ、HTTPヘッダーもTLSによって保護されます。これはGETかPOSTかとは無関係です。ただし、接続先のドメイン名など、通信の成立に関わる情報があらゆる環境で完全に隠されるわけではありません。また、ブラウザの履歴、サイト側のアクセスログ、送信先での保存状態まで、TLSが一律に保護してくれるわけでもありません。出典：RFC 9110：HTTPSの扱いとURIの注意・TLS 1.3の標準仕様

TLSによる保護は、そのTLS接続の両端の間に限られます。 たとえば、サイトの前段で要求を受けて内部へ中継するリバースプロキシでTLS接続を終え、その先へ別の接続で要求を渡す構成があります。その内部区間でもTLSを使うかどうかは、サイトの構成によります。HTTPSで接続できるという表示だけでは、サーバー内部の通信や保存情報のすべてが暗号化されていると断定できません。出典：TLS 1.3の標準仕様・HTTPの標準仕様・nginx公式：プロキシの役割

もう一つ、特に重要な限界があります。HTTPSは、サーバー側のプログラムに脆弱性がないことや、送信された操作が正当なことを保証しません。 TLSによって通信相手のサーバーを確認する仕組みと、WordPressの利用者を認証して操作権限を確認する仕組みも異なります。暗号化された通信で届いた要求でも、サーバー側では入力内容や権限を適切に扱う必要があります。出典：TLS 1.3の標準仕様・WordPress REST APIの認証・権限設定

ここまでで、外部からの情報がHTTPで届き、必要に応じてPHPやWordPressの処理に渡される流れがわかりました。次の第4章「脆弱性はどこに生まれ、何が揃うと攻撃が成立するのか」では、単に要求が届くことと、その要求によって実際に問題が起こることを区別します。

関連する説明：攻撃が成立する条件／TLSとCookieの運用上の対策
この章の目次へ・全体の目次へ

第4章

脆弱性はどこに生まれ、何が揃うと攻撃が成立するのか

脆弱性が公表されたこと、自社サイトでその脆弱性が悪用され得ること、すでに侵害されていることは、それぞれ別の話です。 脆弱性はソフトウェアや設定にある弱点ですが、攻撃が成立するかどうかは、問題のある処理が実際に使われているか、そこへ攻撃者が到達できるか、どのような環境・権限が必要かによって変わります。さらに、修正が適用されているかも確認しなければなりません。

この章でわかること

• PHP本体・WordPress本体・拡張機能・サーバー設定の違い
• 攻撃の成立条件：バージョン・到達経路・構成・権限
  • 「脆弱性あり」と「誰でも侵害できる」は同じではない
  • 修正版とベンダーのバックポートの考え方
• ログイン不要の攻撃と不正ログインは何が違うのか
• 脆弱性の実証・悪用試行・実被害を区別する
• CVE・CVSS・CISA KEVは何を示すのか

前章で説明したHTTP通信は、外部から情報が届く仕組みです。しかし、入力がサーバーへ届いただけで侵害が起こるわけではありません。ニュースを正しく読むには、「どこに弱点があるか」「どの条件で利用され得るか」「何が証拠として確認されているか」を分ける必要があります。出典：PHP開発元のセキュリティ情報・WordPress公式のセキュリティ指針

PHP本体・WordPress本体・拡張機能・サーバー設定の違い

WordPressのサイトは一つに見えても、脆弱性の発生場所は一つではありません。PHP本体はWordPressを動かすためのプログラム実行環境、WordPress本体は記事・ユーザー・設定などを扱うCMSの中心部分です。テーマは見た目やページの表示、プラグインは追加機能を主に担います。これらとは別に、WebサーバーやPHPの設定によって、意図しない公開や権限の問題が生じる場合もあります。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

この表は、典型的な問題の所在を整理したものです。「設定に問題があること」と「製品にCVE番号付きの脆弱性があること」は同義ではありません。 また、プラグイン側の処理がPHPの機能を使っていても、その原因がPHP本体の不具合とは限りません。原因となる部品と、影響を受けるサイト全体を分けて考えることが重要です。出典：WordPress公式「Hardening WordPress」・WordPress公式の独自APIと権限設定

修正する担当者も、問題の場所によって違います。たとえば、サーバー会社がPHPを管理し、制作会社がWordPressや拡張機能を管理している場合があります。ただし、実際の責任分担は契約やサービス形態次第です。WordPress本体を最新版にしたからPHP本体やすべてのプラグインも修正済み、とは言えません。 WordPress公式も、2026年10月に公表されたPHP本体の問題について、WordPress本体の更新とは区別して案内しています。出典：WordPress公式：PHPのセキュリティ更新について・PHP公式：継続的な更新

攻撃の成立条件：バージョン・到達経路・構成・権限

「対象の製品を使っているか」だけでは、攻撃の成立を判断できません。まず脆弱性情報が示す影響バージョンと、現に動いているソフトウェアや修正の適用状況を照らし合わせます。そのうえで、その脆弱な処理に攻撃者が到達できるか、特定の実行方式や機能・設定が必要か、利用者の権限を要求するかを考えます。

判断のために整理する主な観点は、次のとおりです。

• 対象製品・バージョンと修正状況：問題のある部品・系列に該当し、対処する修正が未適用なのか。
• 到達経路：問題のある機能が動いており、攻撃者がそこへ要求を届けられるのか。インターネットから届く場合も、ログイン後や内部ネットワークでしか届かない場合もあります。
• 実行環境・機能・設定：OS、PHPの実行方式、有効化された機能、設定などに追加の条件があるのか。
• 必要な権限や操作：ログイン不要なのか、特定の利用者権限が必要なのか、あるいは別の条件を満たす必要があるのか。
• 実際に生じる結果：条件が満たされた場合に、情報の閲覧・変更など、何が可能になると確認されているのか。

これはすべての脆弱性に五つの独立した条件が必ず必要だ、というチェックリストではありません。 認証不要で公開機能から成立する問題もあれば、特殊な設定や事前の権限を要する問題もあります。ある条件が欠ければその攻撃経路が成立しない場合でも、別の経路や別の弱点まで安全だと証明されたことにはなりません。条件の具体的な組み合わせは、個別の開発元アドバイザリで判断します。出典：PHP開発元：実行方式と条件の記載例・FIRST：攻撃条件と権限の評価項目

「脆弱性がある」と「侵害された」は別の判定

画像を拡大する ＋

図の内容をテキストで読む

• 脆弱性の公表情報

  対象製品・原因・成立条件・修正

• 自社で確認できる環境

  使用製品・設定・実行方式・権限

公表情報と自社環境を照合

脆弱性ごとの必要条件を照合

※5項目すべてが一律に必須なわけではありません

• 製品・バージョン
• 修正・バックポート
• 機能への到達
• 実行環境・設定
• 認証・権限

照合結果による3つの分岐

• 条件が合う場合

  当該経路で悪用され得る

• 条件が合わない場合

  当該経路の成立は限定的
  サイト全体の安全判定ではない

• 情報が足りない場合

  影響判定は未確認のまま

実際に侵害されたかどうかは、ログ・変更履歴・被害の証拠で別に調べる

脆弱性の公表だけでは、自社環境での成立や侵害の有無は決まりません。製品・修正・到達経路など、対象の脆弱性に必要な条件を照合し、実際の侵害はログや被害の証拠から別に確認します。

参考資料：PHP公式セキュリティアドバイザリ／Red Hat：バックポート／FIRST：CVSS v4.0

たとえば、同じPHPの版が表示されていても、その処理を呼び出す経路や実行方式によって、ある攻撃手法の成立状況は異なり得ます。一方、特定の実証方法が成功していないという情報は、すべての環境で影響がないことの証明ではありません。研究で確認できた範囲と、開発元が示す影響範囲は分けて読む必要があります。出典：PHP開発元のセキュリティアドバイザリ

「脆弱性あり」と「誰でも侵害できる」は同じではない

ある製品に脆弱性があるとは、その弱点を利用すると想定外の動作が起こり得る、ということです。それだけで「インターネット上の誰でも、すべての導入サイトを直ちに乗っ取れる」とは結論できません。必要な設定が有効なのか、公開されている処理へ届くのか、権限が必要なのか、利用可能な攻撃手法があるのかによって、結果は変わります。

逆に、成立条件が限定されているからといって、対応を先送りしてよいわけでもありません。サイトの構成を管理者が把握していない段階では、「該当しない」と「まだ確認できていない」は違います。 到達性や権限の条件を確認できるまでは、影響の有無を未確認として扱い、提供元・保守担当者と照合する必要があります。

さらに、攻撃できる状態と、すでに侵害された状態も別です。修正されていない脆弱性が見つかっても、侵害が発生したと断定する根拠にはなりません。反対に、後から修正が適用されても、その前に不正な変更が行われなかったことの証明にはなりません。異常が疑われる場合は、更新状況の確認とは別に、第12章の侵害時対応が必要です。

修正版とベンダーのバックポートの考え方

開発元が問題を修正したソフトウェアを公開すると、通常は修正版のバージョンが案内されます。ただし、修正版が公開されたことと、自社サイトでその修正が動作していることは別です。サービス提供元が独自にソフトウェアを配布・管理している場合、利用者に見える版番号だけでは判断できないこともあります。

その代表例がバックポートです。これは、新しい版で行われた不具合やセキュリティ上の修正を、配布元が管理する古い版へ取り込む方法をいいます。たとえば基になるPHPの版番号が以前のままでも、OSやホスティングの提供元が特定の修正を適用したパッケージを配布している場合があります。Red Hatは、バックポートを行う製品では、上流の版番号だけで脆弱性の有無を判定すると誤ることがあると公式に説明しています。出典：Red Hat：セキュリティ修正のバックポート

ただし、「古い版だから必ず未修正」も「ベンダー提供だから修正済み」も、どちらも正確ではありません。重要なのは、その製品の配布元が対象の脆弱性についてどの修正を提供し、その修正が実際の環境に適用されているかです。上流開発元のアドバイザリと、サーバー会社・OS配布元などの修正情報を区別して確認します。また、バックポートは対象として説明された修正についての話であり、古い系列のすべての弱点や、サポート終了に伴う問題が解消することを意味しません。出典：Red Hatのバックポート方針・PHP公式の更新に関する説明

ログイン不要の攻撃と不正ログインは何が違うのか

脆弱性の説明にある「認証不要」は、問題となる処理を利用する前にログインによる本人確認が必要ないという意味です。「認証」は利用者が誰かを確認する仕組みであり、「認可」はその利用者に操作を許してよいかを判断する仕組みです。公開ページの表示や一部の問い合わせ処理のように、認証なしで使える機能は正常なサイトにも存在します。問題になるのは、その公開機能の実装や権限の扱いに弱点がある場合です。出典：WordPress公式：REST APIの認証・独自エンドポイントの権限確認・OWASP：認証と認可の区別

一方、不正ログインは、盗まれた認証情報などを使い、正当な利用者になりすまして管理画面等へログインする行為です。ログインの仕組みを通過しているため、認証不要の脆弱性とは入口が異なります。すでにログイン可能な低権限ユーザーが、本来許されない操作を実行できる脆弱性もあります。これは「ログインが必要な脆弱性」であって、「不正ログイン」と同じ意味ではありません。

整理すると、ログインが必要かどうか、ログインした人に何を許すか、ログインした人物が本人かは異なる問いです。この違いを無視して「管理画面に強いパスワードを設定したから認証不要の弱点も防げる」と考えるのは誤りです。反対に、認証不要の脆弱性だけに注意して、認証情報の管理や権限設定を軽視することもできません。個別の攻撃手法とその結果は第5章で扱います。

脆弱性の実証・悪用試行・実被害を区別する

セキュリティのニュースでは、「脆弱性を発見」「攻撃コードを実証」「攻撃を観測」「悪用を確認」「企業で被害が発生」といった表現が並びます。これらは証拠が示す内容の違いであって、侵害へ向かって必ず順番に進む五段階ではありません。 研究による実証と現実の被害報告が同時に存在する場合もあれば、実被害が最初に発覚して問題が調べられる場合もあります。

表T02｜脆弱性に関する情報が示すこと・示さないこと

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

PoC（Proof of Concept、概念実証）は、ある問題が特定の条件で起こることを示す検証です。研究環境で再現できても、すべての公開サイトで同じ結果になるとは限りません。逆に、PoCが公表されていないことだけで悪用不可能とも判断できません。

攻撃試行の観測では、検知システムの記録を読んだ際に注意が必要です。悪用を狙った要求が送られたことと、要求が脆弱な処理へ届き、実際の侵害が完了したことは違います。たとえばAWSは2026年10月、調査用の観測環境（ハニーポット）でPHPに関連する悪用試行を捉えたと報告していますが、その試行が実際の組織の環境でも成功したかは不明と記しています。こうした観測結果を「攻撃に成功した企業が確認された」と言い換えてはいけません。出典：AWS：MadPotでの悪用試行の観測

一方、実在の組織で不正なファイルの設置などが確認されたという報告は、試行観測とは異なる重みを持ちます。IPAが2024年に発表したPHP関連の注意喚起には、国内の複数組織で不正なファイルが設置された事例が記されています。ただし、その事実から他のすべてのPHPサイトでも侵害が発生したとは言えません。被害の確認範囲と、一般的な影響条件は分けて読む必要があります。出典：IPA：PHPの脆弱性を狙う攻撃に関する注意喚起

また、「悪用が確認された」と「自社サイトが被害を受けた」は別の主張です。報告がないことも、攻撃が存在しない証明ではありません。日付についても、脆弱性が発見された日、公表された日、試行が最初に観測された日、被害が明らかになった日は一致するとは限りません。調査・報道で使われている動詞と日付を丁寧に確認することが大切です。

CVE・CVSS・CISA KEVは何を示すのか

脆弱性情報を読むときによく現れるのが、CVE、CVSS、CISA KEVです。どれも重要ですが、同じことを表す数字や一覧ではありません。

つまり、ニュースの内容は「CVEで何の問題かを特定し、CVSSで技術的な深刻度を読み、KEVなどで悪用の根拠を確かめ、自社への影響は対象条件と修正状況から判断する」という順に整理できます。どれか一つの番号だけで、危険性も侵害の有無も確定しません。脆弱性ごとの詳しい影響条件は第7章のPHP本体の事例と第8章のWordPress関連の事例、自社環境での具体的な確認方法は第9章で説明します。

関連する説明：攻撃手法の比較／PHPの具体的な事例／WordPressの具体的な事例
この章の目次へ・全体の目次へ

第5章

WordPress・PHPで起こり得る代表的な攻撃手法

攻撃の名前が違えば、問題が起こる場所も、攻撃者にできることも違います。 WordPress・PHPのセキュリティでよく耳にするRCE、SQLインジェクション、XSSは、いずれも深刻な結果につながる場合があります。しかし、RCEは主にサーバーでのプログラム実行、SQLインジェクションはデータベースへの問い合わせ、XSSは閲覧者のブラウザにおける処理が中心です。認証や権限に関する問題も、それらとは別の観点で理解する必要があります。

この章でわかること

• リモートコード実行（RCE）とサーバー上の権限
• SQLインジェクションとデータベースへの影響
• クロスサイトスクリプティング（XSS）と閲覧者側の被害
• 認証回避と権限昇格：本人確認と操作権限の違い
• ファイルアップロード・読み込み処理の不備
• 不正管理者・バックドア・ファイル改ざん
• 攻撃手法ごとの成立条件と主な被害の比較

ここでは、何が原因でその攻撃が成立し、どこに影響が及び、どの対策が有効なのかを整理します。以下は一般的な仕組みの説明です。特定のサイトに脆弱性がある、攻撃が成功した、実際に被害が出たという調査結果ではありません。出典：OWASP：SQLインジェクション対策・OWASP：XSS対策・WordPress公式：権限確認

リモートコード実行（RCE）とサーバー上の権限

RCE（Remote Code Execution：リモートコード実行）とは、遠隔からの操作をきっかけに、攻撃者が意図したプログラム上の処理をサーバー側で実行できてしまう問題です。 たとえば、Webサイトに届いた情報を、単なるデータとして扱うべきところでプログラムの命令として解釈してしまう実装が原因になる場合があります。PHP本体の不具合や、WordPressのテーマ・プラグインが利用する危険な処理など、原因となる箇所は一つに限られません。出典：MITRE：コードインジェクション・OWASP：OSコマンドインジェクションの防御

ここで重要なのが、「遠隔から実行できる」と「ログインせず実行できる」は同義ではないことです。公開機能を通じて認証不要で成立する問題もあれば、ログインした利用者や特定の権限を持つ人にしか届かない機能が前提になる場合もあります。問題のある処理まで到達できること、必要な設定や実行環境に該当することなど、成立条件は個別に異なります。

RCEが成立した場合、サーバー上のファイルの閲覧・変更、別のプログラムの実行、サイトの動作への干渉などが起こり得ます。ただし、RCEの成立だけで、サーバー全体の最高権限を奪われたとはいえません。 多くの環境ではPHPの処理は、OS上の特定の利用者に与えられた権限で動いており、実行可能な操作はその利用者の権限、ファイルのアクセス許可、サーバー構成などに左右されます。データベースへ接続できるかも、利用可能な接続情報や権限次第です。OSの管理者権限まで到達するには、追加の弱点や設定上の問題が必要な場合があります。出典：PHP公式：ファイルシステムのセキュリティ・WordPress公式：セキュリティ強化

防御の中心は、RCEを引き起こす原因となった脆弱性を修正することです。外部入力を命令として扱ってしまう不備では、命令とデータを分離する設計も必要です。一方、PHP内部のメモリ処理の不具合など、アプリケーション側の入力のエスケープだけでは修正できない原因もあります。外部プログラムを呼び出す必要がある場合は、呼び出す処理と受け付ける値を限定し、命令の構造に入力が入り込まない方法を選びます。出典：OWASP：コマンド実行に関する防御指針・PHP開発元：メモリ処理に起因する脆弱性の例

加えて、PHPを実行する利用者に、必要以上のファイル変更権限を与えないことは、問題発生時の影響範囲を抑える手段になります。アクセス制限やWAF（Webアプリケーションへの通信を検査する仕組み）が一部の悪用を妨げることはあっても、脆弱な処理そのものを修正する代わりにはなりません。出典：OWASP：最小権限による多層防御・PHP公式：ファイルアクセス権限

SQLインジェクションとデータベースへの影響

SQLインジェクションは、入力された値がデータベースへの命令文の一部として解釈され、意図しない問い合わせや変更が行われ得る問題です。 SQLは、データベースから情報を取得したり、データを変更したりするための言語です。たとえば、サイト内検索で渡された語句をプログラムがSQL文へ不適切に組み込むと、検索語のはずだった情報がSQLの構造に影響することがあります。ここでいう検索機能は仕組みを説明するための架空の例であり、実際の被害事例ではありません。出典：OWASP：SQLインジェクション対策

成立するためには、外部から操作できる値が問題のあるSQL処理に届き、その処理が値を適切に分離せず問い合わせに組み込んでいる必要があります。入力項目があるだけ、あるいはデータベースを使っているだけでは、SQLインジェクションの成立を意味しません。ログインの要否や、問題のある処理が実行される条件も実装によって異なります。

想定される影響先は主にデータベースです。結果として、一部の情報が意図せず読み出されたり、データが書き換えられたり、問い合わせが正常に動かなくなったりする可能性があります。しかし、SQLインジェクションに成功しても、データベース全件を必ず閲覧・削除できるわけではありません。 到達したSQL処理の内容、アプリケーションが利用するデータベースアカウントの権限、データベース製品や設定などで実行できる範囲は変わります。サーバー上で任意のプログラムを実行できるかどうかも、SQLインジェクションという名称だけでは決まりません。出典：OWASP：SQLの構造と権限の分離

基本的な対策は、SQLの命令構造と入力値を分けて扱うことです。プレースホルダーと呼ばれる、値を安全に渡すための仕組みを利用し、必要なデータ型や入力条件も確認します。WordPressにも、データベース問い合わせを組み立てる際に使う wpdb::prepare() が用意されています。ただし、その機能を使っている箇所があるからといって、サイト内のすべての問い合わせが安全だと証明されたわけではありません。プログラム側の適切な実装に加え、データベースの利用者には必要最小限の権限を与えることが重要です。単純な文字列の置換や、攻撃らしい文字だけを禁止する方法に全面的に頼るのは適切ではありません。出典：OWASP：パラメーター化と最小権限・WordPress公式：wpdb::prepare()

クロスサイトスクリプティング（XSS）と閲覧者側の被害

XSS（Cross-Site Scripting：クロスサイトスクリプティング）は、Webページが表示・処理する情報に悪意あるスクリプトが紛れ込み、閲覧者のブラウザで実行され得る問題です。 スクリプトとは、ここでは主にブラウザ上で動くJavaScriptなどのプログラムを指します。サーバーでPHPの任意コードを動かすRCEとは、まず実行場所が異なります。出典：OWASP：XSS対策

原因として典型的なのは、投稿内容や検索結果などに含まれる信用できない値を、ページのHTMLやJavaScriptへ、表示場所に合った安全な処理をせず組み込むことです。保存済みの投稿などを後から表示したときに影響するものは「格納型」、リクエストの内容が応答ページに反映されるものは「反射型」、ブラウザ側のJavaScriptが値を不適切に扱って起きるものは「DOMベース」と呼ばれます。DOMは、ブラウザがページの構造を扱うための仕組みです。

ただし、格納型・反射型は値が保存・応答される経路に、DOMベースはブラウザ側で値が危険な処理へ渡される仕組みに着目した呼び方です。互いに排他的な分類ではなく、重なり合う場合があります。 どの種類でも、問題のあるページを閲覧することなどが影響発生の条件になり得ます。出典：OWASP：XSSの発生箇所と対策・OWASP：XSSの分類軸

被害は、閲覧者がそのサイトを利用する際の権限や、ブラウザで実行されたスクリプトに許された操作によって変わります。たとえば、悪意ある表示への誘導や、ログイン中の利用者としての意図しない操作につながる可能性があります。管理権限を持つ担当者が問題のある画面を見る場合と、ログインしていない一般の閲覧者が見る場合とでは、影響が違うこともあります。XSSが存在するだけで、サーバー上の任意コード実行や管理者権限の取得が完了したとはいえません。 ブラウザのCookieに読み取り制限を付ける対策にも意味はありますが、それだけですべての不正操作を防げるわけではありません。出典：OWASP：XSSの影響と多層防御

防御では、外部から来た値を確認・整形したうえで、HTML本文、属性、URL、JavaScriptなど、表示先の文脈に合わせて適切にエスケープすることが基本です。エスケープとは、特別な意味を持つ文字を、その場で命令として解釈されない形にして出力する処理を指します。装飾を許した投稿のようにHTML自体を受け付ける場合は、安全な要素・属性だけを残す処理も必要になります。WordPress公式も、入力値のサニタイズ（目的に合う形への整形）と、画面へ出す際のエスケープを別々に説明しています。出典：WordPress公式：データのサニタイズ・WordPress公式：出力のエスケープ

ブラウザ側でページを書き換える場合も、信用できない値をコードやHTMLとして解釈する処理に渡さず、単なる文字列として表示するなど、用途に合う安全な処理を選びます。CSP（Content Security Policy）というブラウザの読み込み・実行制限は被害を抑える補助策ですが、出力処理の不備を放置してよい理由にはなりません。出典：OWASP：安全な出力先とCSPだけに依存しない対策

認証回避と権限昇格：本人確認と操作権限の違い

重要なのは、画面にボタンを出さないだけで操作が禁止されるわけではない、という点です。WordPressの独自機能やREST APIでは、実際に処理を実行する場所で、要求元の本人確認と操作権限を適切に確認する必要があります。操作権限の判定には、WordPressが用意する権限確認機能や、REST APIの各処理のpermission_callbackが使われます。出典：WordPress公式：REST APIの権限確認

CSRF（クロスサイトリクエストフォージェリ）は、利用者のブラウザに、本人が意図しない操作の要求を送らせる攻撃です。たとえば、ログイン状態を示すCookieが送られることを悪用し、本人の操作であるかのように処理させます。フォームなどで使われるWordPressのnonce（ノンス）は、その対策を助ける確認用トークンです。ただし、本人確認や操作権限の検査を代わりに行うものではありません。 また、WordPressのnonceは有効期間内に再利用され得るため、一回限りの値や再送防止を保証する仕組みとは区別します。出典：WordPress公式：nonceの役割と限界

こうした問題への対策は、ログイン機能の保護だけでは完結しません。操作ごとに権限を確認し、必要最小限の権限を割り当て、利用者から直接届く要求にも同じ制約を適用する必要があります。一方、本人確認と操作権限を厳密に管理していても、SQLインジェクションやXSSなど、別の種類の処理上の弱点までなくなるわけではありません。出典：OWASP：最小権限・拒否を基本とする認可

ファイルアップロード・読み込み処理の不備

ファイルを送信できる機能があること自体は、脆弱性ではありません。 会社の問い合わせフォームで画像を添付したり、WordPressへ写真を登録したりする処理は、正当な機能です。問題になるのは、受け付けるファイルの種類、内容、保存先、公開方法、実行の可否などが不適切に扱われる場合です。出典：OWASP：ファイルアップロードの安全設計

たとえば、本来は画像だけを受け付ける機能で、ファイル名の拡張子や送信者が申告した形式だけを信用し、実際の内容を十分に確認しなければ、意図しないファイルが保存されることがあります。さらに、そのファイルがWebからアクセス可能で、サーバーがプログラムとして実行する設定であれば、別の問題へ発展する場合があります。反対に、ファイルを保存できたという事実だけで、サーバー上のコード実行に成功したことにはなりません。 保存された場所、公開設定、Webサーバーの処理方法、ファイル権限などが影響します。出典：OWASP：保存場所・種類・実行制限・PHP公式：ファイルアクセスの制御

防御では、業務に必要なファイル種別のみ許可し、拡張子・ファイルの内容・サイズなどを複数の方法で検証します。保存時には安全な名前に置き換え、できる限りWebから直接実行できない場所へ保存し、必要に応じて別の仕組みで配信します。重要なのは一つの検査に頼らず、保存領域のアクセス権限とサーバー設定を合わせることです。ウイルス検査などの追加対策も有用ですが、悪意ある内容のすべてを完全に検出できるわけではありません。出典：OWASP：多層的なファイル検査

別の問題として、ファイルの読み込み先を利用者の入力から不適切に決める処理があります。たとえば、表示する資料の名前を指定する機能で、想定外の場所にあるファイルまで読み取れてしまうなら、パストラバーサル（許可された範囲の外にあるファイルへ到達する問題）などが疑われます。また、PHPのファイル読み込み・取り込み処理で、信用できない値が対象の指定に使われると、構成と条件次第では意図しないプログラムの取り込み・実行につながることもあります。ただし、ファイルの情報が漏れることとRCEは同じ結果ではなく、読み込みに問題があるだけで必ずコードが実行されるわけではありません。 対象をあらかじめ許可した一覧から選ぶ設計や、公開・読取権限の限定が基本です。出典：MITRE：パストラバーサル・PHP公式：ファイルシステムのセキュリティ

不正管理者・バックドア・ファイル改ざん

見覚えのない管理者アカウント、不審なプログラム、不正に変更されたファイルは、攻撃の「入口」であるとは限りません。何らかの方法で侵入された後、攻撃者が操作を続けたり、再びアクセスしたりするために残したものとして現れる場合があります。前述したRCEや権限の問題、不正ログインなどと、侵害後に行われた操作を分けて理解する必要があります。出典：MITRE ATT&CK：Webシェル・MITRE ATT&CK：アカウントの不正操作

不正管理者アカウントが作られると、そのアカウントに付与されたWordPress内の操作権限を通じて、サイトの設定やコンテンツに影響が出るおそれがあります。ただし、WordPressの管理者権限は、OSやサーバーの最高権限と同じではありません。 できることはWordPress側の権限と、導入済み機能・サーバー側の制約により異なります。出典：WordPress公式：権限の仕組み

バックドアとは、正規の確認や管理の経路を避け、後から不正なアクセスを続けるために設けられる仕組みの総称です。Webサーバー上に置かれ、外部から操作を受け付ける不正なスクリプトをWebシェルと呼ぶことがあります。MITRE ATT&CKは、Webシェルを侵入後のアクセス維持に使われる手法として整理しています。また、ファイル改ざんには、ページの表示を変えるものだけでなく、通常の動作を保ちながら別の不正な処理を加えるものもあり得ます。出典：MITRE ATT&CK：Webシェルによるアクセス維持・WordPress公式：侵害時の兆候

ただし、未知のファイルや管理者が見つかっただけで、悪意あるものと断定することも適切ではありません。 正式な保守作業や未共有の追加機能という可能性もあるため、作成・変更の経緯、管理者の記録、関連する通信などを調べる必要があります。実際に侵害が疑われる場合、原因も範囲も把握しないまま不審なファイルだけを削除して「復旧完了」と扱うと、別の不正な入口やアカウントを見落とすおそれがあります。状況の記録と必要な証拠の保全を優先してください。初動の詳しい手順は第12章で説明します。出典：WordPress公式：ハッキングされたサイトへの対応

攻撃手法ごとの成立条件と主な被害の比較

同じ「不正アクセス」でも、何をきっかけに、どこで処理が変わり、誰の権限で影響が生じるかを分けると、必要な対策を考えやすくなります。次の表T03は、OWASP、WordPress、PHP、MITREなどの一次資料を基に、代表的な違いを整理した本記事独自の比較表です。公式機関がすべてのサイトに一律適用する危険度判定表ではなく、行の順番にも危険度の意味はありません。各手法の原因・条件と、対策で防げないことも合わせて比較します。

表T03｜代表的な攻撃手法の原因・条件・影響・対策の比較

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

表で示した被害は、条件が揃った場合に起こり得る範囲であって、実際に発生した被害を列挙したものではありません。たとえば「SQLインジェクションの攻撃を受けた」という通信の記録だけでは、データベースの情報が取得されたと結論できません。XSSのあるページが存在していても、誰がそのページを開き、どの処理が実行されたかは別の確認事項です。同様に、不審な管理者やファイルが見つかった場合も、どの弱点が最初の侵入に使われたかは調査しなければわかりません。

攻撃手法は単独で終わるとは限らず、複数の問題が組み合わされる場合もあります。 だからこそ、攻撃名だけでサーバー全体の支配や情報流出を断定せず、処理された場所、成立条件、利用できた権限、確認された証拠を分けることが大切です。攻撃者の目的と企業・閲覧者への被害の連鎖は第6章で、実在する個別の脆弱性と修正状況は第7章・第8章で扱います。

関連する説明：攻撃者の目的と被害／防御策の効果と限界
この章の目次へ・全体の目次へ

第6章

なぜ小さな会社のWordPressサイトも攻撃されるのか

小規模な会社や店舗のWebサイトでも、攻撃者の目的に合えば攻撃の対象になり得ます。 攻撃者が欲しいのは、その会社の売上や知名度とは限りません。公開サイトにページを勝手に設置すること、訪問者を別の場所へ誘導すること、保存された情報を手に入れること、サーバーの通信や計算能力を利用することにも価値を見いだす場合があります。出典：WordPress公式の侵害被害例・Googleのハッキングされたコンテンツの説明・MITREの資源悪用の分類

この章でわかること

• 攻撃者によるインターネット上の自動探索
• SEOスパムと無関係な商品・広告ページの設置
• フィッシング・詐欺サイト・不正転送への悪用
• 顧客情報・メールアドレス・認証情報の窃取
• 迷惑メール・マルウェア配布・サーバー資源の不正利用
• 他組織への攻撃中継と第三者への二次被害
• 改ざん・業務停止・金銭要求・企業信用への影響
• サイト運営者が被害者でも二次被害が生じ得る理由

そのため、閲覧者が少ないサイトだから安全とも、WordPressを使っているサイトが必ず侵害されるともいえません。攻撃の対象として見つかること、脆弱性などを悪用する試みがあること、実際に不正な変更や情報の持ち出しが起こることは、それぞれ別の段階です。この章では攻撃手法そのものより、攻撃者の目的から企業と第三者への影響までの因果関係を確認します。

攻撃者によるインターネット上の自動探索

攻撃者は、必ずしも会社名を知ったうえで一社ずつ狙うわけではありません。 インターネットに公開されたシステムへ自動化したプログラムで接続を試し、特定のソフトウェア、機能、設定の特徴を探す場合があります。こうした活動が「探索」や「スキャン」です。MITRE ATT&CKは、公開された機器やアプリケーションの情報を集める能動的なスキャンと、脆弱性の条件に合いそうな対象を調べるスキャンを、攻撃に先立つ活動として整理しています。出典：MITRE：Active Scanning・MITRE：Vulnerability Scanning

例えば特定のソフトウェアや修正前の機能を探す活動では、会社の規模よりも、外部から到達できる入口があるか、返ってくる情報が探索条件に合うかが重要です。小さな店舗のサイトが、大企業のサイトと同じ探索の範囲に入ることも考えられます。ただし、見つかった先で攻撃が成立するかどうかは、製品の状態、設定、認証、権限、通信の制限、攻撃者の手段によって異なります。

攻撃者が、探索で見つけたサイトを利用したいと考える理由も一つではありません。不正ページを公開する場所が欲しいのか、別の攻撃へつながる通信の経由地が欲しいのか、利用できるデータやアカウントを探しているのかによって、侵害後の行動は変わります。反対に、特定の企業や取引先について詳しく調べて狙う攻撃もあります。「すべてが無差別攻撃」という説明も正確ではありません。

アクセスログに不審なリクエストが残っていても、侵害成功の証明にはなりません。 サーバーが要求を拒否したのか、脆弱な処理に届いたのか、その後に許可していない変更が行われたのかを分ける必要があります。

公開されたWeb環境では、脆弱性の悪用による実際の侵害被害も報告されています。IPAが2024年に公表した国内事例と、そこから確認できる被害の範囲は、後述の「他組織への攻撃中継と第三者への二次被害」で説明します。出典：IPA：PHPの脆弱性を狙う攻撃について

探索されたこと・不正操作の成立・被害は、それぞれ別の段階

画像を拡大する ＋

図の内容をテキストで読む

A｜探索から成立条件の照合まで

自動探索は企業規模・知名度に関係なく、公開されたサイトを候補にし得る

1. ① インターネット上の自動探索

   公開サイトや機能を探す

2. ② 公開サイトが候補になる

   候補と侵害成立は別

3. ③ 悪用に必要な条件を照合

   版・設定・到達経路・権限を確認

条件の照合後は、別々の経路に分岐

• 条件不一致・アクセス拒否・悪用不成立

  この経路の不正操作は成立しない。別経路の不存在やサイト全体の安全は意味しない

• 条件が揃い、不正操作が成立した場合

  ここから先も、特定の不正利用や実害が必ず起こるとは限らない
  この分岐のみ、次のBの可能性へ。

B｜成立後に起こり得る不正利用（5つの例）

並列の可能性を示すもの。5つすべての発生や一律の順序を意味しない。

• 1無断ページ・SEOスパム

• 2偽ページ・不正転送

• 3情報の不正閲覧・持ち出し

• 4メール・サーバー資源の不正利用・攻撃中継

• 5改ざん・業務妨害

※ 同じ事案で複数が重なる可能性はあるが、どれも必然ではない

個々の結果と、追加条件・証拠を確認

C｜実際の影響は、各結果と追加の条件・証拠に応じて判断

• 運営企業への影響（起こり得る例）

  信用低下、復旧・調査負担、業務停止、利用制限など。具体的な影響は個別に確認

• 閲覧者・第三者への影響（条件付き）

  偽画面への入力や不正通信を受けた場合など。情報流出・第三者被害を自動的に断定しない

※ 探索・試行の記録だけでは侵害成立を証明できない。件数・確率・被害額は示していない。

図D04｜探索から被害に至るまでには複数の条件があります。矢印は起こり得る関係を示し、不正操作や情報流出、第三者被害が必ず生じることを意味しません。

参考資料：MITRE：Active Scanning／MITRE：Vulnerability Scanning／MITRE：Resource Hijacking／MITRE：Proxy／IPA：CVE-2024-4577への攻撃

SEOスパムと無関係な商品・広告ページの設置

攻撃者がサイトを利用する目的の一つは、自分の宣伝や集客に、他人のWebサイトを勝手に使うことです。 例えば企業サイトの配下に、その会社が扱っていない商品の紹介、販売先へのリンク、検索キーワードを並べたページなどを設置し、検索エンジンから人を集めようとする行為があります。このような不正利用はSEOスパムと呼ばれます。SEOは本来、検索利用者に適切な情報を見つけてもらうための改善全般を指します。無断で加えられたスパムと、企業が許可して行う通常のSEO施策や広告掲載を混同してはいけません。出典：Google：スパムに関するポリシー・MITRE：SEO Poisoning

攻撃者が使おうとするのは、正規サイトに属するURLや、検索でそのサイトを見つけてもらえることです。侵害によって記事やテーマの内容を変更できたり、新たなページを作成できたりすると、無関係な宣伝を正規サイトの一部のように見せられます。閲覧者がトップページを見ても気づかず、検索から入ったときだけ不正な内容が表示される場合もあります。Googleは、許可なく追加されたページ、隠しリンク、閲覧条件に応じた表示の切り替えなどを、ハッキングされたコンテンツの例として挙げています。出典：Google：ハッキングされたコンテンツ

運営企業には、意図しない商品を扱っていると誤解される、苦情や問い合わせが届く、会社名と無関係な検索結果が結びつくといった影響が考えられます。閲覧者は、正規企業が保証した情報と思い込んでリンク先へ進み、詐欺や危険なページへ誘導されるかもしれません。

ただし、不正ページが存在するだけで、Googleにインデックス登録されたことや、正規ページの検索順位が下がったことまで確定しません。 インデックス登録は、検索エンジンがページを検索用のデータに取り込むことです。Googleは、スパムに関するポリシー違反が検出された場合に順位が下がる、または検索結果に表示されなくなることがあると説明しています。また、マルウェアやフィッシングが検知された場合は訪問前に警告が表示され、検索からの流入に影響することがあります。個別サイトで何が起きたかは、不正ページそのもの、検索結果やSearch Consoleの情報、警告の有無などから別々に判断します。出典：Google：スパムに関するポリシー・Google：検索トラフィック減少の調査

フィッシング・詐欺サイト・不正転送への悪用

正規サイトのURLが、偽のログイン画面や詐欺ページへの入口に悪用される場合があります。 「フィッシング」は、信頼できる組織やサービスを装い、パスワードなどを利用者に入力させようとする詐欺の手口です。攻撃者は、不正に追加したページを正規サイト内に置いたり、既存ページへ別のサイトに移動させる処理を埋め込んだりして、閲覧者を誘導しようとします。サイトが侵害されていなくても別の手段で偽URLを案内する詐欺はありますが、ここでは侵害されたサイトの悪用を扱います。出典：Google：ハッキングされたコンテンツ・WordPress公式：侵害による転送の例

不正転送は、運営者が意図していない別のページやドメインへ閲覧者を移すことです。目的には、偽画面への誘導、詐欺商品の販売、マルウェア配布先への送客などがあります。正規の企業サイトから移動したために、閲覧者が警戒しにくくなることも考えられます。ただし、サイト移転のための正規リダイレクトや、会社が設定した予約サービスへの移動は不正転送ではありません。

Googleの資料は、検索結果から訪れた場合だけ不審なページへ移動し、同じURLに直接アクセスすると通常のページが表示される例も示しています。つまり「自分のパソコンでは正常に見える」ことだけで、不正な転送がないとは言い切れません。出典：Google：不正なリダイレクトの例

運営企業は顧客からの苦情、検索上の警告、サイトへの信頼低下に直面するかもしれません。閲覧者には、偽画面へ個人情報や認証情報を入力してしまう危険が生まれます。ただし、不正転送の確認と、利用者が実際に情報を入力したこと、その情報が攻撃者に届いたことは別です。 不正な転送先の存在、アクセス状況、偽画面での送信、当事者の申告など、分かった事実に合わせて被害を表現しなければなりません。

顧客情報・メールアドレス・認証情報の窃取

顧客情報が盗まれるかどうかは、サイトがどの情報を保存し、侵害した側がどこまでアクセスできるかで変わります。 会社概要だけを掲載するサイトと、予約情報、問い合わせ内容、会員データ、注文履歴などを保存するサイトとでは、守るべき情報が異なります。WordPress自体に顧客情報を保存していなくても、外部のフォームや業務サービスと連携するための設定情報がサーバーに置かれている場合があります。一方、外部サービスで管理されているデータが、WordPressへの侵害だけですべて読めるわけではありません。

攻撃者が欲しがるのは、氏名や連絡先を使った詐欺、メールアドレスを利用する迷惑メール送信、盗んだ認証情報による別のサービスへの不正アクセスなどにつながる材料です。データベースを不正に読める状態、権限を奪われた管理者アカウント、読み取りを許された設定ファイルなど、情報に近づく経路は一つではありません。しかし、利用できるかどうかは、実際の保存場所、データベースの接続権限、サーバーのアクセス権限、外部サービス側の認証などに左右されます。出典：WordPress公式：侵害に伴う情報漏えい例・OWASP：データベースの権限限定・WordPress公式：保護の基本

例えば問い合わせ履歴を保存していても、不正な要求がそのデータに届かなければ、情報窃取が成立したとはいえません。逆に、情報へアクセスできる権限を奪われた場合は、画面が正常でも情報を閲覧・取得され得ます。WordPressのログイン用パスワードは通常、元の文字列をそのまま保存するのではなく、パスワードから計算した照合用の値（ハッシュ）で管理されます。ただし、ハッシュなどの認証関連データが不正に取得された場合も、状況に応じた調査が必要です。「パスワードに関係する保管データが読まれた」と「元のパスワードが判明した」も別の事実です。出典：WordPress公式：パスワードのハッシュ生成

特に重要なのは、「情報を読める可能性」と「外部へ持ち出された事実」を分けることです。MITRE ATT&CKは、侵害した環境から情報を盗み出す行為を「情報の持ち出し（エクスフィルトレーション）」という戦術に整理しています。その経路の一つが、攻撃者の指示や応答に使うC2（Command and Control）通信を通じた送信です。C2とは別の経路で持ち出す場合もあるため、調査では通信経路を一つに決めつけません。不正なデータ取得や送信を裏付けるログ、保存された転送物、外部で確認された情報などは判断材料になります。ただし、送信記録がないことだけで流出がなかったと証明できるわけではなく、通信量だけで内容も確定できません。運営企業の調査負担に加え、影響を受けた顧客や従業員には、なりすましや不審な連絡といった二次被害が及び得ます。出典：MITRE：Exfiltrationの全体分類・C2通信を使う手法

迷惑メール・マルウェア配布・サーバー資源の不正利用

攻撃者は、サイトの中身ではなく、サイトが利用できる通信機能やサーバー資源を目的にすることもあります。 例えば、メール送信機能や認証情報を悪用できれば、運営者の意図しないメールが外部へ送られる場合があります。また、公開ページやダウンロードファイルが書き換えられると、マルウェア（利用者の機器や情報に害を及ぼす不正なソフトウェア）へ誘導するリンクや、不正なファイルの配布に使われるおそれがあります。出典：WordPress公式：不正なリンク・スクリプト・MITRE：Drive-by Target

攻撃者の利得は、宣伝や詐欺のメッセージを多くの人へ届けること、偽の案内から個人情報を集めること、別の端末への侵入機会を得ることなどです。仮に会社のドメインやメール機能が悪用されれば、受信者はその会社から来た正規の連絡だと誤認するかもしれません。運営企業は、送信制限や迷惑メール扱い、問い合わせの増加、サーバー事業者からの確認など、通常業務への影響を受けることがあります。ただし、WordPressを設置しただけで大量のメールを任意に送れるわけではありません。 メール送信設定、認証情報、利用できる送信サービス、通信や送信数の制限によって変わります。

サーバーのCPU（計算処理を担う装置）、メモリ、ネットワーク帯域、クラウドサービスの利用枠なども悪用の対象です。MITRE ATT&CKは、侵害した環境の計算能力を無断利用する行為、通信帯域を転用する行為、メッセージ送信機能を大量送信へ使う行為を、資源の不正利用として整理しています。実際にこれらが行われれば、サイトの表示が遅くなる、利用枠に達する、契約条件によって追加費用が生じるといった影響が考えられます。出典：MITRE：Resource Hijacking

一方、不正なファイルが置かれただけで、訪問者の端末にマルウェアが感染したとはいえません。 配布先への誘導、ファイルの取得、実行、端末側の条件は区別が必要です。迷惑メールなら送信履歴、マルウェア配布なら改ざんされたファイルやページと配信の記録、資源悪用なら異常な処理や利用量の記録など、確認する証拠も目的ごとに異なります。

他組織への攻撃中継と第三者への二次被害

侵害されたWebサーバーが、別の組織を攻撃する通信の中継地点に使われることもあります。 この場合、攻撃者が欲しいのは元のサイトに保存された情報ではなく、そこから外部に接続できる経路や、別の機器から見ると正規サーバーに見える送信元です。通信を中継する仕組みを「プロキシ」と呼びます。MITRE ATT&CKは、攻撃者が自らの直接的な接続先を隠すなどの目的でプロキシを用いる手法を整理しています。出典：MITRE：Proxy

Webシェルは、Webサーバーを外部から不正に操作するために使われ得るプログラムです。設置されると、サーバー上で許された範囲の操作や通信に悪用される場合があります。ただし、Webシェルの存在だけで、外部への自由な通信や他組織への攻撃中継まで成立したとはいえません。 サーバー上の実行権限、外向きの通信制限、接続先への到達性などが関わります。出典：MITRE：Web Shell

国内の実被害を示す一次資料として、IPAは2024年7月、PHPの脆弱性CVE-2024-4577が悪用され、国内の複数組織のWebサービスにWebシェルが設置されていたと報告しました。ここまでが、この報告で確認された個別の侵害の範囲です。 IPAは別に、Webシェルが組織内への侵入や他組織への「踏み台」に悪用され得ること、攻撃通信を中継するORB（Operational Relay Box）と呼ばれる状態への注意を説明しています。この報告だけから、Webシェルが設置された複数組織すべてで他社への攻撃中継まで成功したと断定してはいけません。 また、これはPHPを利用するWeb環境の事例であり、被害サイトがWordPressであったとも断定できません。出典：IPA：国内Webサービスの実被害と中継悪用の注意

中継が実際に起きれば、元のサイトの運営会社は不審な通信の送信元として問い合わせや調査の対象になり、ネットワークを制限される場合があります。接続を受けた別組織では不正なアクセスが記録され、さらに侵害へつながるおそれもあります。しかし、送信元IPアドレスにその企業のサーバーが記録されただけでは、誰が操作したか、通信先で何が成功したかまでは確定しません。中継プログラム、通信ログ、接続先の状況などを合わせて判断する必要があります。

改ざん・業務停止・金銭要求・企業信用への影響

サイトが侵害された場合、会社にとっての被害は「ページの見た目がおかしくなる」ことだけではありません。 代表的なのは、正規の文章・画像・リンクが勝手に変えられる「改ざん」、必要なページやフォームが使えなくなる「業務停止」、不正なコンテンツによって顧客が離れたり、取引先に不安を与えたりする「信用への影響」です。WordPress公式も、不正なリンクの埋め込み、データの改ざん・破壊、不正ファイルの追加、サイトが正常表示されない状態などを侵害の例として挙げています。出典：WordPress公式：侵害被害の例

例えば予約フォームが利用できなくなれば、受付の機会を失い、担当者が電話やメールで代替対応する必要が生じるかもしれません。サイトの内容が無関係な販売広告に置き換われば、訪問者にはその会社が掲載を認めているように見えることもあります。Googleなどが危険なサイトとして警告を表示した場合には、検索経由の訪問が減る要因になり得ます。ただし、売上の減少額や検索順位への影響は、事業内容、発生時期、実際の表示状況によるため、一律には見積もれません。出典：Google：セキュリティ上の警告と検索流入

侵害の種類によっては、ファイルやデータを利用不能にして、元に戻すことと引き換えに金銭を要求する行為も考えられます。MITRE ATT&CKは、データを暗号化してアクセスできなくする行為と、復号鍵などの提供を条件とした金銭要求を説明しています。ただし、サイト改ざん＝ランサムウェア被害ではなく、すべての侵害で金銭を要求されるわけでもありません。 金銭要求の文面が届いたこと、データが実際に暗号化されたこと、復旧できるかどうかは別々に確認する事柄です。出典：MITRE：Data Encrypted for Impact

復旧に必要な原因調査、制作会社やサーバー事業者との調整、再設定、掲載内容やフォームの動作確認、顧客・取引先への説明なども、業務負担になり得ます。これらの費用や期間は、保存データの種類、侵害範囲、構成、契約、調査結果で変わります。特定の被害金額や復旧日数をここで示さないのは、サイトの規模だけでは根拠ある推計ができないためです。

サイト運営者が被害者でも二次被害が生じ得る理由

サイト運営者が侵害の被害者であっても、そのサイトを経由した影響が閲覧者や他社へ広がることがあります。 攻撃者にとって、正規の会社のドメインやサーバーは、詐欺ページを公開する場所にも、悪意あるファイルを配る場所にも、通信を中継する場所にもなり得るからです。最初に狙われた企業に攻撃の意思がなくても、別の人が不正なページを信用したり、別組織が不審なアクセスを受けたりすることは考えられます。出典：Google：ハッキングされたコンテンツ・IPA：踏み台悪用の説明・WordPress公式：他サイトへの攻撃に使われた兆候

以下の表T04は、攻撃者が何を得ようとし、その結果、誰にどんな影響が及び得るかを整理したものです。各行は一般に起こり得る被害の関係であり、特定のサイトで確認された実被害や発生頻度を表すものではありません。

表T04｜攻撃者の目的と運営企業・第三者への影響

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

同じ侵害から表の複数行に該当する状態が生じることもあれば、どの結果にも至らず、探索や攻撃の試行だけで終わることもあります。表を、すべてのWordPressサイトで発生する出来事の一覧として読まないでください。

影響を考える際には、何を裏付ける証拠なのかを明確にする必要があります。アクセスログに不審な要求があれば攻撃の試行があったかを判断する材料です。一方、運営者が作っていないページや管理者、変更されたファイルなどが確認されれば、「許可されない変更が起きた」という判断を強めます。それでも、情報の外部送信や第三者の認証情報窃取まで同時に証明されたわけではありません。検索結果に不正なページが見つかった場合も、まず掲載の事実と時期を確認し、データの持ち出しや閲覧者の被害とは切り離して扱います。出典：WordPress公式：侵害の兆候・Google：ハッキングされたページの説明

二次被害が起こり得ることと、運営者が法律上の責任を負うことも別問題です。 法的な判断は、保存していた情報、契約関係、具体的に起きた行為、適用法令、運営者が把握・対応した状況などによって異なります。「侵害されたサイトを持っていた」という事実だけで、一律に責任の有無を確定することはできません。

小さなサイトであっても、自分の会社の表示やデータだけでなく、そこへ訪れる人や、つながる別の組織への影響まで視野に入れる必要があります。同時に危険を大きく見積もりすぎないためにも、探索された事実、侵害された事実、第三者に生じた被害を、証拠に沿って別々に確かめることが大切です。

関連する説明：試行と実被害の読み分け／自社サイトの確認／侵害が疑われる場合
この章の目次へ・全体の目次へ

第7章

2026年10月のPHP重大脆弱性と過去の実被害

2026年10月21日、PHPの内部処理に関する2件の重大な脆弱性が公表され、同日に修正版が案内されました。 いずれも条件が揃えば、ログインしていない外部の人物によるリモートコード実行（RCE）につながり得ます。ただし、2件の原因も、攻撃が実証された実行環境も同一ではありません。また、攻撃が観測されたことと、実在する会社のサーバーが侵害されたことは別の事実です。出典：PHP開発元の公表・OOMの個別アドバイザリ・状態残存の個別アドバイザリ

この章でわかること

• 2026年10月21日のPHP重大RCEは何が問題だったのか
  • CVE-2026-109618：メモリ不足時の処理不整合
  • CVE-2026-109619：ワーカーに残る古い状態の利用
• PHPの実行方式によって攻撃条件が異なる理由
• 影響バージョン・修正版・配布元パッチの確認
• 10月23日の別問題（CVE-2026-115560）との違い
• 攻撃試行が観測されたことと侵害成功の違い
• 2024年PHP-CGIのCVE-2024-4577と国内の実被害
• 自社PHP環境への影響を確認するための判断材料

この章では「PHP2Shell」と呼ばれるこの2件、10月23日に別途注意喚起された問題、2024年に国内で現実の被害が確認されたPHP-CGIの問題を分けて説明します。PHPの脆弱性はWordPress本体の脆弱性ではなく、WordPressだけを更新してもPHP本体の修正にはなりません。 判断の基本は、PHPの系列と修正適用状況、Webで使う実行方式、問題のある処理へ到達する条件を照合することです。出典：WordPress公式の注意喚起・IPAの2026年注意喚起

2026年10月21日のPHP重大RCEは何が問題だったのか

問題は、PHPがリクエストを処理する途中で異常が起きた際の内部状態の管理にありました。 PHPはページ表示やフォーム送信など、一つひとつの要求を「リクエスト」として扱います。処理中は一時的なメモリを確保し、終了時に後片付けを行います。通常はこれらの処理が整合していますが、異常終了や処理の順番によって、まだ有効ではない状態や、すでに無効になった状態を使ってしまう経路がありました。出典：PHP公式告知・2件の開発元アドバイザリ・状態残存の解説

ここでいうメモリとは、PHPの実行中にデータを置く作業領域です。不正なメモリの扱いがあること自体と、外部から任意の処理を実行できることは同義ではありません。 実行方式や入力の到達範囲など、攻撃を成立させる条件はCVEごとに異なります。

CVE-2026-109618：メモリ不足時の処理不整合

CVE-2026-109618の中心は、メモリ不足（OOM：Out Of Memory）の処理が、PHP内部の初期化と後片付けの順序を崩すことです。 OOMは、実行中のプログラムが必要なメモリを確保できなくなる状態を指します。PHPは従来、一部のOOM発生時にlongjmp()という仕組みで現在の処理を途中から抜け、リクエストの中断へ移っていました。これは処理の深い位置から別の位置へ戻る仕組みであり、必ずしも途中の処理がすべて通常どおり完了するわけではありません。出典：PHP開発元：OOMの原因と修正

問題になるのは、リクエストで使用するメモリが「確保され、参照可能になったが、初期化はまだ完了していない」短い段階です。その段階で別のメモリ確保に失敗すると、その時点で処理を抜けます。しかし終了処理が「必要な準備は完了したはず」と考えてその領域を読んだり、状態によって処理を分岐したりすると、未初期化または不整合な情報を有効なものとして扱う危険が生じます。失敗したメモリ確保が、問題のある領域そのものに関係している必要もありません。単なるメモリ不足なら通常は要求を失敗として扱えばよいところ、後片付けが不正な状態に作用するため、より重大な問題になります。出典：GHSA-w8hw-w9fx-j79w

外部からの要求がこの状況を生み得る理由は、PHPがアプリケーションの処理に入る前に、フォームやファイル送信などのデータを解析する場合があるからです。データの受信量に制限があっても、内部で作られる管理情報などのメモリ消費まで必ず同じ比率で抑えられるわけではありません。開発元は、通常のPHP側の上限に収まって見えるリクエストでもOOMへ到達する経路があると説明しています。ただし、データが大きいこと、ファイルアップロード機能があることだけでRCEが成立するわけではありません。 処理を中断する時点の内部状態、終了処理の挙動、実行環境などが関係します。出典：GHSA-w8hw-w9fx-j79w

このCVEについて、開発元がログイン不要のHTTPリクエストからRCEまで実証したのは、Apacheのmod_php構成です。この方式では、リクエストの開始途中で失敗しても後片付けが呼ばれ、アプリケーションのPHPコードを実行する前に問題が表面化し得ます。一方、PHP-FPMでは、リクエスト開始に失敗したワーカーが終了するため、これと同じ経路では実証が成立しません。 開発元は、正常な開始後にアプリケーションの処理でOOMが起きる別経路についてPHP-FPMへの影響可能性を指摘していますが、このCVE単独のPHP-FPM向け完全なRCE実証は公表していません。 FrankenPHPでは類似する終了処理から影響が疑われ、LSAPIでも別条件での可能性が挙げられていますが、同一条件での実証済みと読み替えられません。出典：GHSA-w8hw-w9fx-j79w：実行方式別の説明

修正では、メモリ不足時に無条件で途中の処理を飛び越える従来の挙動を改め、安全な中断位置で処理する方法と、より深刻なメモリ不足で即座に終了する方法が導入されています。目的は、不完全な状態を通常の終了処理へ渡さないことです。開発元は修正版への更新だけが完全な緩和策と明記し、設定変更や入力制限は一部の発生経路を減らす補助策と位置付けています。出典：GHSA-w8hw-w9fx-j79w：修正と緩和策

CVE-2026-109618｜OOM（メモリ不足）に伴う問題の模式図

画像を拡大する ＋

図の内容をテキストで読む

通常の処理

1. 領域を確保

2. 初期化が完了

3. 本来の処理

4. 適切な後片付け

問題になる処理の例

1. 領域を確保

2. 初期化の途中

3. 別の確保が失敗

   OOM（メモリ不足）

4. 途中で中断

   longjmp()

5. 不完全な状態を後片付けが扱う

※初期化完了前の中断経路が問題

重要：メモリ不足＝直ちにRCEではありません。実行方式・到達経路・条件により影響は異なります。

上図は原因の抽象化であり、実際の全コード順序を示すものではありません。

修正版と条件は本文の第7章を参照。

図D05A｜CVE-2026-109618で問題になる初期化と終了処理の不整合。抽象化した説明であり、メモリ不足だけでRCEが成立することを示すものではありません。

参考資料：PHP公式セキュリティアドバイザリ／PHP公式：2026年リリース記録

CVE-2026-109619：ワーカーに残る古い状態の利用

CVE-2026-109619の中心は、前のリクエストが使っていた情報への参照がワーカー内に残り、次のリクエストがそれを再利用してしまうことです。 ワーカーは要求の処理を担当する実行単位です。PHP-FPMではワーカープロセスが要求を受け持ち、mod_phpではApache側の実行構成に応じたワーカーでPHPが動きます。いずれも同じワーカーが複数の要求を順番に担当する場合があります。ワーカーの再利用自体は通常の動作です。問題は、前の要求だけに有効だった情報が、要求の終了後も使えるものとして残る点にあります。出典：GHSA-6wmf-4rv5-p3rp・PHP公式：ワーカーの扱い・PHP-FPM

PHPは、エラー、セッション、オブジェクト、拡張機能などに関する状態の一部を、ワーカー側の共通領域から参照します。他方、具体的なデータが保存されている場所は、そのリクエストが終わると解放されることがあります。解放済みメモリへの参照とは、すでに使い終えて別の用途に利用され得る領域を、以前の情報がまだ存在するかのように指し続けることです。このような問題を「Use-After-Free（解放後使用）」と呼びます。別のデータが同じ領域に置かれた後に古い参照をたどると、意図しない情報を読んだり、プログラムの制御に影響したりする場合があります。出典：GHSA-6wmf-4rv5-p3rp：原因

このCVEの成立には、前後の処理がつながることが重要です。開発元は、古い参照を残す処理を「producer（状態を残す側）」、後でその参照を使う処理を「consumer（状態を利用する側）」と呼びます。概念上、問題が成立するには、前の要求で一時データへの参照が残り、その元データが解放され、同じワーカーが次の要求を受け、通常の初期化で参照が更新される前に後続の処理が古い値を利用する必要があります。致命的なエラーやメモリ不足で後片付けが途中で終わる場合だけでなく、終了処理の後半に新たな警告などが生じて状態が残る場合もあります。別のワーカーに届いた要求や、状態が正しく消去された要求では同じ連鎖を前提にできません。出典：GHSA-6wmf-4rv5-p3rp：producer・consumerの条件

実証された経路は一つではありません。開発元は、PHP 8.5の致命的エラー時のバックトレース（エラーに至る呼出履歴）と、次の要求の初期設定時の診断処理が関係する経路について、mod_phpでRCEを実証しています。また、ファイル送信の進捗をセッションに記録する機能に関係する別の経路では、mod_phpとPHP-FPMの両方でRCEを実証しました。ただし、PHP-FPMの実証は、リクエスト開始後のアプリケーション処理で状態が残り得ることなどの条件を伴い、mod_phpの開始途中の異常をそのまま適用したものではありません。出典：GHSA-6wmf-4rv5-p3rp：実証経路

初期設定の診断を利用する経路でも方式差があります。mod_phpはディレクトリ単位の設定を通常のPHP初期化より前に適用する場合があり、そこでの警告等が古い状態に触れ得ます。PHP-FPMはプール設定をワーカー起動時に読み、.user.iniは通常の初期化より後に適用するため、これらを同じ条件として扱えません。PHP-FPMでもフロント側から渡す一部の設定パラメーターによって開始前の診断が起こり得ますが、追加の構成条件が必要です。開発元は他のエラー処理や拡張機能の状態についても候補を挙げていますが、具体的なproducerとconsumerが示されていない経路をRCE実証済みとはしていません。出典：GHSA-6wmf-4rv5-p3rp：方式ごとの到達条件

古い参照の不正利用から起こり得る影響として、メモリ情報の不正取得とRCEは分ける必要があります。前者は本来見せてはいけない情報を読み出してしまうこと、後者は処理の制御に影響してサーバー側で意図しないコードを実行できることです。開発元は両方を実証したと報告していますが、すべての構成で同じ結果になるとは述べていません。いずれのCVEもRCEが成立した場合の権限は、PHPを実行するWebワーカーのOS上の権限が基本です。自動的にサーバー全体の管理者権限を得るわけではなく、アクセスできるファイルや他のシステムは権限と設定によって異なります。出典：GHSA-6wmf-4rv5-p3rp：影響と実証・GHSA-w8hw-w9fx-j79w：実証範囲

修正では、前の要求で使用した情報への参照が次の処理に持ち越されないよう、状態の後片付けが強化されています。セッション進捗機能や一部の診断機能を停止することは特定経路の緩和にはなりますが、他の状態が残る可能性まで取り除くものではありません。 したがって、開発元が示す基本対策はここでも修正済みPHPを利用することです。出典：GHSA-6wmf-4rv5-p3rp：修正・緩和策

CVE-2026-109619｜前の要求の参照が後続の要求で使われる条件

画像を拡大する ＋

図の内容をテキストで読む

同一PHPワーカー（時間は上→下）

前のリクエスト A

状態を公開する処理（producer）
要求Aだけの一時メモリへの参照

要求Aが終了

A終了：要求用メモリは解放される

以下は条件による別々の経路。

問題が成立し得る側

1. ワーカー側に古い参照が残る

2. 後のリクエスト B（同じワーカー）

3. 初期化前の利用（consumer）

4. 解放後使用の可能性

対照：適切に消去する側

1. 要求Aの終了処理などで参照を適切に消去・再初期化

2. 後のリクエストBへ持ち越さない

   （上記の残存経路を避ける）

※ワーカーの再利用自体は正常な動作です。producerとconsumerなどの条件が必要です。

※mod_phpとPHP-FPMで実証された経路・条件は異なります。詳細は第7章。

図D05B｜CVE-2026-109619では、同じPHPワーカーで前のリクエストの参照が後続処理へ残ることが問題になります。通常のワーカー再利用そのものが脆弱性という意味ではありません。

参考資料：PHP公式セキュリティアドバイザリ／PHP公式：持続的接続

PHPの実行方式によって攻撃条件が異なる理由

同じPHPの脆弱性でも、リクエストを開始・終了するときに動く処理が違えば、攻撃条件は変わります。 mod_phpはApacheの内部でPHPを動かす方式、PHP-FPMはWebサーバーから要求を受けてPHPのワーカーが処理する方式、PHP-CGIはCGIという仕組みでPHPの実行プログラムへ要求を渡す方式です。PHP-FPMもFastCGIを利用しますが、ワーカーが動作し続ける期間を、通常のCGIと同じだと考えてはいけません。出典：PHP公式：Apacheモジュール・PHP公式：FPM・Apache公式：CGI

mod_phpではApacheのワーカーとPHPの処理が密接につながり、開始途中に失敗したリクエストでも終了処理へ進むため、CVE-2026-109618ではアプリケーションから独立したRCE経路が実証されました。PHP-FPMは開始失敗時にワーカーを終了させるので、これと同じ条件ではありません。ただしPHP-FPMでも、正常に開始した後の処理や、前のリクエストから状態が持ち越される問題が別の形で存在し得ます。 実際、CVE-2026-109619では、条件付きのPHP-FPM経路が実証されています。出典：OOMのアドバイザリ・状態残存のアドバイザリ

PHP-CGI、LiteSpeedのLSAPI、FrankenPHPなどもPHPをWebで動かす入口になり得るため、PHP公式は影響の有無を確認すべき対象に挙げています。ただし、「確認が必要」「ソース上の影響が疑われる」「RCEを実証した」「実在のサイトが侵害された」は四つの別の区分です。今回の二つのアドバイザリで実証範囲が明記されたもの以外を、実証済みと断定しません。PHP-CGIについては、後述する2024年のWindows固有の問題とも混同しない必要があります。出典：PHP公式の対象説明・GHSA-w8hw・GHSA-6wmf

運営者が判断するときに必要なのは、「うちはApacheだから」「nginxだから」というWebサーバー名だけではありません。ApacheからPHP-FPMへ渡す構成もあれば、同じサーバー上のサイトごとにPHPの実行設定が異なる場合もあります。実際にWebサイトを処理しているPHPの実行方式と、担当するワーカーの設定を把握することが必要です。出典：Apache公式：FastCGI連携・PHP公式：FPM

影響バージョン・修正版・配布元パッチの確認

2026年10月21日に公表された2件について、PHP開発元が示した修正版は8.2.35、8.3.36、8.4.27、8.5.12です。 次の表T05は、あくまで10月21日の2件に対する当時の修正境界を示します。より新しい版が存在するか、10月23日に案内された別件まで修正されているかを、この表だけから判断してはいけません。出典：PHP公式告知・OOMの影響・修正版・状態残存の影響・修正版・PHP公式変更履歴

表T05｜PHP系列と修正版の比較（CVE-2026-109618／CVE-2026-109619）

この表の「影響バージョン」は、PHP開発元が両アドバイザリに示した8.2～8.5系列の修正前の範囲です。個々の実行方式で必ずRCEが成功する版の一覧ではありません。PHP 8.1以前は2026年10月時点でPHP本家の通常サポートが終了しており、上の4系列と同じ「新しい公式リリース番号」はありません。ただしPHPのセキュリティチームは今回、PHP 7.4・8.0・8.1向けにソースコードへの最小限の修正差分も提供したと説明しています。これが存在することと、利用中の古い環境にその修正が実際に適用済みであることは別です。古い系列の利用は他の修正漏れやサポート範囲も含めて提供元に確認する必要があります。出典：PHP開発元の告知・PHP公式サポート状況・IPAの注意喚起

Linuxディストリビューションやホスティング事業者は、PHP本家の新しいバージョン番号へ一律に置き換える代わりに、必要なセキュリティ修正を古い版のパッケージへ取り込むことがあります。これがバックポートです。例えば表示されるPHPの基本バージョン番号が修正版より前でも、配布元が対象CVEへの修正を取り込んでいる場合があります。反対に、提供元が「修正を提供した」だけでは、そのサーバーが適用・再起動まで完了したと判断できません。PHP本家の版番号、配布元のパッケージ版・改訂番号、対応済みCVE、稼働中プロセスの状態を一緒に確認します。出典：Red Hat：バックポートの考え方・PHP開発元の案内

日付を照合する際は、PHP公式ニュースと開発者のリリース案内が10月21日、PHP公式変更履歴の対象リリース欄が10月22日と表示されている点に注意してください。この章の「10月21日」はセキュリティ告知の日付です。変更履歴に記載された日付との差の理由は確認できていないため、各資料の日付を一律に書き換えず、修正版の番号と対象CVEを併せて確認します。出典：PHP公式ニュース・PHP公式変更履歴・PHP開発者のリリース案内

10月23日の別問題（CVE-2026-115560）との違い

2026年10月23日にPHP公式が説明したCVE-2026-115560は、21日の2件とは別の問題であり、21日の修正版で解消したものではありません。 PHP公式がこの日に出したものは、重大な修正版リリースの告知ではなく、セッションのアップロード進捗機能に関する暫定的な注意情報（informational advisory）です。公式は、特殊な設定とアプリケーションコードの組み合わせでRCEにつながる可能性を示し、次の通常のバグ修正リリースで正式なアドバイザリを公開する方針を説明しています。2026年10月26日にPHP公式告知と変更履歴を再確認した範囲では、当該問題に対応した正式な修正版番号、確定した影響バージョン一覧、個別の完全なアドバイザリは確認できていません。 未確認の版番号を推定せず、対応を判断するときはこの告知に続く公式情報も確認してください。出典：PHP公式2026年10月23日の情報・PHP公式変更履歴

セッションは、Webアプリケーションが利用者の操作に関連する状態を、複数の要求にまたがって扱うための仕組みです。ファイルアップロード中の進捗をセッションに記録する機能がsession upload progressで、PHPにはセッションの情報を保存形式に変換する「シリアライズ方式」を指定する設定session.serialize_handlerがあります。問題になるのは機能が存在することだけではなく、保存形式として使った方式と、後で読み戻す方式が特殊な条件で食い違うことです。出典：PHP公式10月23日告知

PHP公式が挙げる成立条件は、アプリケーションの設定が当初php_binaryまたはphp_serializeという形式を利用し、実行中にini_set()でphp形式へ切り替え、session_start()でセッションを開始する前にその変更を行い、さらにアップロード進捗機能が有効なことです。これらは組み合わせとして必要な特殊条件であり、PHP-FPMやWordPressという名前だけで該当を決められません。公式は、実行中にシリアライズ方式を切り替えないアプリケーションについて、この経路では機能を有効のままにできると説明しています。出典：PHP公式10月23日告知

PHP公式が案内する当面の緩和策は、管理者が設定上でアップロード進捗機能を無効にすることです。これは開発元が当該経路への暫定対処として示したもので、変更前に機能の利用有無を確かめる必要があります。21日のCVE-2026-109619でも、この機能の無効化は特定の経路への緩和策として言及されていますが、だからといって両CVEの原因が同一になるわけではありません。また、10月21日の2件への完全な対策を、この設定変更だけで代替できません。出典：PHP公式10月23日告知・GHSA-6wmf-4rv5-p3rp

この別問題について、PHP公式の10月23日告知からは正式な修正版番号、確定した影響バージョン一覧、現実の企業での侵害事例までは確認できません。確認できない情報を、21日の2件の数字や攻撃観測から補完しないことが必要です。

攻撃試行が観測されたことと侵害成功の違い

2026年10月17日には、PHP2Shellの公表前に、その悪用を試みた通信がAWSの観測環境へ届いていました。ただし、この観測を「企業のサイトへの侵害成功」と読み替えてはいけません。 AWSのAmazon Threat Intelligenceは、攻撃などの通信を観測するおとりのシステム（ハニーポット）であるMadPotの記録から、10月17日の試行を確認したと公表しています。これは10月21日の一般公表より4日前です。出典：AWS Security Blogの原文

AWSはさらに、10月21日の公開前の時間帯にも複数の概念実証や試行を観測し、公開・修正後には新たな実証コードが短時間でセンサーに対して使われたと説明しています。概念実証（PoC）は、その問題が一定の条件で悪用可能であることを検証するためのものです。開発元アドバイザリに書かれた「特定の構成でRCEを実証した」という説明は技術的な成立の実証であり、AWSのMadPot記録は外部からの攻撃試行の観測です。証拠の性質が違います。出典：AWSの観測報告・GHSA-w8hw・GHSA-6wmf

AWSは、実環境で悪用の試みが広がっていると報告しています。一方、観測した特定の試みが現実のシステムで成功し得たかは不明とも明記しています。実際に悪用を試みる通信が届いたことと、その試みが対象を侵害できたことは、別に確かめる必要があります。企業のサーバーへの侵害が成功したと判断するには、そのサーバーで不正な処理が成立し、無断の変更・実行などの結果が発生したことを裏付ける追加の証拠が必要です。ハニーポットへの通信件数や、センサーが受けた不審な要求の数は、被害組織数には変換できません。出典：AWS Security Blog・IPAの2024年実被害報告

表T06｜脆弱性の公表・攻撃観測・実被害の時系列

この時系列は、2024年の国内実被害のCVEと、2026年の観測対象が別であることも示しています。CVE番号の付与や公開だけでは、CISAのKEV（実際の悪用が知られた脆弱性の公式カタログ）への掲載を意味しません。2026年10月26日に取得したCISA公式データ（カタログ版2026.10.23）では、CVE-2024-4577は2024年6月12日付で掲載されています。一方、この取得版にCVE-2026-109618、CVE-2026-109619、CVE-2026-115560の記録はありません。この非掲載は、攻撃試行や実際の悪用が存在しないことの証明ではありません。 AWSの観測、開発元の実証、KEVへの掲載は、それぞれの根拠と確認時点を分けて扱います。出典：CISA公式KEVデータ・AWS原文・IPA 2024

2024年PHP-CGIのCVE-2024-4577と国内の実被害

CVE-2024-4577は、2024年に国内で現実の侵害被害が報告された、Windows上のPHP-CGIの問題です。 PHPの実行プログラムへ渡される情報の扱いが原因であり、2026年の2件で問題になった初期化途中のメモリの扱いや、同一ワーカー内で前のリクエストの状態が後続のリクエストへ残る仕組みとは、技術的に異なります。出典：PHP GroupによるCVE公式記録・IPAの2024年報告

問題になるのは、Windows上でApacheとPHP-CGIを組み合わせ、特定の文字コード設定（コードページ）を使用している場合です。Windowsの一部の文字変換には、完全に対応しない文字を似た別の文字へ置き換える「Best-Fit（最適近似）」という振る舞いがあります。PHP-CGIへ渡すコマンドラインの文字列がこの変換を受けると、通常のデータのはずだった文字がPHPの起動オプションの区切りなどとして誤解釈される可能性があります。これが引数注入の問題です。条件が揃うと、PHPプログラムのソースコードが露出したり、サーバーで任意のPHPコードが実行されたりするおそれがあります。出典：PHP Group CNAによるCVE公式JSON

この問題は「PHPを使っていればどのOSでも成立する」という意味ではありません。Windowsであることだけでも不十分で、PHP-CGIの実行方法と、文字コード変換に関する条件が重要です。一般的なLinux上のPHP-FPMに、そのまま同じ成立条件を当てはめることはできません。ただしLinuxやFPMの環境にも別の脆弱性があり得るため、CVE-2024-4577に該当しないことをPHP全体の安全の証明にしてはいけません。出典：PHP GroupのCVE記録・PHP公式FPM解説

2024年当時の修正版は、PHP 8.1.29、8.2.20、8.3.8でした。公式記録では、それぞれ同じ系列の修正版より前の版が対象とされています。2026年に使うPHPへこれらの版番号だけを適用して安全性を判断するのは不適切で、現在のソフトウェア管理では後続の修正や提供元の保守状況も確認する必要があります。出典：IPA：影響バージョンと対策・CVE公式記録

IPAは2024年7月5日の報告（同月12日更新）で、国内の複数組織について、CVE-2024-4577を悪用されたWebサービスにWebシェルが設置されていたと説明しています。WebシェルはWebサーバーを外部から不正に操作するために使われ得るプログラムで、この報告は単なる攻撃の試みではなく、不正プログラムの設置という具体的な侵害被害を示しています。ただし、IPAの資料から会社名、業種、WordPressの利用有無、組織の規模、被害金額や厳密な成功件数を補うことはできません。出典：IPA 2024：国内組織の被害

IPAはさらに、設置されたWebシェルを経由して組織内部のネットワークへ侵入が試みられたり、別の組織への攻撃の中継地点として利用されたりする危険を説明しています。ORB（Operational Relay Box）は、侵害された機器などが攻撃通信の中継に悪用される状態を指します。IPAは中継・隠蔽に使われた別の事例にも言及していますが、CVE-2024-4577の被害が報告された国内組織すべてで、内部への侵入や他組織への攻撃中継が成功したと述べているわけではありません。 「Webシェル設置の確認」と「さらに起こり得る二次被害」を分ける必要があります。出典：IPA 2024：ネットワーク貫通型攻撃とORB

自社PHP環境への影響を確認するための判断材料

自社サイトへの該当性は、ニュースで見たCVE番号やPHPの表示バージョンだけでは確定しません。 少なくとも、何の製品が動いているか、実際にWebリクエストを処理しているPHPの系列・配布元・パッケージ改訂、実行方式、修正適用状況を一組として確認する必要があります。特に、ターミナルで動くCLI版PHPと、Webサイトで使うPHP-FPMやApacheモジュールの版が異なる構成もあるため、片方の情報だけを全サイトの状態と決めつけないでください。出典：PHP公式FPM・WordPress公式注意喚起・Red Hatバックポート

実務上は、次の順に事実を整理すると、保守会社やサーバー事業者との確認が進めやすくなります。

1. 対象を特定する。 利用中のPHPが、WordPressを表示している実行環境なのか、別のアプリケーションや機器の内部で動くものなのかを確かめる。管理対象のサイトが複数あれば個別に整理する。
2. 修正適用状況を照合する。 2026年10月21日の2件について、表T05のPHP系列・当時の修正版、配布元のCVE別対応告知、適用済みパッケージの版や改訂番号を突き合わせる。配布されたことと、現在動いているプロセスへ反映済みであることも区別する。
3. 実行方式と前提条件を確認する。 mod_php、PHP-FPM、PHP-CGI、その他の方式のどれが使われているかを調べる。CVE-2026-109618ではOOM時の処理、CVE-2026-109619ではワーカーの再利用と前後の状態、CVE-2024-4577ではWindows・PHP-CGI・文字コード設定という条件が判断材料になる。
4. 10月23日の別問題も切り離して確認する。 セッションのシリアライズ方式をアプリケーション実行中に切り替えているか、アップロード進捗機能を利用しているかを保守担当者に確認する。10月21日の修正適用済みという返答だけで、CVE-2026-115560まで対応済みと扱わない。
5. 根拠を残す。 確認した日付、提供元と情報のURL、対象サイト、PHPの動作形態、修正済みと判断した根拠、確認できなかった項目をまとめる。不審な動作があれば単なる更新確認と分け、記録の保全や専門家による調査が必要か判断する。

これらは点検時に収集すべき判断材料であり、外部の第三者サイトを調べる方法や、脆弱性を再現するための操作ではありません。具体的な画面の見方は第9章、更新に伴う確認は第10章、侵害が疑われる場合の対応は第12章で扱います。出典：PHP公式ニュース・WordPress公式注意喚起・IPA 2026

結論として、2026年の2件では「PHPを利用している」だけで侵害済みとは判断できませんが、実証された構成が存在するため、対象版と修正の適用を優先して確認する必要があります。 2024年のIPA報告は実被害の事実、AWSの2026年の報告は攻撃試行の観測です。この違いを保ったまま、各サイトの実際の環境に照らして対応してください。

関連する説明：WordPress本体の別の問題／稼働版の確認／安全に更新する準備
この章の目次へ・全体の目次へ

第8章

WordPress本体・テーマ・プラグインの重大脆弱性事例

WordPressサイトの脆弱性は、WordPress本体だけでなく、利用しているテーマやプラグインにも生じます。 同じ「ログイン不要の攻撃」でも、外部からの入力がデータベースに作用する問題、複数の処理上の弱点が連鎖してサーバー上のコード実行に至る問題、特定のテーマやサーバー構成が揃う場合に限って成立する問題など、原因と条件は異なります。したがって、CVE番号、対象製品、影響バージョン、必要な条件、修正版、実際の悪用に関する証拠を一組として確かめる必要があります。

この章でわかること

• 2026年7月のwp2shell：WordPress本体の2件の連鎖
  • CVE-2026-60137：SQLインジェクションの問題
  • CVE-2026-63030：REST APIの問題との組み合わせ
• 2026年9月のCVE-2026-87902：条件付きのRCE
  • 有効テーマとサーバー環境の前提条件
  • 古いWordPress系列にも存在する修正版
• 2026年10月のWordPress 7.1.3：7件のセキュリティ修正
• BricksテーマのCVE-2024-25600：認証不要RCEの事例
• WordPress AutomaticプラグインのCVE-2024-27956：SQLインジェクションの事例
• WordPress本体と拡張機能では更新先が異なる
• 事例別の影響条件・修正・実際の悪用状況の比較

前章の「PHP2Shell」はPHPの実行環境に関する2026年10月の問題でした。ここで扱う2026年7月の「wp2shell」はWordPress本体に存在した別の脆弱性の連鎖であり、名称が似ていても原因も更新対象も違います。以下の修正版は原則として各問題が公表された当時の修正境界です。2026年10月26日時点のすべての安全性を保証するものではありません。出典：WordPress 7.0.2公式リリース・WordPressの個別アドバイザリ・PHPの問題に関するWordPress公式案内

2026年7月のwp2shell：WordPress本体の2件の連鎖

2026年7月17日に公表されたwp2shellは、WordPress本体の二つの弱点を組み合わせると、ログインせずにリモートコード実行（RCE）へ至り得るという問題です。 一つはデータベース検索を組み立てる処理、もう一つは複数のAPI要求をまとめて処理する機能にあります。連鎖したRCEが報告された対象は、WordPress 6.9.0～6.9.4および7.0.0～7.0.1です。一方、6.8.0～6.8.5には前者のSQLインジェクションの問題がありますが、6.9以降のREST API側の脆弱性まで同じように存在するわけではありません。出典：WordPress公式リリース・個別アドバイザリ2件・REST API側の個別アドバイザリ・発見者の公表

SQLインジェクション（SQLi）は、プログラムがデータベースへ送る問い合わせ文の構成に、外部の入力が本来許されない形で影響する問題です。REST APIは、Webサイトの外部やブラウザ上のプログラムが、HTTP通信を使ってWordPressの機能に要求を送る仕組みです。REST APIを備えていること自体は脆弱性ではなく、今回問題になったのは個別の要求を検証・実行する処理の不整合でした。

CVE-2026-60137：SQLインジェクションの問題

CVE-2026-60137は、WordPress本体のWP_Queryがauthor__not_inという検索条件を処理する際のSQLインジェクションです。 WP_Queryは、投稿を検索するときの条件を受け取り、データベースから該当する投稿を取得するWordPressの中核機能です。author__not_inは特定の投稿者を検索結果から除外するための指定で、本来は投稿者の識別番号を適切な型の値として扱う必要があります。出典：開発元GHSA-fpp7-x2x2-2mjf

検索条件に渡される値の形式や内容が適切に制限されないと、プログラムが構築するSQL文の一部を、外部から渡されたデータが変えてしまう可能性があります。通常の検索なら「この投稿者を除いて表示する」という条件になるところ、意図しないデータベース操作へつながる余地が生じます。今回の問題は、そのような危険がWP_Queryの特定パラメーターに残っていたものです。ただし、WP_Queryを使うすべてのページが無条件に攻撃可能だったわけではありません。 外部から信頼できない値が当該パラメーターまで届く経路が必要です。出典：WordPress開発元の個別説明

通常、WordPress本体の公開APIは必要に応じて入力を検証・整形します。しかしテーマやプラグインなどが受信した値を不適切にWP_Queryへ渡す場合や、他の脆弱性によって本来の検証を通らずに到達できる場合は、SQLiの入口になり得ます。SQLiそのものはデータベース操作に関する問題であって、単独で必ずPHPコードを実行できる、あるいはサーバー全体の管理者権限を得られる、という意味ではありません。 実際の取得・変更可能範囲は、問い合わせの形、データベース接続アカウントの権限、別の実行経路の有無に左右されます。

開発元が示した影響範囲は6.8.0～6.8.5、6.9.0～6.9.4、7.0.0～7.0.1です。2026年7月17日当時、それぞれ6.8.6、6.9.5、7.0.2で修正されました。6.8系にこのSQLiがあるという事実は、次のCVE-2026-63030によるRCE連鎖が6.8系でも成立すると証明するものではありません。出典：GHSA-fpp7-x2x2-2mjf・WordPress 7.0.2

CVE-2026-63030：REST APIの問題との組み合わせ

CVE-2026-63030は、WordPress REST APIの「バッチ要求」を扱う際、要求の経路とその検証・処理の対応が混乱する問題です。 バッチ要求とは、複数のAPI処理をひとつの通信で受け付ける仕組みです。それぞれの処理では、本来、実行する機能に応じた入力の検証や権限確認が必要ですが、経路の対応に不整合が生じると、ある要求が想定と異なる処理へ渡される余地が生まれます。開発元は、これをREST APIのbatch-route confusionと説明しています。出典：GHSA-ff9f-jf42-662q・WordPress公式リリース

二つの問題が結び付くのは、通常なら十分に制限されるべき外部入力が、REST API側の混乱により、SQLiのあるWP_Query処理へ到達し得るからです。前者が「不適切な入力を通してしまう経路」、後者が「その入力がデータベース問い合わせに作用してしまう箇所」という関係にあります。開発元はこの組み合わせを認証不要RCEに至る連鎖として公表し、発見者も、プラグインを追加していない標準的なWordPress構成で成立し得ると報告しました。出典：REST API GHSA・SQLi GHSA・発見者の一次報告

ここで注意すべきなのは、APIの経路混乱だけが、単独でサーバー上の任意コード実行を保証するわけではないという点です。また、SQLiが成立しても、そこからコード実行へ至るには、連鎖の中で必要なデータベース操作や後続のWordPress処理が利用可能であることが前提です。開発元のいうRCEは、検証・実行経路を組み合わせた場合の結果であり、二つのCVEがそれぞれ単独で及ぼす影響を、単純に足し合わせたものではありません。成功した場合に動くコードの権限も基本的にはWebサイトのPHP実行アカウントの範囲であり、OSの最上位権限の取得を意味しません。

このREST API側のCVEの対象は6.9.0～6.9.4と7.0.0～7.0.1で、2026年7月17日当時の修正版は6.9.5および7.0.2でした。6.8系はこのCVEの対象として列挙されていません。 6.8系の管理者にはSQLi自体への修正として6.8.6が必要でしたが、6.9系以降のwp2shell連鎖と同一の成立条件を当てはめてはいけません。出典：GHSA-ff9f-jf42-662q・GHSA-fpp7-x2x2-2mjf・公式7.0.2

公表と実際の悪用の証拠も分けて扱います。 7月17日の開発元公表と発見者の実証は、技術的に成立し得ることの根拠です。CISAの公式KEVデータでは、両CVEは2026年7月21日付で掲載されています。2026年10月26日に取得したカタログ版2026.10.23で、該当する番号と追加日を確認できます。これは現実の悪用についてCISAが公表した根拠ですが、自社が侵害された事実や被害組織数を示すものではありません。カナダのサイバーセキュリティセンターも7月21日付の更新でCISAへの追加を紹介し、日本のIPAは7月22日に注意を呼びかけています。出典：CISA公式KEVデータ・カナダ政府7月の注意喚起・IPAの注意喚起

2026年9月のCVE-2026-87902：条件付きのRCE

CVE-2026-87902は、WordPress本体のページテンプレートを探す処理が、通常のテーマ領域外にあるPHPファイルを読み込んでしまう可能性がある問題です。 2026年9月22日にWordPress 7.1.2などで修正されました。ログインしていない攻撃者から到達できる問題ですが、RCEの成立には有効なテーマとサーバー環境について追加条件が必要です。この点が、標準構成での連鎖が報告された7月のwp2shellとの大きな違いです。出典：GHSA-7hp8-65ch-5whp・WordPress 7.1.2公式リリース

WordPressでは、固定ページなどを表示するときに、現在のテーマにあるテンプレートファイルを探し、必要に応じて読み込みます。get_page_template()はその解決に関係する本体の関数です。今回の問題はパスの解決と読み込み対象の制限にあり、意図されたテーマの外側にあるファイルを選べてしまう点が危険です。こうしたファイル位置の制限を越える問題は、パストラバーサルと呼ばれます。対象がPHPファイルの場合、単にテキストを読み取るのではなく、PHPとして実行される処理に結び付くことがあるため、条件次第でRCEへ発展します。出典：開発元の技術説明

有効テーマとサーバー環境の前提条件

開発元が明示した条件は、テーマ側のディレクトリ構造と、サーバー側に存在する読み込み可能なPHPファイルの組み合わせです。 具体的には、現在の有効テーマ、または有効な子テーマが参照する親テーマの直下に、名前がpage-で始まるディレクトリがあること、さらにWebサーバーの実行アカウントが読み取れる対象のローカル.phpファイルが存在することが挙げられています。出典：GHSA-7hp8-65ch-5whp

WordPressの開発元は、該当し得るテーマの例に過去の公式テーマ「Twenty Twelve」「Twenty Fourteen」と、複数のサードパーティー製テーマを挙げています。ただし、そのテーマを使っているだけで必ずRCEが起きるという意味ではありません。 実際に有効なテーマの構造、読み込み先となるファイルの有無、ファイルの読取権限、そのファイルを実行したときの振る舞いまでが関係します。問題のあるWordPress本体と、攻撃を成立させる環境上の条件を区別してください。出典：WordPress開発元アドバイザリ

開発元は追加の実行経路の例として、PHPのPEAR関連ファイルとregister_argc_argv設定の組み合わせにも言及しています。しかしこれは特定の条件を満たす環境における可能性の説明であり、PEARのファイルがないサイトや設定が異なるサイトにもそのまま適用できるものではありません。実行可能なファイルの配置方法や攻撃の再現手順を知らなくても、管理者が確認すべきことは「どのPHPファイルをWebサーバーの権限で読める状態にしているか」「有効なテーマがどのような構造か」の二点です。出典：GHSA-7hp8-65ch-5whp

このCVEの「認証不要」とは、問題となる要求を送る前にWordPressのログイン資格情報を必要としないという意味です。それは、攻撃を実行できるサーバー構成が無条件に整っていることを意味しません。仮にRCEに至った場合も、基本的な権限はPHPを動かすWebサーバー側のアカウントに依存します。ファイルの閲覧・変更や別プログラムの起動可能範囲は、そのアカウントの権限とサーバー設定で変わり、自動的にOSの管理者権限を得るものではありません。

古いWordPress系列にも存在する修正版

この問題の修正版は7.1.2だけではありません。 WordPressの開発元は2026年9月22日、7.0.6、6.9.9、6.8.10などの系列別修正版も公開しました。個別のGHSAでは、さらに4.7系まで遡る修正版が明示されています。したがって「7.1.2より古い番号なら一律に未修正」という説明は誤りです。出典：GHSA-7hp8-65ch-5whp・WordPressリリース履歴

同じ6.8系列でも、7月のSQLiに対応した境界は6.8.6、9月のテンプレート問題に対応した境界は6.8.10です。古い6.8.6は7月の問題には修正済みでも、9月の別件には未修正の可能性があります。逆に、6.8.10で9月の修正が存在することを理由に、その系列が長期的に最新系列と同等の保守を受けられると考えてはいけません。WordPress公式は、積極的にサポートしているのは最新のWordPress系列と説明しています。出典：9月個別GHSA・10月公式リリース

実際の悪用状況については、CISAの公式KEVデータ（2026年10月26日取得、カタログ版2026.10.23）に、2026年9月25日付の追加が記録されています。カナダ政府のサイバーセキュリティセンターも9月23日付の注意喚起で実環境での悪用を示す公開報告に言及し、9月25日の更新でCISAへの追加を紹介しています。CISA自身の記録と、それを紹介する別機関の注意喚起は区別します。いずれも、自社の被害の有無、侵害成功件数、実際の被害現場のテーマ構成を個別に証明する資料ではありません。出典：CISA公式KEVデータ・カナダ政府AV26-952

2026年10月のWordPress 7.1.3：7件のセキュリティ修正

WordPress 7.1.3は2026年10月6日に公開され、公式リリースでは7件のセキュリティ修正と4件の通常の不具合修正が告知されました。 ここでの「7件」は開発元がリリースに含まれる問題として列挙した数であり、7件すべての個別CVE番号を今回の資料で確認できたという意味ではありません。 2026年10月26日時点では、非公開・未公開投稿のコメント露出はCVE-2026-66666に対応することを、CVE ProgramのCNA（CVE番号を割り当て、記録を管理する機関）が発行した正式記録で確認できます。残る6件の個別CVEとの対応は未確認です。これは「未採番」や「CVEがない」という意味ではありません。各項目の実際の悪用の有無も、修正の公表とは別に確認します。出典：WordPress公式7.1.3リリース・7.1.3公式バージョン記録・CVE-2026-66666公式JSON

公式が列挙した7件を、機能と成立条件に分けて確認します。修正項目と報告者はWordPress公式の告知、補足する技術的条件はPatchstack自身のコードレビュー、コメント露出のCVE対応と版の範囲はCNA記録を根拠にしています。調査者の分析を、公式リリースに書かれた説明や実被害の報告と混同しないでください。出典：WordPress公式告知・Patchstackによる7.1.3のコードレビュー・CVE公式JSON

1. 管理画面のコメント一覧における格納型XSS：承認待ちのコメントを経由して、管理画面に不正なスクリプトが保存・表示され得る問題です。格納型XSSは、保存された文字列が後からページに表示される際、閲覧者のブラウザで本来意図しないスクリプトが動く問題です。Patchstackのコードレビューでは、コメントを審査する編集者（Editor）以上の利用者が、管理画面のコメント内のリンクをクリックすることが必要な条件とされています。単にコメント一覧を開けば必ず発動するという説明ではありません。影響するのはブラウザ側であり、サーバー上のPHPコード実行と同一視できません。報告元はTrail of BitsとOpenAIです。
2. WP_Http::make_absolute_url()のサービス妨害（DoS）：WordPressがHTTP処理で利用するURLを絶対URLに変換するメソッドに関係する問題です。Patchstackのコードレビューは、寄稿者（Contributor）以上の利用者がブロックエディターのリンクプレビューを利用する経路を示しています。細工されたURLの処理に時間がかかり、応答に支障を来し得ます。この説明を、匿名の訪問者がすべての公開ページを同じ条件で停止できるという意味に広げてはいけません。報告元はAnthropicです。
3. WXRエクスポートの二次的SQLインジェクション：WXRはWordPressの投稿などを移すためのエクスポート形式で、二次的SQLiは、入力時に保存されたデータが、後の別処理でSQLへ取り込まれる際に問題になることを指します。Patchstackのコードレビューでは、不適切なアイキャッチ画像のメタデータがすでに保存され、管理者が特定の投稿種類を選んで書き出すことが必要です。標準の「すべてのコンテンツ」の書き出しは、同じ処理経路ではありません。保存値に影響できる経路と、後続の管理者操作を分けて考え、エクスポート機能があるだけで外部の誰もがDBを直接操作できるとは判断しません。報告元はAnthropicです。
4. 投稿者（Author）権限で投稿を先頭固定できる問題：本来の権限設定に反して、投稿者ロールの利用者が投稿を「先頭に固定」できる問題です。ログインしたAuthor権限の利用者が前提であり、匿名の訪問者が自動的に管理者へ昇格するという報告ではありません。報告元はAnthropicです。
5. 非公開・未公開投稿に付いたコメントの認証不要の閲覧（CVE-2026-66666）：コメントフィード（コメントの更新情報を配信する仕組み）を通じて、本来許可されない閲覧者へ非公開・未公開投稿に関連するコメントが開示され得る問題です。正式なCNA記録は、WordPressへのログインを必要としない情報露出として説明しています。公式が挙げたのはコメントの露出であり、当該投稿の本文やサイトの全データベースが漏れたと置き換えてはいけません。報告元はPatchstackのAnanda Dhakalです。
6. Imgur埋め込みに関係するXSS：画像共有サービスImgurの埋め込みコンテンツを表示する際のスクリプト処理に問題があり、閲覧者のブラウザに影響する可能性があります。Patchstackのコードレビューでは、寄稿者（Contributor）以上の利用者が埋め込みを作成できることと、影響を受ける人がその内容を閲覧することが条件として示されています。ブラウザ内のスクリプト実行を、サーバー上のRCEと読み替えてはいけません。報告者はZhengyu Liu、Jingcheng Yang、Gavin Zhongです。
7. {status}_{type}フックに渡される偽造可能なパラメーターとアクション名の衝突：WordPressのフックは、特定の処理が起きた際にテーマやプラグインの追加処理を呼び出す仕組みです。投稿状態・種類などから組み立てるアクション名の扱いに衝突が起きると、想定外の追加処理が呼ばれるおそれがあります。Patchstackのコードレビューは、プラグインなどが、十分に検証していない投稿状態・投稿種類をwp_insert_post()へ渡す経路を挙げています。実際の影響は、その経路と呼び出される追加処理によって変わり、この問題だけで必ずRCEや権限昇格が起きるとは断定しません。報告者はWordPressセキュリティチームのAlex Conchaです。

CVE-2026-66666のCNA記録が示す系列別の修正境界は、7.1.0～7.1.2 → 7.1.3、7.0.0～7.0.6 → 7.0.7、6.9.0～6.9.9 → 6.9.10、6.8.0～6.8.10 → 6.8.11、6.7.0～6.7.9 → 6.7.10、6.6.0～6.6.9 → 6.6.10です。この一覧はコメント露出のCVEに対する記録であり、他の6修正の影響範囲を示すものではありません。出典：CVE-2026-66666公式JSON

ImgurのXSSは、本体を更新した後も保存済みの埋め込み内容を別に確認する必要があります。 Patchstackは、問題のあるoEmbedの結果がすでにWordPressのデータベースへ保存されている場合、更新後にもその内容が再利用・表示され得ると説明しています。oEmbedは外部コンテンツの埋め込み用の情報を取得する仕組みで、この保存済みデータはブラウザやCDNのキャッシュとは別です。保守担当者は該当する埋め込みの有無と保存内容を確認し、必要な再取得・置き換えを判断します。不審な内容や侵害の疑いがある場合は、先に第12章の初動に沿って記録・保全の要否を判断し、データベースの項目を一括で削除しないでください。出典：Patchstack：保存済みoEmbedへの注意

7件は成立条件も影響も異なります。ログイン権限、閲覧者の操作、保存済みのデータ、連携するコードの条件を各項目に対応させ、ある項目の「認証不要」を他の項目へ広げないことが大切です。また、修正版が10月6日に公開されていても、自社サイトで更新と必要な追加確認が完了したかは、実際の管理状況から確かめます。出典：7.1.3公式リリース・Patchstackのコードレビュー

旧系列向けの修正もあります。 7.1.3公開時の案内は、4.7系まで必要に応じてバックポートを進めると説明しており、公開当日すべての系列へ同時に適用が完了したとまでは述べていません。一方、WordPress公式のリリース履歴と個別のバージョン記録から、7.0.7、6.9.10、6.8.11などが2026年10月6日付で公開され、同じ7件の修正を含むと説明されていることを確認できます。「7.1.3以外は未修正」という断定も、「古い系列の全サイトで適用済み」という断定も誤りです。 個々の系列に修正版が存在するかと、実際のサイトがそこまで更新されているかは別々に確認します。出典：10月公式リリース・公式配布履歴・7.0.7・6.9.10・6.8.11

BricksテーマのCVE-2024-25600：認証不要RCEの事例

CVE-2024-25600は、WordPress本体ではなく、サイトのページを視覚的に構築する「Bricks」テーマに生じた認証不要のRCEです。 2024年2月13日に、開発元はBricks 1.9.6.1を緊急修正版として公開しました。対象とされたのは1.9.6以前のBricksです。WordPress本体を更新しても、脆弱なBricksテーマのプログラム自体は必ずしも修正されません。出典：Bricks公式1.9.6.1・CERT-In CIVN-2024-0057

問題は、Bricksの編集・表示機能に含まれるサーバー側レンダリングのREST APIと、検索条件を組み立てるprepare_query_vars_from_settingsの処理にありました。Patchstackの技術調査によると、この経路では、外部から渡された設定に含まれるPHPの内容が、eval()という文字列をPHPコードとして評価・実行する仕組みへ到達する可能性がありました。通常、表示のために渡された情報はデータとして制限すべきで、攻撃者が指定できる内容をそのまま実行対象にしてはいけません。出典：Patchstackによる技術調査

Bricks側にはREST APIの権限確認処理がありましたが、当時の実装ではnonce（特定の操作に関連付けて検証する値）を主に検証し、WordPress上の適切な利用者権限を十分に確認していませんでした。 しかも対象のnonceは公開ページ側から入手できるため、値を持っていることだけではログイン済みの管理者であると証明できません。Patchstackは、Bricksの通常構成で、認証していない利用者からPHPコード実行が再現可能と報告しました。修正版には利用者権限の検証とPHP内容の適切な処理が追加されています。出典：Patchstack調査と修正解説

公開時点と、後日の攻撃観測を混同してはいけません。 2月13日のBricks開発元の案内は、「そのリリース時点では悪用の証拠がない」と述べていました。その後、Patchstackは2月14日に攻撃試行を初めて監視環境で確認したと記録し、2月19日に技術報告を公開しました。さらに、インド政府のCERT-Inは2月21日付の注意喚起で、現実の悪用があると報告しています。これらは確認時点と証拠の種類が異なる情報であり、開発元の2月13日の説明と後日の悪用報告は必ずしも矛盾しません。出典：Bricks公式2月13日・Patchstack2月19日・時系列・CERT-In2月21日

Patchstackが観測した攻撃試行や悪用後に使われる不正プログラムの報告は、脆弱性に対する攻撃活動を具体的に示します。ただし、その記録だけで全試行が侵害に成功したとはいえません。CERT-Inの悪用報告は別の公的根拠ですが、ここで確認した資料には被害企業名や侵害成功件数の確証はありません。RCEが成立した場合も、まず問題となるのはWordPressを動かすPHPプロセスの権限範囲であり、サーバー全体の管理者権限を即座に取得できると置き換えてはいけません。

WordPress AutomaticプラグインのCVE-2024-27956：SQLインジェクションの事例

CVE-2024-27956は、外部サイトから記事などを自動取得・投稿するWordPress Automatic（Automatic）プラグインのSQLインジェクションです。 影響版は3.92.0以前、当時の修正版は3.92.1です。問題はWordPress本体ではなく、このプラグインが独自に持つPHP処理にあったため、本体だけを更新しても対処は完了しません。出典：Patchstackの脆弱性データベース・Patchstackの技術報告

Patchstackの解析では、プラグイン内のCSV出力に関係するPHP処理が、外部から渡された問い合わせ内容をSQLとしてデータベースへ実行する構造になっていました。途中に認証や整合性を確認するように見える処理はありましたが、未認証のリクエストでも通過し得る欠陥があり、許可されていないSQL文を実行できる状態でした。ここでの問題は、単なる文字列の検索条件の誤りにとどまらず、問い合わせそのものを外部入力に左右される設計と、その入口の認証不備が結び付いたことです。Patchstackによると、開発元は問題のCSV処理ファイルを修正版から削除する方法で対処しました。出典：Patchstack 2024年3月19日技術報告

SQLが実行されれば、WordPressが接続しているデータベースの権限と実際のSQL処理次第で、保存データの閲覧・変更・削除などに影響する可能性があります。WordPressのユーザー情報に関する操作から管理権限の悪用へつながる場合もありますが、SQLiだけでサーバーのOS管理者権限を直接得られるとは限りません。 さらに、WordPressの認証を迂回できることと、外部のすべてのサイトでコード実行に成功することも同義ではありません。出典：Patchstackの技術報告・WPScanの攻撃調査

この件は「悪用の可能性」だけでなく、現実の攻撃活動を観測した報告があります。Patchstackはデータベース上で「Known to be exploited」と表示しています。加えてWPScanは2024年4月24日、3月13日の公開以降に5,576,488件の攻撃試行を記録したと公表し、管理者アカウントの不正作成や不正ファイルの設置などを伴うキャンペーンについて、侵害されたサイトで見られた状況を報告しました。攻撃試行件数は侵害成功件数ではなく、侵害事例の説明から被害企業数を逆算することもできません。出典：Patchstackデータベース・WPScan 2024年4月24日の観測報告

また、Patchstackの「Known to be exploited（KEV）」という表記は、Patchstack自身の脆弱性データベースにおける悪用情報の表示です。米国CISAのKEVカタログに正式登録された事実とは別の確認事項です。2026年10月26日に取得したCISA公式データ（カタログ版2026.10.23）には、CVE-2024-27956の記録はありません。この取得版に掲載がないことは、悪用がないという意味ではなく、PatchstackやWPScanの観測を否定するものでもありません。出典：CISA公式KEVデータ・Patchstack・WPScan

開発元の修正の時系列についても、Patchstackは2月25日に発見・報告、2月27日に3.92.1公開、3月13日にデータベース登録、3月19日に技術記事公開と記録しています。この日付は脆弱性の発見日、修正版の公開日、情報公開日が別であることを示しています。出典：Patchstack技術報告・時系列

WordPress本体と拡張機能では更新先が異なる

必要な修正を適用するには、脆弱性が見つかった「製品そのもの」を特定しなければなりません。 同じWordPressサイトでも、更新先は次のように異なります。

• WordPress本体：WP_QueryやREST API、テンプレート処理など、WordPress共通機能の問題は、WordPress本体の該当系列に対する修正が必要です。
• テーマ：Bricksのようにテーマ固有のPHP処理に問題がある場合、該当テーマの修正版が必要です。WordPress本体を更新しただけでテーマまで修正されるとは限りません。
• プラグイン：WordPress Automaticのように追加機能が問題の発生場所であれば、そのプラグインの修正版が必要です。テーマやWordPress本体の更新では、別製品の欠陥が解消したと判断できません。
• PHPの実行環境：PHP本体の脆弱性には、サーバー側で実際に利用されるPHPの修正が原則として必要です。PHPを更新しても、WordPressや拡張機能の固有の弱点が自動的に直るわけではありません。

実務上、サーバー会社がPHPを管理し、サイト運営者や保守会社がWordPress本体・テーマ・プラグインを管理する場合があります。ただし、誰に更新の権限と責任があるかはホスティング方式や保守契約によって異なります。 全部を一人が更新するとも、サーバー会社がすべて引き受けるとも決めつけられません。必要なのは、何の製品にどの修正が必要かを分け、その修正が実際のサイトへ適用されたことまで確認することです。出典：WordPress公式セキュリティガイド・WordPress公式のPHP更新案内

なお、脆弱性の存在と、すでに侵害されているかどうかは別問題です。修正版へ更新したとしても、更新以前に不正なアカウントやファイルを作られていた場合、それらが自動的に消える保証はありません。更新手順は第10章、安全な状態確認は第9章、異常が疑われる場合の初動は第12章で扱います。

事例別の影響条件・修正・実際の悪用状況の比較

修正が必要かを判断するときは、CVE名より先に「どの系列・製品を使っているか」を確認します。 次の表T07は2026年7月17日と9月22日の各脆弱性が公表された当時のWordPress本体の修正版を示します。10月6日公開の7.1.3など、後続の修正版への更新状況とは混同しないでください。表中の「対象外」は、そのCVEの開発元アドバイザリに列挙されないという意味であり、WordPressの別の問題まで安全という意味ではありません。出典：7月SQLi GHSA・7月REST GHSA・9月テンプレート GHSA

表T07｜WordPress系列とCVE別修正版

利用中の系列の行で対象CVEを照合し、その後の修正履歴も確認してください。現在の推奨版一覧としては使いません。

表にある旧系列向けの修正はCVE-2026-87902に対する9月当時の修正です。旧系列の修正版が存在しても、別のCVEに対応済みか、長期保守が継続するかまで示しません。実際に、10月6日の別のセキュリティ更新では7.1.3だけでなく、7.0.7、6.9.10、6.8.11などが公開されています。「9月時点の修正版」で止まらず、CVE別・公表日別に修正履歴を見比べる必要があります。出典：WordPress公式リリース一覧・7.1.3公式情報

表T08｜脆弱性別の影響条件・修正・悪用状況

「実証」は一定条件で再現できたこと、「攻撃観測」は試みの記録、「実被害」は現実のサイトで不正な変更・設置などが確認されたことです。 公的機関が公表する悪用情報にも、CISA自身のKEVへの掲載と、別機関によるその紹介や注意喚起があります。発表主体と根拠を明示し、同じ事象を独立した被害報告として重ねて数えないようにします。特に試行件数を被害件数として引用したり、個別CVEのKEV採録だけで自社の侵害を確定したりしないでください。

KEVに関する上表の確認は、2026年10月26日に取得した公式カタログ版2026.10.23に限ります。同じ取得版にCVE-2026-66666とBricksのCVE-2024-25600の記録もありませんが、非掲載を、未悪用や修正不要の証明には使いません。出典：CISA公式KEVデータ

この章を踏まえて自社サイトについて確認したいのは、利用中のWordPress本体の系列と修正履歴、使っているテーマ・プラグインの製品名と版、PHPの稼働環境、そしてそれぞれを誰が保守しているかです。脆弱性ニュースを「WordPress全体が危険」「最新版のWordPress本体だけで対処完了」とまとめず、問題のある部品と、その部品に固有の攻撃条件・修正版を照合することが適切な対応につながります。

関連する説明：テーマ・プラグインの棚卸し／更新と依存関係／侵害後の復旧
この章の目次へ・全体の目次へ

第9章

自社のWordPressサイトの状態を安全に確認する方法

自社サイトの管理状態は、制作・保守資料と、許可されたWordPress管理画面・サーバー管理画面を照合することで確認できます。 最初から専門的な検査を行う必要はありません。確認すべきなのは、利用中の製品とバージョン、更新の状態、管理できる人、ログイン対策、バックアップと保守の担当です。

この章でわかること

• WordPressを利用しているかの確認
• WordPress本体とPHPのバージョン確認
  • WordPress管理画面の「サイトヘルス」で確認する
  • サーバー管理画面で確認する場合
• テーマ・プラグイン・自動更新の状況確認
• 管理者アカウント・権限とログイン対策の確認
• バックアップ・復元履歴・保守担当者の確認
• 外部から見える情報だけでは判断できないこと
• 自分で確認できない項目を整理する

第7章ではPHP本体、第8章ではWordPress本体・テーマ・プラグインの脆弱性と修正を説明しました。そこで紹介した「修正版が公開された」という情報と、「自社サイトへ必要な修正が適用されている」という事実は異なります。本章では、その違いを確かめるために何を、どこで、誰の権限で見て、何を控えるかを整理します。侵入試験や脆弱性スキャン、設定変更は行わず、まず閲覧と既存資料の確認にとどめます。出典：WordPress公式セキュリティガイド・サイトヘルス画面

確認結果は、対象サイトのURL、確認日、確認した人、情報源とともに社内の管理資料へ記録してください。画面を見られなかった項目は「未確認」とし、「問題なし」とは書きません。なお、すでに見覚えのない管理者、無断で追加されたページ、不審な転送などがある場合は、通常の自己点検を続けるより第12章の侵害時対応を優先してください。

WordPressを利用しているかの確認

最も確実なのは、制作・運用の記録、または正当な管理権限で確認する方法です。 自社サイトの制作契約書、納品書、運用マニュアル、保守契約、サーバーの契約・設置資料を見て、使用CMSと対象ドメインが明記されているかを確認します。制作会社や社内のWeb管理担当者に、現在公開されているサイトでWordPressを使っているかを質問してもかまいません。「以前はWordPressだった」という回答だけでなく、現在の公開環境について確かめることが大切です。

WordPressの管理画面へすでに正式なアクセス権があるなら、ログイン後のダッシュボードや「ツール → サイトヘルス」を確認できます。ただし、管理画面の一部に入れたことだけでは、トップページからすべての下層ページまで同じ仕組みで表示していると証明できません。WordPressを記事の編集用に使い、公開ページは別の仕組みで配信している構成や、複数サイトを組み合わせた構成もあり得ます。必要なら制作・保守担当者に公開構成を確認します。出典：サイトヘルス画面・WordPress公式セキュリティガイド

サーバー管理情報や設置資料を確認できる場合は、対象ドメインとWordPressの設置先の対応も控えます。会社が契約しているサーバーにWordPressのファイルがあることと、現在の公開サイトがその設置を利用していることも同じではありません。テスト用・旧サイト用の設置が残っている場合があるためです。

一般の閲覧者でも、公開ページのHTMLにwp-contentのような文字列が見つかれば、WordPressを利用している可能性を推測できます。しかし、これは手掛かりにすぎません。キャッシュや静的な書き出し、過去のファイル、構成変更などが影響し得るため、文字列が見えることだけで現在の稼働形態や安全性は確定できません。逆に、痕跡が見えないことも「WordPressではない」という証明にはなりません。 自社の管理資料と担当者の回答で確認し、外部のサイトを検査する行為は不要です。

WordPress本体とPHPのバージョン確認

WordPress本体のバージョンとPHPのバージョンは、別々に記録します。 WordPressはサイトを管理するソフトウェア、PHPはその処理をサーバー側で実行する環境だからです。WordPressが新しくてもPHPが古い場合があり、その逆もあります。出典：WordPress公式のPHP更新案内

WordPress管理画面の「サイトヘルス」で確認する

WordPressの標準的な管理画面で確認できる権限がある場合は、次の順番で見ます。

1. 「ツール → サイトヘルス → 情報 → WordPress」を開き、「バージョン」の値を控えます。これは、そのWordPress設置で現在使われている本体の版です。
2. 「ダッシュボード → 更新」を開き、WordPress本体に更新の案内があるか、現在の版に関して何が表示されるかを確認します。ここには更新のあるプラグイン・テーマや翻訳の案内も表示される場合があります。確認だけを行い、更新・再インストールのボタンは押しません。
3. 「ツール → サイトヘルス → 情報 → サーバー」を開き、「PHPバージョン」の値を控えます。表示されるのは、このWordPressの管理画面の要求を処理するPHP環境が報告したバージョンです。必要に応じて同じ画面の「PHP SAPI」（PHPの実行方式を表す情報）も担当者に伝えられます。（出典：サイトヘルスの公式操作経路・更新画面の公式説明・WordPress公式PHP確認案内・サイトヘルスの実装資料）

「サイトヘルス」には「ステータス」と「情報」があります。「ステータス」はWordPressが実施する検査の結果を表示し、重要な問題や改善の推奨を確認する入口です。一方、「情報」は現在の設定や版などの詳細を参照する画面で、閲覧するだけなら設定を変更しません。ステータスに合格した検査が並んでいても、検査対象外の脆弱性や保守上の問題が存在しないことまでは証明できません。出典：WordPress公式サイトヘルス

管理画面で表示される項目は利用者の権限やサイト構成によって異なります。上記は標準的な管理者向けの経路です。記事を編集する権限しかない担当者には「サイトヘルス」「更新」などが表示されない場合があります。メニューが見当たらなければ、URLを推測してアクセスしたり権限を変更したりせず、管理者または保守担当者に確認を依頼してください。出典：WordPress公式の役割と権限

「更新のお知らせがない」ことと「必要なセキュリティ修正がすべて適用された」ことは別です。 管理画面の更新通知は、取得できる更新情報やサイトの設定・配布形態に左右されます。たとえば、WordPressの過去の系列にも個別のセキュリティ修正版が提供される場合があるため、「新しい大きな版への案内がない」という表示だけで、その系列のすべての問題に対応済みとは判断しません。現在の版番号と、開発元のセキュリティリリース・該当系列の修正履歴を照合します。第8章の修正版一覧は各脆弱性が公表された当時の境界なので、後日に公表された別の修正まで含む一覧として使わないでください。出典：WordPress公式更新画面・WordPress公式リリース一覧・7.1.3の公式リリース

WordPressの「情報」にはサーバーやデータベースに関する詳細も含まれます。「サイト情報をクリップボードにコピー」した全文を公開フォームや不特定多数のチャットへ貼り付けないでください。 まずは必要な版番号、確認日時、対象ドメイン、画面名だけを社内の管理記録へ転記すれば十分です。出典：WordPress公式サイトヘルス

サーバー管理画面で確認する場合

WordPressの管理画面に入れないときは、サーバー契約者や保守担当者へ「その公開サイトで実際に稼働しているPHP」を確認します。 レンタルサーバーなどでPHP版の表示機能がある場合、正式な契約者権限で管理画面を参照します。ただし、PHP版の表示場所や機能名はサーバー会社・契約プランによって異なるため、確認していないサービス固有の画面名はここでは指定しません。どこを見ればよいかわからなければ、事業者の公式マニュアルかサポート窓口に確認します。出典：WordPress公式PHP更新案内

このときは対象のドメイン／サブドメイン、公開サイトかテストサイトか、紐づくPHP設定、確認日時を一組で扱ってください。同じ契約に複数のサイトがある場合、それぞれ別のPHP版や実行方式が使われていることがあります。サーバー全体の「利用可能なPHP一覧」や、別サイトの設定値を見て、自社の公開サイトでその版が動いていると判断しないことが重要です。

また、技術担当者がコマンドラインでphp -vを確認する場合、そこで分かるのはコマンドライン用のPHP（CLI）の版です。Webサーバーがページ表示に使うPHPとは異なる実行ファイル・設定・版である可能性があります。確認結果が食い違うときは、どのドメインのHTTP要求を、どのPHPプロセスが処理しているかを保守担当者に照合してもらいます。公開サーバーに確認用のPHPファイルを新設したり、phpinfo()の出力をインターネットへ公開したりする必要はありません。出典：PHPの実行方式に関する公式資料・サイトヘルスの実装資料

さらに、配布元が古い系列へセキュリティ修正を取り込むバックポートを採用する場合、画面に出る基本版番号だけで修正状況を決められません。サーバー会社・OS提供元に、実際のパッケージ版・改訂番号、対応したCVE、適用日時、稼働中のPHPへの反映状況を確認します。「修正版を提供中」と「対象サイトへ適用済み」も分けて記録してください。出典：Red Hatのバックポート解説・WordPress公式PHP更新案内

テーマ・プラグイン・自動更新の状況確認

テーマとプラグインは、導入済みの全件を確認し、そのうち現在有効なものを区別します。 テーマはサイトの表示やひな形を担い、プラグインは機能を追加する部品です。インストールされていることと、機能が有効なことは同義ではありません。出典：WordPress公式テーマ画面・プラグイン画面

通常のプラグイン一覧だけでは、実行される部品をすべて把握できない構成もあります。MU（Must-Use）プラグインは特別な場所から自動的に読み込まれるプラグインで、通常の有効・無効の一覧とは扱いが異なります。また、キャッシュやデータベース処理などを補うdrop-in（ドロップイン）という特別な部品が使われる場合もあります。管理画面の分類やサイトヘルスの情報を見ても判断できなければ、保守担当者へ「通常一覧以外の部品があるか、版・更新元・管理責任者をどこで確認するか」を尋ねてください。マルチサイトではネットワーク管理者にも確認します。確認のためにファイルを削除・変更する必要はありません。出典：WordPress公式：MUプラグイン・サイトヘルスのMU・drop-in分類

ただし、無効化されている製品にも脆弱性が存在する場合があります。 ある欠陥が有効化を前提とするかは問題ごとに異なり、ファイルがサーバー上に残っていることが判断に関係する場合もあります。無効化済みだから対応不要と決めず、問題があるかは製品・版・成立条件で確認します。有料だから安全ともいえません。出典：WordPress公式セキュリティガイド・第8章の事例

WordPress公式ディレクトリ以外から購入・導入した有料テーマや有料プラグイン、個別開発された製品には、販売元の配布サイト、契約・ライセンスの有効期間、更新の提供方法、サポート窓口、最後の修正提供情報も必要です。管理画面で更新通知が出ない理由が、単に最新版だからなのか、更新情報を取得できないからなのかを区別してください。導入元がわからなければ制作会社に製品名と配布元の確認を依頼します。出典：WordPress公式更新画面・プラグインとテーマの自動更新

自動更新は、設定と実行結果の二段階で確認します。 プラグイン一覧には自動更新の状態を示す列があり、テーマの詳細にも個別の自動更新設定があります。ここでは有効／無効という表示を見るだけにとどめ、切替操作はしません。WordPress本体の自動更新は拡張機能とは扱いが異なり、構成・管理方針によって適用範囲が変わります。管理者や保守会社に、本体・テーマ・プラグインをそれぞれ誰が管理するか尋ねてください。出典：拡張機能の自動更新・WordPress本体の自動更新仕様

自動更新が「有効」でも、予定実行が動かない、サーバーの設定に制限される、更新に失敗する、配布元が更新情報を提供していない、といった理由で修正が適用されない場合があります。WordPress公式は、自動更新の成功／失敗を知らせるメールや、サイトヘルスでのスケジュール実行エラーの確認を案内しています。設定の表示、最終更新結果、現在の版、配布元の修正版の有無を分けて見ます。出典：WordPress公式の自動更新と失敗時の説明

管理者アカウント・権限とログイン対策の確認

画像を拡大する ＋

「誰がログインでき、何を変更できるか」を確認します。 WordPressでは、ログインできることと、サイト全体を管理できることは異なります。標準的な単一サイトでは「ユーザー → ユーザー一覧」に利用者と役割が表示され、役割ごとの絞り込みも可能です。原則として管理者権限を持つ人や、利用者一覧を参照する権限を与えられた人が確認します。記事の更新担当者には、この一覧が見えない場合があります。出典：WordPress公式ユーザー一覧・役割と権限

初めに、管理者（Administrator）アカウントの件数、社内の利用責任者、現在も業務上必要かどうかを管理者へ確かめます。退職者、異動者、契約終了した制作会社の担当者、用途が不明なアカウントが残っていないかも確認対象です。担当者個人を特定する詳細は、権限を持つ社内管理者がアクセス制限された台帳で扱い、この記事や公開フォームを通じて、ログイン名・メールアドレスの一覧を収集することはありません。

WordPressの標準的な役割では、Administrator（管理者）はサイト管理、Editor（編集者）はほかの利用者の記事を含む記事管理、Author（投稿者）は主に自分の記事の公開・管理を行います。Contributor（寄稿者）やSubscriber（購読者）にも別の権限範囲があります。必要以上に管理者を増やさず、業務に必要な役割かを確認することが目的です。なお、マルチサイトのSuper Admin（特権管理者）、追加プラグインや独自設定による権限変更がある場合、標準の役割名だけで実際の権限を確定できません。出典：WordPress公式の役割と権限一覧

ログイン対策は、多要素認証（MFA）、ログイン試行制限、アクセス制限について、導入の有無だけでなくどのログイン先・どの利用者に適用されているかを担当者に確認します。多要素認証は、パスワードだけでなく別の要素による本人確認を求める仕組みです。導入プラグインがあるだけでは、管理者全員に適用されているとは限りません。ログイン制限やアクセス制限も、サーバー、WordPressのプラグイン、ネットワーク側のどこで実施しているかによって範囲が異なります。設定画面が不明なら提供元・保守担当者に確認を依頼してください。出典：WordPress公式の多要素認証解説・セキュリティガイド

さらに、WordPressへのログイン、サーバー契約者の管理画面、ドメイン管理、バックアップ保存先、外部サービスは、利用者と認証情報が別になっていることがあります。「WordPressの管理者が分かるので、サーバーも管理できる」とは判断しないでください。各管理先の担当部署・契約者・緊急連絡先を整理します。パスワード、認証コード、復旧コード、秘密鍵は点検表へ書かず、公開やメールへの添付も避けます。

バックアップ・復元履歴・保守担当者の確認

「バックアップがあるか」だけでなく、「どのデータを、いつ、どこへ保存し、誰が戻せるか」を確認します。 WordPressの一般的なサイトでは、画像・テーマ・プラグイン・設定ファイルなどのファイルと、記事・ユーザー情報・各種設定を含むデータベースが別の場所にあります。片方だけの保存では、元のサイト全体を戻すための情報が不足する場合があります。出典：WordPress公式バックアップ解説

サーバー会社が提供するバックアップ、WordPress内部のバックアッププラグイン、制作会社が保管している独自バックアップは、それぞれ対象、保存場所、保存期間、取得頻度、復元の権限が異なる可能性があります。サーバー会社の機能があるから、WordPressのファイルもデータベースも必要な時点まで保存されているとは限りません。複数の保存方法を使う場合は、どの保存物に何が含まれているのか分けて確かめます。出典：WordPress公式バックアップ解説

確認するのは、自動取得か手動取得か、最後に正常取得した日時、対象範囲、保存先の管理者、保存期間、取得失敗の通知先です。「自動取得を設定している」という説明だけでなく、最後に取得できた実績を確認してください。共有する際は、保存先のアカウント名やアクセス用URL、バックアップ本体の中身などを公開せず、社内で管理します。

そして重要なのが復元テストの履歴です。復元テストとは、用意したバックアップを、許可されたテスト環境などで実際に読み戻し、サイトの必要なデータや機能を戻せるか確認する試験です。「ファイルが存在する」は保存の確認、「必要な範囲を復元できた」は別の確認結果です。記録するのは実施日、担当者、対象サイトと保存世代、テスト環境、確認できた範囲、失敗・未実施の有無。実際にテストをしていなければ「復元未確認」とします。本章では復元を実行しません。出典：WordPress公式バックアップ解説

なお、正常に復元できたとしても、侵害の原因が取り除かれたことにはなりません。 不正な変更が含まれた時点のバックアップを戻せば、その変更も戻る可能性があります。復元の実施方法は第10章、侵害が疑われる場合の原因調査や復旧の考え方は第12章で扱います。

アクセス履歴やエラーを調べるためのログについても、どこに保存され、誰が確認でき、いつまで残るのかを保守担当者に尋ねておきます。WordPressの管理画面ですべてのログを見られるわけではなく、サーバー会社や追加機能が保管している場合があります。ログが保存されていることも、侵害がないことを保証しません。出典：WordPress公式セキュリティガイド

最後に、保守契約が何を対象とするかを確認してください。WordPress本体、テーマ、プラグイン、PHP、サーバー、バックアップ、障害調査を誰が担当するかは契約によって異なります。契約先、担当窓口、通常時の連絡方法、重大な問題が起きた場合の緊急連絡先を控えます。「制作会社に頼んだことがある」と「現在も保守契約が有効」は同じではありません。

外部から見える情報だけでは判断できないこと

サイトが正常に表示されることや、外部ツールが問題を検出しなかったことだけでは、安全性を確定できません。 公開画面から確認できるのは、外から見える通信と表示の一部に限られ、サーバー内の修正適用状況、未公開の設定、権限、バックアップや過去の侵害の有無までは必ずしも分かりません。出典：WordPress公式セキュリティガイド・OWASPの検査限界の説明

• ページが正常表示される：通常の閲覧に応答していることは分かりますが、別の機能や未確認の入力に弱点がないとは証明できません。
• HTTPSが有効である：ブラウザとの通信を保護する重要な対策ですが、テーマ・プラグイン・PHPの欠陥や管理権限の問題を修正する機能ではありません。
• WordPressのバージョン番号が表示されない：公開情報を減らす工夫にはなっても、実際のソフトウェアが更新されたかは別です。
• 管理画面のURLを変更している：一般的なURLへのアクセスを減らす場合はあっても、ログインの本人確認や非認証機能の脆弱性を解消するものではありません。
• セキュリティプラグインを導入している：対象となる機能の保護に役立つ場合はありますが、導入しただけで設定、動作、適用範囲、ほかの部品の更新が完了するわけではありません。
• 外部診断ツールで問題が検出されなかった：検査が扱う対象・技術・権限・検出方法には限界があります。検出対象外の問題や、公開側から判別できない状態は残り得ます。

これらの対策が無意味なのではありません。防いでいるリスクが異なるため、一つを導入しただけで別の管理項目を「確認済み」にしない、ということです。OWASPのWeb Security Testing Guideも、自動的な検査のみでは個別の実装や業務処理の問題を十分に評価できず、問題が出ない結果を安全の証明として扱えないと説明しています。ここで第三者サイトのスキャンを勧めたり、検査を実行したりするものではありません。出典：OWASP WSTG・WordPress公式セキュリティガイド

自分で確認できない項目を整理する

調べられなかったことは「未確認」と記録し、その情報を管理できる人へ質問すれば十分です。 経営者や広報担当者がPHPの実行方式やパッチ管理を自力で操作する必要はありません。ただし、担当者に聞くための対象と質問を明らかにしておくと、回答を後から照合しやすくなります。

表T09｜WordPressサイトの安全な自己点検シート

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

画面の操作経路と標準的な権限はWordPress公式のサイトヘルス・更新・テーマ・プラグイン・ユーザー資料に基づきます。サーバーと保守契約の項目は個別環境で異なるため、特定サービスの操作画面を一律には指定していません。出典：サイトヘルス・更新画面・テーマ・プラグイン・ユーザー・バックアップ

各項目は、確認状態「確認済み／未確認／対象外」と、対応状態「対応不要／要対応／対応中／完了」の二つに分けて記録します。確認状態は何が分かったか、対応状態は情報の確認や問題の是正のための作業がどこまで進んだかを示します。表を横に広げず、「記録する内容」の欄などに二つのラベルを添えれば管理できます。確認日と根拠、必要な作業・担当者・期限、完了を裏付ける結果も残してください。

例えば、修正版が未適用だと確認できた項目は「確認：確認済み／対応：要対応」、バックアップ範囲の問い合わせ回答を待つ項目は「確認：未確認／対応：対応中（問い合わせ回答待ち）」です。依頼した更新とその後の確認を終えた場合は、その作業の根拠を付けて「確認：確認済み／対応：完了」と記録します。「確認済み」は事実の確認、「完了」は記録した個別作業の完了であり、どちらもサイト全体の安全を保証しません。

「対象外」とする場合は理由を明記します。例えば公開会員登録機能が存在しなければ、その機能の点検は対象外にできますが、WordPress管理者の認証まで対象外になるわけではありません。情報が不明なら「対象外」や「対応不要」へ置き換えず、確認状態を「未確認」として理由と次の確認作業を残します。一部だけ確認できた場合も、確認できた対象と未確認の対象を分けて記録してください。

重大な脆弱性の情報があり影響や適用状況が不明なら、単なる定期点検待ちにせず、対象製品・版・構成と修正状況を保守担当者や提供元へ優先して確認してください。異常が疑われる場合は第12章の判断を優先します。

必要な情報が揃ったら、実際の更新や検証は第10章に沿って担当者と計画します。本章では確認のためにサイトを変更する必要はありません。

WordPressやPHPの更新状況、管理状態がわからない場合は、WordPress無料診断からご相談いただけます。

関連する説明：更新前の準備／継続点検の記録／異常があるときの初動
この章の目次へ・全体の目次へ

第10章

PHP・WordPressを安全に更新・保守する方法

安全な更新とは、新しい版を入れる作業だけではなく、更新前の状態を残し、変更後に重要な機能を確かめ、問題があれば復旧できるように進めることです。 第9章で確認したPHP・WordPress・テーマ・プラグインの版、権限、バックアップ、保守担当者を、ここからは具体的な作業計画にまとめます。確認できていない項目があれば、「おそらく大丈夫」として進めず、担当者に確認するか、影響を限定できる方法を選びます。

この章でわかること

• PHPとWordPress本体は別々に更新する
• テーマ・プラグインを更新し、不要なものを削除する
• 修正版・LTSバックポート・サポート終了の扱い
• 更新前のバックアップ・互換性確認・テスト環境
• 更新後の表示・フォーム・ログイン・更新失敗確認
• バックアップに必要なファイルとデータベース
• 復元テストと復旧時に気を付けること
• 重大な脆弱性が公表された際の優先対応

WordPress公式も、本体やプラグインを更新する前のバックアップと、更新に失敗した場合の復旧を前提とした手順を案内しています。一方、バックアップがあっても、必要なファイルやデータが揃っていなければ元に戻せません。準備→検証→適用→確認→記録をひと続きの作業として扱うことが重要です。出典：WordPress本体の更新手順・WordPressのバックアップ

PHPとWordPress本体は別々に更新する

PHPとWordPress本体には、それぞれ独立した修正版と更新方法があります。 WordPressを更新しても、サーバー側で処理を実行するPHPの版は通常それだけでは変わりません。PHPを更新しても、WordPress本体に含まれる不具合や脆弱性が自動的に修正されるわけではありません。2026年10月にWordPress公式がPHP本体の重大な更新を別途注意喚起したことも、この責任範囲の違いを示しています。出典：WordPress公式のPHP更新案内・PHPに関するWordPress公式告知

まず対象サイトごとに、現在の稼働版、更新先の候補、作業権限を持つ人、更新方式、必要な停止時間を一組で整理します。PHPの更新はサーバー会社の契約者画面や事業者側の管理によることが多く、WordPressの管理者権限だけでは操作できない場合があります。共用・マネージドホスティングなら、提供元が変更できるPHP系列、変更単位（サイトごと／契約ごと）、修正提供状況、反映時刻と切り戻し条件を公式マニュアルや窓口で確認します。特定のサーバー会社に共通する操作ボタンはありません。出典：PHP更新のWordPress公式案内・PHPの設定ファイルと適用範囲

自社管理サーバーでは、OSとPHPのパッケージを管理する担当者が、使用している配布元のアドバイザリに基づき更新を計画します。パッケージを入れただけで終わりではありません。Web要求を実際に処理するPHP-FPMやApacheモジュールなどへの反映、必要なプロセスの再起動・切替、関連拡張機能と設定の読み込み、サーバーログを確認する責任があります。これらは運用構成で異なるため、実行するコマンドや再起動対象を一律には指定できません。 PHPのコマンドライン用版とWeb用の稼働版も異なり得ます。出典：PHP-FPM公式説明・PHP設定ファイルの公式説明・バックポートの仕組み

WordPress本体は、標準的な管理者権限があれば「ダッシュボード → 更新」で更新案内を確認でき、対象版の説明を読んだうえで「今すぐ更新（Update Now）」から更新できます。WordPress公式には手動でファイルを入れ替える方法もありますが、ファイル所有権、更新対象、データベースの更新が絡むため、画面からの更新が失敗した際に経験のない担当者が即座に置換を試す手順にはしません。管理画面ではなくホスティング側でWordPressを集中管理している契約なら、そちらの手順と責任分担を優先します。出典：WordPress更新画面・本体更新の公式手順・詳細な更新手順

自動更新と手動更新も区別します。 WordPress本体は保守・セキュリティ更新と機能追加を伴う大きな更新で設定が異なる場合があり、新規設置時期やホスティングの管理方針にも左右されます。テーマ・プラグインは別途自動更新の設定を持ちます。「自動更新が有効」という表示だけでは更新成功の証拠にならないため、実行通知と実際の版を照合します。重要な独自機能があるサイトでは自動更新の監視体制も合わせて決めます。出典：WordPress本体の自動更新の公式説明・拡張機能の自動更新

更新順序は「必ずPHPから」でも「必ずWordPressから」でもありません。例えば、予定するPHP版に現在のテーマが対応していないなら、互換性のあるテーマ・プラグインへ先に更新する必要があるかもしれません。逆に、WordPress本体の更新先が新しいPHPを前提とするなら、別の順序や段階的な移行が必要です。重大なPHPの修正が急がれるときは、互換性確認の範囲と更新までの暫定措置を担当者が同時に判断します。WordPressが案内する最低実行条件と、PHP本家のサポート期限は別なので、「WordPressが動く最低版」だけで採用するPHP版を決めないでください。出典：WordPressのシステム要件・PHPの移行時の互換性変更・PHPサポート期間

変更後は、WordPressのサイトヘルスのWeb要求を処理したPHPの版、WordPress本体の版、提供元の更新履歴を確認します。サーバー画面で「選択した版」や端末のphp -vを見ただけでは、公開サイトの処理がその版に切り替わった証明にはなりません。出典：サイトヘルス・PHP実行情報の根拠

テーマ・プラグインを更新し、不要なものを削除する

テーマとプラグインは、WordPress本体と別に、導入済み製品ごとに更新先を決めます。 有効なプラグインは機能が動いている状態、無効なプラグインは通常の有効化による動作を止めた状態です。ただし、無効にしてもファイルが残る場合があります。危険性は個々の脆弱性の到達経路や有効化条件によるため、「無効なら安全」とも「無効なら必ず攻撃される」とも判断しません。出典：WordPressのプラグイン管理・WordPressのセキュリティ管理

標準的な管理画面では、「プラグイン → インストール済みプラグイン」または「ダッシュボード → 更新」で通知を確認し、製品詳細や変更履歴を読んで対象を選択します。テーマも「外観 → テーマ」の詳細や更新案内から確認します。更新する権限を持つ担当者は、バックアップと更新前テストを確認した後、対象製品を更新し、フォーム、表示、管理画面などその製品が担当する機能を個別に再検証してください。複数製品を一括更新する機能はありますが、障害が出たとき原因を切り分けにくくなるため、重要な機能を持つ製品は段階的に更新して結果を記録する方法が適しています。出典：プラグイン更新の公式手順・テーマ管理画面・ダッシュボード更新画面

公式ディレクトリ配布の製品はWordPress側で更新が案内されることがありますが、外部配布・有料製品は販売元やライセンスの状態、更新提供方法を別に確認します。有効なライセンスがないと更新ファイルを取得できない、制作会社の契約を通して配布される、ZIPの差し替え手順が指定されているなどの違いがあります。更新通知が表示されないだけでは「最新版」とは判断できません。提供元の正規の変更履歴と、使用中のバージョン・適用権限・ライセンス条件を照らし合わせます。出典：WordPressの更新管理・拡張機能の自動更新

更新前には、対応するWordPress版・PHP版、依存する別プラグイン、予約・決済・会員などの関連機能、独自改修を確認します。親テーマのソースを直接書き換えている場合、更新で変更が失われ得ます。子テーマは改修を親テーマから分離する仕組みですが、親テーマ更新後の表示・テンプレート・関数の互換性を保証するものではありません。カスタマイズ内容の差分や開発者の連絡先を記録し、不明な場合は制作者と調整してから適用します。出典：子テーマの公式説明・本体ファイル上書きの注意

使っていない製品は、利用状況と依存関係を調べてから削除を判断します。 管理画面で有効になっていないテーマも、有効な子テーマが参照する親テーマなら必要です。有効化状態だけで削除候補にせず、親子の関係、別プラグインが呼び出すライブラリ、作業時に必要な保守機能、今後の切り戻しに使う資料を確認します。削除候補は、設定やデータのバックアップを取り、業務上の必要性と代替策を確認したうえで、権限を持つ担当者が進めます。WordPressの通常のプラグイン削除は無効化後に「削除」ですが、製品によってはアンインストール処理で設定値や独自テーブルまで削除され得ます。停止しただけとアンインストールは別の操作です。自動的に読み込まれるMU（Must-Use）プラグインや、キャッシュ・データベースなどの処理を補うdrop-inは、通常のプラグインと更新・停止・削除の管理方法が異なる場合があります。第9章で整理した構成と管理担当者を照合し、通常一覧にないことを不要の根拠にせず、保守担当者が提供元の手順に沿って判断してください。出典：公式プラグイン管理・サイトヘルスの構成分類・アンインストール時のデータ処理・親子テーマの関係

更新が長く止まっている製品やサポート終了品は、保守終了の発表、最終修正版、代替品・機能廃止の可否を調べます。代替品へ移す前に機能と保存データの移行方法を確認し、今ある製品を直ちに削除しないことが大切です。移行できない間は、該当機能の利用停止などの暫定策が成り立つかを専門担当者に相談します。

修正版・LTSバックポート・サポート終了の扱い

更新先を判断するときは「版番号が新しいか」だけでなく、「誰が、何を、いつまで修正するのか」を確認します。 PHP本家は系列ごとに通常の修正期間と、重要なセキュリティ修正に限定した期間を設けています。2026年10月26日に確認した公式サポート表では、PHP 8.2は2026年12月31日、8.3は2027年12月31日、8.4は2028年12月31日、8.5は2029年12月31日までが各系列のセキュリティサポート期限です。8.2・8.3は通常の機能・不具合修正期間を過ぎ、重要なセキュリティ修正に限定された段階です。サポート期限は「そこまで無条件に安全」という保証ではなく、稼働環境が実際の修正版を適用していることが別途必要です。出典：PHP公式サポート対象一覧

WordPress本体はこれと同じ期間保証ではありません。WordPress公式のサポート方針では、積極的なサポート対象は最新のメジャー系列であり、旧系列向けのセキュリティ修正は必要に応じた提供で、保証された期限や共通のLTS系列はありません。 過去の系列に修正版があることを、「その系列は何年でも使い続けられる」という保証へ読み替えないでください。テーマ・プラグインのサポート期間も、それぞれの開発元・販売元の公表条件を確認する必要があります。出典：WordPress公式サポート方針・WordPress 7.1.3の公式告知

バックポートとは、上流の新しい版に入ったセキュリティ修正を、配布元が管理する古い系列・パッケージへ取り込むことです。OSベンダーやホスティング会社がPHPの表示上の基本版番号を保ち、パッケージ改訂番号だけを進める場合もあります。そこで、PHP本家のリリース番号だけを見て未修正と決めず、配布元のアドバイザリに記された対象CVE、パッケージ名と改訂番号、対象サーバーへの適用日時、稼働プロセスへの反映をそろえて確認します。一方、事業者が修正を配布していても、契約中の環境へ適用されていなければ完了ではありません。出典：Red Hatのバックポート解説・PHP公式の継続更新指針

LTS（Long Term Support）は、提供元が指定する製品や系列に対する長期サポートの呼称で、対象範囲・期限・修正の種類は契約や配布元によって異なります。PHP本家のサポート表と、OSやホスティングの延長保守、WordPress本体の旧系列バックポートをひとまとめに「LTSだから安全」と呼ぶのは不正確です。サポート期限を迎える場合は、まだ受けられる修正を確認しながら、互換性試験、移行先の選定、予算と担当者、切り替えの時期を計画します。出典：PHP公式サポート表・WordPress公式サポート方針・配布元のバックポート説明

2026年10月の事例も、公表当時の修正版と現時点の修正状況を区別して読む必要があります。10月21日のPHPの2件（CVE-2026-109618／CVE-2026-109619）については、当時の公式修正版が8.2.35／8.3.36／8.4.27／8.5.12でした。10月23日の別件CVE-2026-115560は、特殊なセッション設定とアプリケーション処理の組み合わせに関する注意喚起であり、21日の修正版で直ったとは扱えません。10月23日時点のPHP公式は、次の通常リリースで正式な個別アドバイザリを公開すると記載しています。2026年10月26日にPHP公式告知と変更履歴を再確認した範囲では、その後の正式な修正版番号と完全な個別アドバイザリは確認できていません。 すべてのPHPサイトが該当する問題ではなく、成立条件と提供元の最新案内を追う必要があります。出典：PHP公式2026年ニュース・PHP公式変更履歴・PHP開発元の個別アドバイザリ

また、2026年10月6日のWordPress 7.1.3には当時7件のセキュリティ修正が含まれ、旧系列にも必要に応じて修正が提供されています。これはWordPress本体の更新事例であり、PHP本体や個別のテーマ・プラグインの修正完了を意味しません。公開後にさらに修正が追加されることもあるため、記事中の当時の版をそのまま将来の更新先として固定しないでください。出典：WordPress公式7.1.3告知・WordPress公式配布履歴

更新前のバックアップ・互換性確認・テスト環境

更新前に必要なのは、戻せる状態の確保と、変更の影響を判断できる準備です。 作業責任者、実際にサーバーやWordPressを操作できる人、バックアップ・復元ができる人、問題発生時に判断する人を決めます。営業時間、予約受付、決済、掲載情報の更新予定などを確認し、利用者への影響を抑えられる日時を選びます。急ぎのセキュリティ修正で延期が危険な場合も、作業中の連絡手段と復旧担当者は明確にしてください。出典：WordPress更新前の準備・WordPressバックアップの公式案内

一般的な進め方は次のとおりです。実際のサーバーを一律の順序で変更するためのコマンド列ではなく、担当者間で確認する工程を示しています。

1. 変更対象と完了条件を決める。 公開サイト・テストサイトの区別、現在の版、更新先候補、影響する機能、担当者、連絡先を記録します。PHP、WordPress本体、拡張機能のどれを変えるかを曖昧にしません。
2. バックアップの取得範囲と復元方法を確認する。 ファイルとデータベースの両方、特殊な保存先、取得時刻と保存先を確認します。終了通知だけでなく、ファイルの存在・容量・読出し・復元の可否を確かめ、必要に応じて復元テストを実施します。
3. 互換性と変更履歴を照合する。 WordPressとPHPの推奨条件、テーマ・プラグインの対応版、サーバーのPHP拡張・設定、独自コード、外部連携を確認します。更新先のリリースノートには変更・廃止機能が含まれる場合があります。
4. 複製・起動前に隔離を確認し、テスト環境で予行する。 実顧客への通知や本番サービスへの書き込みを止める設定を先に確認します。そのうえで、可能なら実際のPHP版・拡張・プラグイン・設定に近づけ、更新後の表示、フォーム、ログイン、業務機能を検証します。本番との差は一覧にして残します。
5. 開始・中断・復旧の判断基準を共有する。 例えばバックアップの取得結果が不明、互換性の重大な問題が判明、重要機能がテストで動かない、担当者不在、想定外のエラーが出た場合は作業を中断し、技術担当者に判断を求めます。
6. 権限を持つ担当者が変更を適用し、直後と後日に確認する。 本番で変える対象を記録し、変更が重なる場合も検証できる単位に分けます。完了判定は更新処理の表示だけでなく、稼働版と機能の検証結果によって行います。

WordPress公式が案内するファイルとデータベースのバックアップは、それぞれ保存手段と復元方法が異なります。取得時刻が大きくずれたファイルとデータベースを無条件に組み合わせると、添付ファイルと記事の参照、設定とプラグインの状態が一致しない場合があります。 予約・注文など更新頻度の高いデータがあるサイトでは、更新中に書き込みが続くか、どの時点の整合性を確保するかまで技術担当者が設計します。単純に「DBを先に取れば絶対に整合する」とは言えません。出典：WordPressバックアップの組み合わせ・データベースのバックアップ

ステージング環境は、本番を直接変更する前に動作を確かめるためのテスト用サイトです。ただし、ドメイン、PHP実行方式、サーバーの設定、データ量、メール・決済サービスの接続先などが本番と異なれば、テスト成功は本番成功を保証しません。差分を記録したうえで、重要な経路を本番適用後にも検証します。WordPress公式もPHP更新に際して、テスト環境と本番環境を分けて検証する考え方を案内しています。出典：WordPress公式のPHP環境説明

本番データの複製や複製先の起動より前に、テスト環境が実際の顧客や本番サービスへ作用しない構成を確認します。 起動後の定期実行などが、操作を始める前にメール・通知・請求や本番データへの書き込みを行う可能性も、連携機能ごとに調べます。必要最小限のテストデータを優先し、本番由来の顧客情報・注文履歴を使う場合は、目的に応じてマスキング（個人を識別できる情報の置換）を行ってください。

確認対象は、メールや決済の送信先だけでなく、外部サービスの接続先と認証情報、定期実行、Webhook（出来事を別のサービスへ通知する仕組み）、外部ストレージにも及びます。提供元のテストモード、送信先の置換、接続制限などを、採用している製品の仕様に合わせて設定します。検索結果に出さない設定だけでは閲覧制限にはならないため、必要なアクセス制限を別に設けます。隔離を確認できない連携は未確認として記録し、担当者と方法が決まるまで本番データの複製・起動や連携試験を始めません。これらは構成に応じた運用上の推奨であり、すべてのステージング製品が自動的に保証する機能ではありません。秘密情報が入ったバックアップも、アクセスできる担当者を限定して扱います。

更新成功の表示だけで、重要な機能の正常性は保証されない

画像を拡大する ＋

図の内容をテキストで読む

通常の進行は更新前 → 更新作業 → 更新後。各段階で未確認・問題があれば、中断の経路へ分岐します。

更新前｜準備・試験

1. ① 対象・担当・操作権限を確認

2. ② 公式修正情報と互換性を確認

3. ③ ファイル＋DBを保存／復元可能性を確認

4. ④ 複製を起動する前に外部連携を隔離・試験

5. ⑤ 開始条件と中断基準を合意

更新作業｜承認された範囲

1. ⑥ 承認された対象だけを更新

2. ⑦ 実際に稼働するバージョンを確認

更新後｜表示・機能・ログ

1. ⑧ 表示・認証・フォーム・重要業務を確認

2. ⑨ エラー・キャッシュ・遅延処理を確認

3. ⑩ 根拠と残課題を記録し完了判断

未確認／問題あり

※③④⑦⑧⑨などで分岐

1. 作業を中断・記録

2. 権限ある担当者へ連絡

3. 原因と影響を確認

4. 戻す時点・データ損失

   復元／再試行の要否を担当者が判断

注意：PHP→WordPressなど、一律の更新順序を指示する図ではありません。

複製環境の起動前には、通知・決済等の外部作用も確認します。

図D06｜更新の準備・適用・確認と、失敗したときの判断の流れ。

参考資料：WordPress公式：更新手順／WordPress公式：バックアップ／WordPress公式：WordPressの更新

更新後の表示・フォーム・ログイン・更新失敗確認

「更新が完了しました」という表示と「サイトが正常に使える」は別の判定です。 更新直後は、担当者が何を更新したか、何に変わったか、重要な処理が使えるかをセットで確認します。WordPress公式の更新画面には本体・拡張機能などの更新状態が表示されますが、それだけでサイト固有の予約や決済機能まで検証されたわけではありません。出典：WordPress更新画面・本体更新の最終確認

また、修正内容によっては、プログラムの更新に加えて保存済みデータの点検が必要です。第8章で扱ったWordPress 7.1.3のImgur埋め込みでは、以前に保存したoEmbedの内容が更新後にも表示され得ます。開発元や調査主体が示す追加確認を個別に読み、ブラウザやCDNのキャッシュ更新だけで対処が終わったとは判断しません。出典：Patchstack：7.1.3のコードレビュー

更新直後に問題がなくても、時間差で処理される予約通知、定期実行、キャッシュ更新、外部連携で異常が現れる場合があります。 あらかじめ決めた一定時間後や次の実運用タイミングにも再確認し、日時、対象、更新前後の版、担当者、確認項目と結果、発生した問題と対処を残します。

更新途中で失敗した、管理画面に入れない、主要機能が止まった、継続してエラーが出る場合は、操作を連打したり、確認しないままの上書き・復元を始めたりしません。エラー表示と開始時刻、直前の更新対象を控え、担当者に連絡して影響範囲と復旧手段を確認します。古い版への安易な切り戻しは、修正済みの脆弱性を再び持ち込んだり、更新後のデータベース構造と合わなくなったりする危険があります。出典：WordPressの更新失敗と切り戻しへの注意

表T10｜WordPress・PHP更新前後の確認表

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

この表は、更新工程で実施した結果を誰が残し、何をもって完了とするかを示したものです。第9章と同じく、確認状態は「確認済み／未確認／対象外」、対応状態は「対応不要／要対応／対応中／完了」で記録します。更新処理の成功・失敗という実行結果も別に残し、処理が成功しただけで機能の確認や残課題まで「完了」にしません。担当名は一般例であり、実際には保守契約と権限に合わせて割り当てます。表にある項目を、検証していないのに「完了」と記載してはいけません。

バックアップに必要なファイルとデータベース

画像を拡大する ＋

WordPressの復旧には、通常、ファイルとデータベースの両方が必要です。 ファイルにはWordPress本体、テーマ、プラグイン、アップロードされた画像やPDFなどの添付ファイル、独自プログラム、設定ファイルがあります。データベースには記事・固定ページ・コメント・利用者に関する情報、サイト設定、プラグインが保存したデータなどが含まれます。画像ファイルだけが戻っても本文や画像との対応が失われることがあり、データベースだけが戻ってもテーマ・添付ファイル・独自機能が欠ける場合があります。出典：WordPressのバックアップ説明・ファイルのバックアップ・DBのバックアップ

サーバー会社の自動バックアップと、WordPress側のプラグインによるバックアップは同じものとは限りません。 対象範囲、世代（過去のどの時点まで残すか）、保存期間、契約終了時の扱い、復元時の料金・操作権限、別の場所への持ち出し可否を確認します。保存先を同一サーバー上だけにすると、サーバー全体の障害や誤削除時に同時に失う可能性があります。事業が許容できるデータ損失と停止時間に合わせて、異なる保管場所と複数世代を検討します。バックアップには個人情報・設定情報・秘密情報が含まれ得るため、必要な人以外が読めないアクセス権、転送・保存時の保護、不要になった世代の適切な削除も必要です。出典：WordPressバックアップの保管上の説明

「バックアップ完了」と記録する前に、対象の一覧、実ファイルの存在とサイズ、取得結果のエラー、読出し可能性、取得時刻を確かめます。 ファイルのハッシュ値（内容から計算した照合用の値）が利用できる仕組みなら、転送時の一致確認にも役立ちます。ただし、容量やハッシュの一致はそれだけでデータベースが正しく復元できることを証明しません。復元テストで初めて確かめられる事項が残ります。

復元テストと復旧時に気を付けること

バックアップが存在すること、内容を読み出せること、サイトとして復元できることは三つの異なる段階です。 復元テストは、実際の障害が起きる前に、必要なファイルとデータベースを指定した時点の状態へ戻せるか、担当者が手順を実行できるか、復元後に重要機能が使えるかを確かめる作業です。原則として本番から隔離したテスト環境で行い、本番データを上書きしません。復元先の複製・起動前にも、前述のステージングと同じく、実顧客への送信・請求や本番サービスへの書き込みが起きないことを確認します。出典：WordPressのDB復元方法と上書きの注意・バックアップの考え方

復元担当者は、戻すサイト、バックアップの取得日時、ファイルとDBの対応、復元先、接続情報・権限、必要な外部サービスを照合します。例えばデータベースは復元したのに、対応する画像・プラグインが別の時点のままでは、サイトが開いても記事内の画像、フォームの設定、会員処理などが正しく動かない場合があります。復元後はトップページだけでなく、更新前確認と同じ主要ページ・ログイン・フォーム・業務機能を点検します。サーバー設定やドメインなどに差がある場合は、単純なファイルコピーで完了とはしません。出典：ファイル・DBをセットで扱う公式説明・WordPressの移行時の注意点

復元時点より後の投稿・注文・予約・会員登録が失われる可能性があります。 例えばバックアップ取得後に新たな予約を受け付けていたなら、古いデータベースへ戻すことでその記録が消えるかもしれません。復元可能な時点（どれだけのデータを失うおそれがあるか）と、復旧に必要な時間（いつ業務を再開できるか）を、運営責任者と技術担当者が事前に見積もります。必要に応じて更新直前の差分をどう扱うかも判断します。WordPress公式は、バックアップからDBを復元すると現在のDB内容が保存時点のものに置き換わることを注意しています。出典：WordPress DB復元の公式説明

バックアップの一部が破損している、設定ファイルが欠けている、必要なDBへ接続できない、復元先のPHPやDBとの互換性がない場合は、作業を成功扱いにしません。残っている別世代や提供元バックアップ、構成記録を探し、必要なら専門担当者と復旧可能範囲を調整します。復元のための権限や秘密情報が手元にない場合も、承認のない操作で代用しないでください。

特に、侵害されていた時期のバックアップから復元しても、侵害原因や不正な変更が残るおそれがあります。 「正常に表示できた」「復元処理が完了した」ことは、悪意あるファイルや不正アカウントが除去された証拠ではありません。すでに改ざんや不正アクセスを疑う兆候がある場合は、通常の更新や復元を先に進めず、第12章「改ざんや侵害が疑われるときの初動と復旧」の方針に従って、証拠保全と専門的な判断を優先します。出典：WordPress公式の侵害時案内

重大な脆弱性が公表された際の優先対応

重大な脆弱性が公表されたときは、定例の保守予定を待つかどうかを、対象への該当と実際の悪用状況から優先的に判断します。 重大度の数字だけでも、製品名が一致しただけでも、自社への影響は確定できません。まずPHP・WordPress・テーマ・プラグインのどれの問題かを分け、開発元・配布元の正式な告知を読み、影響バージョン、必要な設定・権限・公開機能、当該環境に適用済みの修正、悪用の証拠を確認します。出典：PHP公式のセキュリティ更新情報・WordPressのセキュリティ告知・WordPress公式のサポート方針

対応はおおむね次の判断順です。

1. 正式情報と該当範囲を確認する。 開発元のリリース情報、OS・ホスティングのセキュリティアドバイザリ、必要に応じて公的機関の注意喚起を照合します。攻撃手法が実証されたこと、攻撃試行が観測されたこと、実際の侵害が確認されたことを混同しません。
2. 担当者と契約範囲を確認する。 サイト運営責任者、WordPress保守担当、PHPを管理するサーバー担当に連絡し、契約上の緊急対応の対象・受付時間・承認者を確かめます。更新権限がなければ提供元へ適用状況を問い合わせます。
3. 修正版がある場合は、適用経路を優先して計画する。 影響を受けると分かった製品の正規修正版または配布元パッチを確認し、バックアップ・重要機能の最低限の互換性試験・監視方法を用意して速やかに適用します。緊急性によって試験の範囲や実施順序は調整しますが、無条件のテスト省略や、根拠のない変更は勧めません。
4. 修正版がまだない／更新できない場合は、暫定策の根拠を確認する。 開発元が特定の設定変更や機能停止を案内しているか、対象経路をアクセス制限やWAFで抑えられるかを技術担当者が評価します。WAFは通信を検査する防御機構ですが、あらゆる攻撃を防ぐ修正パッチの代用品ではありません。機能停止には業務影響があり、アクセス制限は正規利用者にも影響します。対策ごとに有効な成立条件と副作用を確認し、暫定対応として記録します。
5. 完了を検証する。 適用対象と実際の稼働版・パッケージ改訂番号、主要機能、失敗通知・ログ、一定時間後の稼働を確認します。未対応が残る場合は、業務を続けるか停止するかを権限のある責任者へエスカレーションします。

2026年10月23日のPHPのセッションアップロード進捗に関する告知では、特定の条件に限る問題について、通常リリースまでの暫定設定変更が示されました。こうした緩和策は、対象機能を使うアプリケーションへの影響も確認して判断すべきものです。この設定変更を、10月21日の別の2件のPHP脆弱性への完全な修正として扱うことはできません。出典：PHP公式の2026年10月告知・PHPの個別脆弱性説明

最後に、修正版の適用は「その欠陥を修正する作業」であり、「以前から侵害されていなかったことの証明」ではありません。 更新後に見覚えのない管理者、不正なページ、意図しない転送などが見つかった場合は、更新成功として閉じず、第12章の侵害時対応に判断を切り替えます。通常の保守記録に残すのは、何に該当し、どの修正をいつ適用し、何を検証し、何が未確認かです。出典：WordPress公式の侵害時案内・WordPressセキュリティ指針

関連する説明：防御策の組み合わせ／侵害した状態からの復旧／継続点検
この章の目次へ・全体の目次へ

第11章

セキュリティ対策は何を防ぎ、何を防げないのか

WordPressのセキュリティ対策は、一つ導入すればサイト全体が安全になるものではありません。 多要素認証は主にログイン時の本人確認を補強し、WAFは条件に合う不審なWeb通信を検査・制限し、HTTPSは通信経路を保護します。それぞれ守る対象が違うため、ある対策が正常に動いていても、別の場所にある弱点は残り得ます。

この章でわかること

• 多要素認証・パスワード・管理者権限の管理
• WAFの効果と限界
• Basic認証・IP制限・管理画面URL変更
• CAPTCHAとログイン試行制限
• HTTPS/TLS・Cookie等の通信面での保護
• ファイル権限・設定ファイル・公開範囲
• ログ監視・改ざん検知・脆弱性情報の把握
• サーバー事業者とサイト管理者の責任分担
• 多層防御を組み合わせる理由

たとえば、管理者のログインに多要素認証を設定していても、ログイン不要で悪用できるプラグインの脆弱性まで塞がるわけではありません。WAFが危険な通信を遮断できても、その脆弱性の修正が不要になるわけではなく、HTTPSの証明書が正常でも、公開しているページが改ざんされていないとは限りません。対策の効果を判断するときは、「何を対象に」「どの通信・操作に適用され」「誰が管理し」「何が未対応のままか」を分けて考えます。出典：WordPress公式セキュリティ指針・OWASPの認証対策・OWASPの仮想パッチ解説・TLS仕様

多要素認証・パスワード・管理者権限の管理

多要素認証は、パスワードだけで成立する不正ログインを減らすための対策です。ただし、ログインに成功した人が何をできるかは、別の「権限管理」で決まります。 本人であることを確かめる処理を「認証」、その人に許される操作を判断する処理を「認可」と呼びます。認証を強化しても、不必要に広い権限まで自動的に減るわけではありません。出典：OWASP：認証・OWASP：認可

パスワードの基本は、推測されにくく、サービスごとに異なるものを使うことです。短く単純な文字列や会社名から推測できるものは、総当たりや辞書を使った試行の対象になり得ます。別サービスから漏れたID・パスワードの組み合わせをWordPressにも試す「クレデンシャルスタッフィング（認証情報の使い回しを狙う攻撃）」では、WordPress自体からパスワードが流出していなくても被害につながる場合があります。パスワードマネージャーは、複雑で重複しない認証情報の生成・保管を助けます。ただし、マネージャー自体へのアクセスや端末も適切に保護する必要があります。出典：OWASP：認証・OWASP：流出認証情報への対策

多要素認証（MFA）は、知っている情報（パスワードなど）、持っているもの（認証端末・セキュリティキーなど）、本人の特徴といった、異なる要素を組み合わせて確認する仕組みです。「パスワードと確認コード」のように二つの要素を要求する方式だけでなく、実装によってはパスワードを使わない方式もあります。これにより、攻撃者がパスワードを一つ入手しただけではログインを成立させにくくなります。出典：WordPress公式：二段階認証・OWASP：MFA

ただし、MFAならどの方式でもフィッシングに強い、という理解は誤りです。 認証アプリが表示するワンタイムコード（TOTP）は、使い捨ての番号を追加する効果がありますが、利用者が偽サイトにその番号を入力してしまえば、攻撃者が即時に悪用できる場合があります。SMSなどで届くコードも、通信経路や端末・アカウントの乗っ取りなどを考慮しなければなりません。一方、FIDO2などに基づく適切なセキュリティキーやパスキーは、正規サイトの識別情報（オリジン等）と結び付いた認証により、一般的なコード入力方式よりフィッシングに強い仕組みを構成できます。ただし、サービス側の実装、登録方式、代替ログイン手段によって実際の保護範囲は変わります。出典：OWASP：MFAの方式と限界

MFAで守るのは、原則としてそのMFAが確認を行うログイン経路です。PHPやWordPressの未修正の脆弱性、認証を経ないAPIや公開機能、権限確認の実装不備、すでに乗っ取られたログインセッションによる操作までは防ぎません。セッションは、複数のリクエストを同じ利用者の状態に結び付ける仕組みです。ログイン前の状態管理にも使われますが、ここでは認証後のログイン状態を扱います。攻撃者に有効なセッション情報が渡った場合、改めてパスワードやMFAを尋ねる場面を通らずに操作が成立することがあります。認証後の重要操作で再確認を行うか、異常なセッションを失効できるかなども、実装と運用に左右されます。出典：OWASP：MFA・セッション管理

WordPressの権限は、通常の単一サイトなら「管理者（Administrator）」が設定や利用者管理など広範な操作を担当し、「編集者（Editor）」は主に記事・ページなどコンテンツの編集を担います。さらに投稿者・寄稿者など、役割に応じた区分があります。マルチサイトでは特権の分担が異なり、プラグインによって独自の権限も追加され得ます。記事を直すだけの担当者へ、利用者や設定を管理し、テーマ・プラグインを変更できる権限まで渡す必要があるかを判断するのが「最小権限」です。管理者の人数を減らすことだけが目的ではなく、各担当者に必要な操作を過不足なく割り当てます。出典：WordPress公式：ロールと権限・OWASP：認可

WordPress内の管理権限は、サーバーの契約者画面やOSの管理権限と同じではありません。ただし、テーマ・プラグインのコードを変更できる構成では、そのコードがPHPの実行主体に許された範囲でファイルやデータへ影響を与えることがあります。管理画面の操作権限と、実際のプログラムが動く権限の両方を確認します。出典：WordPress公式：ロールと権限・OWASP：認可・WordPress公式：ファイル権限

WordPress公式は二段階認証を解説していますが、一般的なWordPressの標準設置について「すべてのユーザーが最初からMFA必須」とは説明していません。プラグインや外部の認証サービスなど、採用した方式が、対象ユーザーとログイン経路に確実に適用されているかを確認する必要があります。また、WordPressには外部アプリ等で利用するアプリケーションパスワードという別の認証手段があります。これは通常のブラウザログイン用パスワードとは用途が異なるものの、許可されたAPI経由の操作権限につながるため、作成・利用・失効の管理が必要です。出典：WordPress公式：二段階認証・アプリケーションパスワード

対象はWordPressだけではありません。レンタルサーバーの契約者画面、ドメイン登録事業者、DNS、バックアップ保存先、保守会社の共有サービスなどが別々の認証を用いる場合があります。WordPressの管理画面だけを強化しても、別経路からサイトの公開先やファイルを変更できる権限が残っていれば、その経路のリスクは消えません。さらに、MFAを使う人が認証端末を紛失する場合に備え、復旧コードを安全に保管し、再登録を誰が承認するかも決める必要があります。復旧手段が弱すぎれば抜け道になり、厳しすぎれば正当な管理者が入れなくなるためです。出典：OWASP：MFAの復旧と再登録・WordPress公式セキュリティ指針

WAFの効果と限界

WAF（Web Application Firewall）は、Webアプリケーションに届くHTTP通信を調べ、ルールなどに合う要求を記録・制限・遮断するための防御策です。 一般的なネットワークファイアウォールが主として通信先のポートやネットワーク接続を制御するのに対し、WAFはWeb要求のURL、ヘッダー、パラメーター、本文など、アプリケーションに関係する情報を検査する方式があります。検査できる項目や通信サイズ、レスポンスを対象にするかどうかは製品や構成次第です。出典：OWASP：WAFを含むアプリケーション構成・OWASP：仮想パッチ

たとえば、SQLインジェクション（データベースへの不正な問い合わせに関係する攻撃）やXSS（閲覧者のブラウザで意図しないスクリプトを動かす攻撃）に似た入力を、既知のパターンや複数の検査ルールで判定するWAFがあります。攻撃に用いられる表現を検知し、危険と判定したリクエストをアプリケーションまで届かせないことが、主な役割です。しかし、SQLiやXSSという種類に分類される攻撃を、すべて一律に止められるわけではありません。 同じ攻撃でも表現や処理経路が違えば検知できない可能性があり、認可の欠落や業務機能の使い方を悪用する問題は、一般的なパターン検査だけでは判断しにくい場合があります。出典：OWASP：WAFの防御範囲・OWASP：仮想パッチ

WAFを「有効」にしているというだけでは、どの要求が検査されるかは確定しません。主な提供方式には、次の違いがあります。

• ホスティング事業者のWAF：事業者のWebサーバーやその前段などに実装される場合があります。契約したサイト・ドメイン・機能にどこまで適用されるかは、そのサービスの仕様によります。
• CDN・クラウド型WAF：閲覧者と元のサーバー（オリジン）の間にある中継サービスがWeb要求を受け、条件に応じてオリジンへ転送します。中継を通るホスト名・経路だけが検査対象となる構成があり、DNS設定や別の入口から直接オリジンへ届く通信には、同じ防御が及ばない場合があります。
• WordPress内で動くセキュリティ機能：プラグイン等が処理の途中で要求を検査する方式があります。WordPressやPHPが動作する前の段階から通信を遮断するWAFと、すべて同じ位置・保護範囲ではありません。WordPressが起動しない通信や、処理のより早い段階で成立する問題に対しては効果が異なり得ます。

これらは設置位置と処理順序の違いであり、「クラウド型だから必ず上位」「プラグイン型だからすべて無意味」と決められるものではありません。複数の構成を併用することもあります。重要なのは、実際の公開経路に検査が入ること、必要な通信を判別できること、ルールが有効であることです。Cloudflareの公式資料でも、プロキシを通すDNSレコードとDNS情報のみを返すレコードでは、経由する通信が異なると説明されています。これは製品固有の例であり、あらゆるWAFの設定方法を示すものではありません。出典：Cloudflare公式：プロキシの適用範囲・OWASP：WAFの配置

修正プログラムの準備や適用に時間が必要なとき、特定の脆弱性を狙う要求に合わせてWAFルールを作り、悪用を抑えることがあります。これを仮想パッチ（Virtual Patching）と呼びます。適用条件が合えば有効な緩和策ですが、これはサーバーに残った脆弱性を修正するものではありません。該当する要求がWAFを通過し、ルールがその攻撃方法を検知できることが必要です。迂回経路、未対応の攻撃の形、対象外のAPIなどがあれば保護できず、開発元の修正版適用に置き換えることはできません。出典：OWASP：仮想パッチ・WordPress公式セキュリティ指針

さらに、ルールが過敏なら、正当な投稿の本文に含まれるHTMLや記号、問い合わせフォームの内容、ファイルアップロード、管理画面・REST APIへの操作まで攻撃と誤判定してしまうことがあります。これが誤検知（False Positive）です。逆に、本来止めたい通信を見逃すこともあります。OWASP Core Rule SetはWordPressで正常な投稿がXSS関連ルールに反応する例を示し、必要に応じた細かな除外調整を説明しています。誤検知を理由に広い範囲の検査を一括で無効化すると、別の攻撃も通しやすくなるため、対象の機能・ルール・通信を絞った判断が必要です。出典：OWASP CRS：誤検知の調整・Cloudflare：管理ルールのトラブルシューティング

実務では、WAFの提供元と適用対象、検査するホスト名・経路、ルール更新の管理者、遮断か監視のみか、例外設定、ログの見方、正常機能が止まった際の連絡先を確認します。「検知ログに記録された」「通信を遮断した」「脆弱性を修正した」は、それぞれ別の状態です。設定変更や検査を実施しなくても、契約内容や保守担当者への確認を通じて、これらを説明できる状態を目指します。出典：Cloudflare：WAFの確認事項・OWASP：仮想パッチ

Basic認証・IP制限・管理画面URL変更

Basic認証、IP制限、管理画面URLの変更は、いずれも「入り口」を狭める目的で使われますが、同じ対策ではありません。 Basic認証はアクセス時に追加のID・パスワードを要求し、IP制限は接続元のネットワークアドレスを条件に許可・拒否を決めます。管理画面URLの変更は、既定の場所を知らない自動アクセスを減らすことはあっても、独立した本人確認を増やすものではありません。出典：Apache：認証とアクセス制御・nginx：接続元IPの制御・WordPress公式：隠すだけの対策の限界

導入時は、管理者本人・外部保守会社・必要な自動処理がアクセスできるかも重要です。Basic認証やIP制限を広く掛けすぎると、サイトの更新処理、正規のAPI連携、編集画面、フォームや公開動作に影響する構成があります。URL変更で既存のブックマーク・連携・案内が使えなくなる場合もあります。正しい管理者が締め出されたときの復旧権限を誰が持つかを確認せずに導入すると、問題発生時に復旧しにくくなります。設定方法や適用範囲はApache、nginx、レンタルサーバー、CDNで異なるため、提供元の正式仕様に合わせて判断します。出典：Apache公式：認証・nginx公式：アクセス制御

CAPTCHAとログイン試行制限

CAPTCHAとログイン試行制限は、自動化された大量の操作を難しくするための対策であり、ログイン認証そのものの代わりではありません。 自動プログラムが短時間で大量のパスワードを試す行為や、フォームへ繰り返し投稿する行為などに対して、試行の手間を増やし、速度を落とすことを狙います。防御対象を「ログイン試行」「フォーム送信」「アカウント作成」などに分けなければ、効果の範囲はわかりません。出典：OWASP：ボット管理・OWASP：認証情報の使い回し攻撃

CAPTCHAは、画像や音声による確認、端末・操作の特徴、リスク評価など、方式に応じて人間の操作と自動的な処理を区別しようとする仕組みです。ただし、認識技術の進歩、人手を介した突破、別の入口からの操作などにより回避される場合があります。CAPTCHAが表示されたことは、利用者の本人確認が済んだ証明ではありません。また、画像が読みにくい人、音声を聞き取りにくい人、操作に時間が掛かる人など、正当な利用者のアクセシビリティと利用体験にも影響し得ます。外部サービス型なら、利用規約・データ送信・プライバシー面の確認も必要です。出典：OWASP：ボット管理とCAPTCHA

ログイン試行制限やレート制限は、一定の期間内に許可する要求数や失敗回数などを絞る仕組みです。接続元IPごとの制限は同じIPからの連続試行を抑えますが、IPを分散して行う攻撃では効果が弱まる場合があります。一方、利用者アカウントごとの制限は一つのIDへの反復試行に有効でも、攻撃者が複数のIDを使ったり、第三者のアカウントを意図的にロックさせたりする可能性があります。端末や経路など複数の要素を組み合わせる方式もありますが、利用できる情報や精度は製品依存です。出典：OWASP：認証情報の使い回し攻撃・OWASP：ボット管理

試行制限を厳しくすると、入力間違いをした社員や、共通のネットワークを使う正当な利用者までログインできなくなる場合があります。予約の確認や記事の更新など、業務を止める副作用を考慮する必要があります。何回失敗したら何分停止する、といった数値は全サイト共通の正解ではありません。 利用者数、重要な業務、異常時の通知先、MFAの有無、アカウント回復方法に応じて調整し、ロックした後に誰が解除できるかを決めます。なお、ログイン画面で制限できても、公開API・フォーム・未修正のプログラムの弱点には別の防御が必要です。出典：OWASP：認証・OWASP：ボット管理・WordPress公式：二段階認証

HTTPS/TLS・Cookie等の通信面での保護

HTTPSは、ブラウザと接続先との通信を保護する仕組みです。接続先のWebサイトが侵害されていないことや、WordPressに脆弱性がないことを証明するものではありません。 HTTPにTLS（Transport Layer Security）を組み合わせたHTTPSは、通信途中で内容を盗み見られたり、改ざんされたりするリスクを減らします。TLSでは、通信の暗号化、改ざん検出、証明書等を用いた接続先の確認が重要な役割を担います。出典：TLS 1.3仕様：RFC 9846・OWASP：TLS

証明書の検証に成功し、URLやブラウザの表示がHTTPSになっていても、そのサーバーが返すページ自体の内容が正当とは限りません。正規の証明書を持つサイトでも、管理権限を奪われ、ページを書き換えられた状態は起こり得ます。 HTTPSはSQLインジェクション、XSS、PHP実行環境の欠陥を修正しません。途中にCDNやリバースプロキシがある場合は、ブラウザと中継先の間だけでなく、中継先と元のサーバー間の保護がどうなっているかも構成ごとに確認します。出典：OWASP：TLS・WordPress公式セキュリティ指針

ログイン後の状態には、ブラウザが保存するCookieが関係します。Cookieは、サーバーの応答などによりブラウザに保持され、指定された送信条件に合う通信で送り返される情報です。WordPressはログインした利用者の識別に認証用Cookieを使います。Cookie自体にはパスワードの全文が入っていなくても、正規のセッションに結び付く値が盗まれたり不正利用されたりすると、ログイン状態の悪用につながる場合があります。WordPress本体の認証Cookie処理と、プラグイン・外部連携が独自に扱うCookieは、必ずしも同じ設定ではありません。出典：WordPress公式：認証Cookieの実装・OWASP：セッション管理

Cookieの代表的な属性には、次のような役割があります。

• Secure：原則としてHTTPS接続でのみCookieを送らせるための属性です。平文HTTPの通信へ重要なCookieが送信されるリスクを減らしますが、サーバーの脆弱性や端末上の窃取まで防ぎません。
• HttpOnly：ブラウザ上のJavaScriptなどから、対象Cookieの値を直接読み取ることを制限します。XSSでCookie値を盗まれる一部の経路を抑えますが、XSSそのものを除去したり、侵害されたページのJavaScriptによる不正操作をすべて防いだりはしません。
• SameSite：他サイトを起点とする要求にCookieを付ける場面を制御し、CSRF（利用者の意図と異なる操作を行わせる攻撃）への補助的な対策となります。Strict、Lax、Noneなどの指定とブラウザの挙動によって、適用範囲は変わります。Noneでは安全な設定としてSecureとの組み合わせが要求される実装があります。属性だけでCSRF対策や権限確認が完成するわけではありません。

これらは別々のリスクに対応します。フォーム、外部ログイン、埋め込みコンテンツ、別ドメイン間の連携などでは、Cookieの送信条件を変えると動作しなくなる場合があります。安全そうな属性を機械的に追加するのではなく、ログイン機能と連携方式を確認し、提供元が推奨する設定と実際の動作を整合させます。 各属性の効果と限界はOWASPのセッション管理資料、WordPress本体の認証Cookieの処理は公式の実装資料で確認できます。ただし、どの属性が全Cookieに設定済みかは、実際の構成を別途見なければ確定できません。出典：OWASP：セッション管理・WordPress公式：認証Cookie

ファイル権限・設定ファイル・公開範囲

ファイル権限は、サーバー上の誰がファイルを読み、書き換え、実行できるかを制限するための仕組みです。 WordPress本体、テーマ、プラグイン、画像などのアップロードファイル、設定ファイルは、サーバー上でそれぞれ扱われます。権限が広すぎると、正当な用途では不要な書き換えや情報の閲覧まで許してしまう場合があります。一方で、制限を厳しくしすぎると、WordPressやPHPが必要な処理を行えず、更新やアップロードに失敗することがあります。出典：WordPress公式：ファイル権限の変更・WordPress公式：Hardening

一般的なUnix系サーバーでは、ファイルやディレクトリに所有者・グループ・その他の利用者ごとの権限が設定され、読み取り・書き込み・実行などの許可が関係します。ディレクトリの「実行」は、プログラムファイルを動かす意味とは異なり、その階層をたどれるかにも関わります。PHPを実行するOSユーザーと、ファイルをアップロードするユーザー、保守作業のユーザーが同じとは限りません。PHP-FPMの構成などによって、実際にどの権限でWordPressの処理が動くかは異なります。出典：WordPress公式：ファイル権限・PHP-FPM公式説明

ファイルの「実行」権限と、Web経由でPHPとして処理されることも別です。 一般的なWebサーバーとPHPの構成では、PHP処理系が読み取ったスクリプトを実行するため、PHPファイル自体の実行ビットを外すだけでは、WebからのPHP処理を禁止できません。プログラムの実行を制限するときは、ファイルの置き場所、WebサーバーがそのファイルをPHPへ渡す設定、PHP実行主体の読み書き権限を合わせて確認します。具体的な設定は提供元と保守担当者に確認してください。出典：WordPress公式：ファイル権限・PHP-FPM公式説明

必要な考え方は、公開すべきファイルと、Web経由で直接読ませる必要のないファイルを分けることです。WordPressのwp-config.phpなどにはデータベース接続に使う設定情報が含まれます。これを誰でも読める場所に公開したり、不必要なユーザーへ閲覧権限を与えたりしないよう管理します。バックアップの圧縮ファイル、設定の控え、開発時の一時ファイルを公開領域に残すことも、意図しない情報公開につながり得ます。また、Webサーバー側の設定次第では、ディレクトリの一覧が表示されることがあります。サーバーにファイルが置かれていることと、Webから直接取得できることは同義ではありませんが、公開範囲とアクセス制御を確認する必要があります。出典：WordPress公式：Hardeningと設定ファイル保護・WordPress公式：ファイル権限

テーマ・プラグイン・WordPress本体のファイルには、通常の更新で書き換える必要があるものがあります。一方、アップロード用ディレクトリには画像や文書などが保存されますが、利用者がアップロードしたプログラムを意図せずサーバー上で実行できる状態にしないという点も重要です。どの拡張子を許可し、どこへ保存し、Webサーバーがどう処理するかを含めて判断します。ファイル権限だけでは、アップロード機能のプログラム上の検証不備を修正できません。出典：WordPress公式：Hardening・WordPress公式：ファイル権限

WordPress公式は権限設定の例を示していますが、すべてのサイトで同じ数値・所有者にすれば安全になる、という意味ではありません。 共用レンタルサーバー、VPS、コンテナ、管理型サービスではOSユーザー、ファイル所有者、更新方式、FTP等の連携が異なります。また、PHPの実行プロセスや管理者アカウントを侵害され、その主体が書き込みを許可されている場合は、ファイル権限の設定が正しくても許可された範囲で不正な変更が起こり得ます。したがって、最小限の権限に加え、認証、ソフトウェア更新、公開範囲、変更監視を別々に考える必要があります。出典：WordPress公式：ファイル権限・WordPress公式：Hardening

ログ監視・改ざん検知・脆弱性情報の把握

ログや改ざん検知は、何が起こった可能性があるかを調べる手掛かりです。存在するだけで攻撃を防止したり、異常が見つからないからといって安全を保証したりするものではありません。 検知した事象と、侵害が実際に成功したかどうかは分けて判断します。出典：OWASP：ログの設計と限界・WordPress公式：ログ・ファイルの監視

また、サイトへ接続できるか、応答が遅くなっていないかを確かめる稼働・性能監視は、セキュリティ上の不正な変更を調べる監視と目的が異なります。両方を組み合わせる場合も、検知対象と通知を受ける担当者を区別します。出典：WordPress公式：稼働・性能のモニタリング

同じWebサイトでも、記録される内容は一種類ではありません。

• アクセスログ：Webサーバー等に届いたリクエスト、時刻、接続元として認識した情報、応答状況などを、環境に応じて記録します。不審なアクセスや増加傾向を調べる材料になります。ただし、ログ上の接続元や応答コードだけで攻撃成功は判断できません。
• エラーログ：PHPやWebサーバーが検知した実行エラーなどを記録する場合があります。原因究明の助けとなりますが、攻撃が成功してもエラーが出るとは限らず、ログ出力の設定・保存先も環境次第です。
• WordPressの操作・監査ログ：プラグインや外部監視サービスなどを追加して、ログイン失敗、ユーザー・権限の変更、設定や記事の更新を記録できる構成があります。すべてのWordPressサイトで、その詳細な監査ログが標準で保存されるとは限りません。 誰の操作がどの範囲で記録されるかは導入機能によります。
• WAFの検知記録：どのルールに反応し、観測・制限・遮断のどの動作をしたかを確かめる手掛かりです。ただし「攻撃らしい通信を検知」したことは「サイト内部で不正な処理が実行された」証拠とは別です。

出典：OWASP：Logging・PHP公式：エラーログ設定・WordPress公式：Hardening・Cloudflare：WAFのログと誤検知

改ざん検知は、ファイルのハッシュ値や内容、更新時刻などを基準となる状態と比較し、予期しない変更を発見するために使われます。正規のWordPress更新、テーマのアップデート、管理担当者による修正でもファイルは変わるため、変更があっただけで不正とは断定できません。一方、監視対象から外れているファイルや、検知機能自体が侵害された場合には発見できないことがあります。改ざんを検知しても、その時点だけで侵入経路や原因を確定できるわけではありません。出典：WordPress公式：Hardeningの監視・整合性確認・OWASP：ログと監視

また、記録していること、誰かが確認していること、異常時に通知されること、担当者が対応できることは、それぞれ別の段階です。ログの保存期間が短ければ以前の状況をたどれず、ログのあるサーバーそのものが侵害された場合は記録の信頼性にも注意が必要です。ログに誰がアクセスできるか、外部保存があるか、時刻の整合が取れているかなどが、後で状況を把握できるかに影響します。アクセスログにはIPアドレス等、監査ログには利用者の情報が含まれる場合があり、認証情報や個人情報を不必要に収集・公開しない配慮も欠かせません。出典：OWASP：Logging

脆弱性情報も同様に、情報を見たことと、自社の修正適用が済んだことは別です。CVEは公開された脆弱性を識別するための番号であり、単独では自社サイトが影響を受けるという判定にはなりません。WordPress本体、使用中のテーマ・プラグイン、PHP、サーバーソフトウェアについて、開発元・配布元の注意喚起、影響する版と条件、修正版・緩和策を対応させて読む必要があります。特に独自プラグインや外部配布の製品では、更新通知の仕組みが異なる場合があります。脆弱性速報を監視していても、適用対象や担当者が不明なら対処は進みません。出典：WordPress公式：Hardening・WordPress公式：更新管理・PHP公式：セキュリティ修正の適用

ログに異常がなくても、攻撃が発生していないことの証明にはなりません。異常の見つけ方と、実際にサイトが侵害された場合の調査・復旧は別の作業です。改ざん、未知の管理者、勝手な転送などが疑われる場合の具体的な初動は、第12章の被害拡大防止と証拠保全で扱います。

サーバー事業者とサイト管理者の責任分担

サーバー会社がセキュリティ機能を提供していても、自社のWordPressサイトのすべてが自動的に保護・更新・監視されるとは限りません。 サーバー会社、Web制作・保守会社、サイトを所有・運用する自社の役割は、契約内容とシステムの構成で変わります。まず「誰が操作できるか」と「誰が実施する契約か」と「誰が完了を確認するか」を分ける必要があります。出典：WordPress公式：責任範囲とHardening・WordPress公式：PHP更新とホスティング

共用レンタルサーバーでは、OSや共通のWebサーバーなどを事業者が管理し、契約者が選択可能なPHP版やWAF設定、サイトのWordPressや拡張機能を別々に管理する形が見られます。ただし、PHP版を誰が切り替えるか、WAFが自動で有効か、バックアップが取得だけか復元も対象かは各契約によります。VPSや自社管理サーバーでは、OS・Webサーバー・PHPの更新まで自社または委託先が引き受ける場合が増えます。一方、WordPress向け管理サービスでは、WordPress本体の更新やバックアップ、監視を事業者が代行するプランもありますが、プラグイン・独自コード・テーマ・ドメインまで含むとは限りません。サーバーの種類だけで担当を決めつけないことが重要です。出典：WordPress公式：Hardening・WordPress公式：PHP更新

Web制作会社がサイトを制作していても、納品後の継続的な更新・監視・緊急対応が契約に含まれるとは限りません。「保守契約あり」という表現だけでも、作業内容や対応時間は判断できません。また、ドメイン・DNSの契約を自社が持ち、Webサーバーは別会社、サイトの更新は制作会社という分担もあり得ます。この場合、WordPress管理者、サーバー管理者、ドメイン契約者は別の権限を持ち、それぞれができる操作と責任が違います。出典：WordPress公式：Hardening・WordPress公式：ロールと権限

表T12｜サーバー会社・制作会社・自社のセキュリティ管理分担

以下は契約確認のための一般的な役割整理です。「担当になり得ること」を示しており、どの会社にも共通する法的・契約上の義務を断定するものではありません。

表の区分は固定的な責任分担ではありません。「機能を提供している」と「その機能を自社サイト向けに有効化し、設定・運用している」は別です。たとえば、サーバー会社のWAFが用意されていても、サイトごとの切り替えが必要な場合があります。バックアップの自動取得サービスがあっても、どのデータを何世代保存し、誰が復元できるかまで契約に含まれるとは限りません。出典：WordPress公式：Hardening・WordPress公式：バックアップ

契約先へ確認するときは「セキュリティ対策はありますか」だけで終えず、対象ドメイン、対象製品、利用中の契約名、作業内容、実施担当者、検証担当者、緊急連絡手段を示して質問すると判断しやすくなります。特に、PHPの修正を誰が配布・適用するか、WordPressと拡張機能の保守範囲、WAFの適用経路、バックアップと復元の責任、ログ保管先、ドメイン・DNS・証明書の管理者、休日や夜間の対応範囲を明確にしておきます。これは本章での管理上の推奨であり、特定のサーバー会社が一律に提供する機能を表したものではありません。

多層防御を組み合わせる理由

多層防御（Defense in Depth）とは、一つの対策が効かなかった場合にも、別の対策で影響を抑えられるよう、役割の異なる保護を組み合わせる考え方です。 WordPressの安全性を「導入しているプラグインの数」で判断しないのと同様に、保護機能は数よりも対象と運用状態が重要です。WordPress公式のHardeningも、セキュリティを完全な危険の排除ではなく、適切な対策を組み合わせたリスクの低減として位置付けています。出典：WordPress公式：Hardening・OWASP：仮想パッチ

たとえば、パスワードの使い回しを避け、管理者アカウントに適切なMFAを設定すれば、認証情報の流出からの不正ログインを難しくできます。さらに、その管理者が不要な権限を持たず、作業の記録や異常通知が整っていれば、万一ログインが成立しても被害範囲の抑制や発見につながる場合があります。ただし、ログインを介さない脆弱性には別の対策が必要です。開発元の修正を適用し、必要に応じてWAFで特定の危険な要求を抑えることは、認証対策とは異なる役割を担います。出典：OWASP：MFA・OWASP：認可・OWASP：仮想パッチ

通信のTLS、セッションCookieの属性、ファイル権限も同様です。TLSは通信途中の盗聴・改ざんのリスクを減らし、Cookie属性はブラウザが認証情報を扱う条件を補強し、ファイル権限はサーバー内の操作範囲を絞ります。しかし、どれも未修正のプログラムの欠陥を自動的に直す機能ではありません。 ログ監視や改ざん検知は問題を見つける補助であって、脆弱性の修正やアクセス制限そのものとは役割が異なります。出典：OWASP：TLS・OWASP：セッション管理・WordPress公式：ファイル権限・OWASP：ログ管理

表T11｜代表的なセキュリティ対策の効果と限界

表の「減らせるリスク」は、適切な範囲に対策が適用され、正常に運用されている場合の主な狙いです。導入のみで効果を保証するものではありません。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

同じ「セキュリティ」という言葉でも、防ぐ対策、影響範囲を狭める対策、異常を発見する対策、修正する対策が混在しています。表を読むときは、一つの行を別の行の代わりにしないでください。ソフトウェア更新を行わずWAFだけに頼ることも、管理者の認証を弱いまま更新だけを続けることも、残るリスクを説明できない状態です。出典：WordPress公式：Hardening・OWASP：仮想パッチ・OWASP：認証

小規模な企業や店舗であっても、すべての製品を導入する必要があるという話ではありません。まず、管理対象の更新を担当できるか、必要なアカウントの認証・権限が適切か、バックアップの責任者がいるかを基礎として考えます。そのうえで、管理画面へアクセスする場所、フォームやAPIの利用、扱う情報の重要性、保守契約で対応できる範囲に応じて、WAFや追加のアクセス制限、検知機能を選びます。これは対策を増やす順番を一律に決めたものではなく、継続して管理できる組み合わせを選ぶための考え方です。出典：WordPress公式：Hardening・OWASP：認証・認可

対策が増えれば、その分だけ更新、例外設定、認証手段の復旧、ログ通知を見て対応を判断する作業、機能の競合といった管理負担も増えます。設定が重複して正当な利用者を締め出すことも、対策が複雑すぎて誰も実情を把握できなくなることも避けたい状態です。それぞれが「何を守り、誰が確認し、何が残るか」を説明できることが、長く運用できる多層防御につながります。

なお、適切に対策を組み合わせていても、侵害の可能性がゼロになるわけではありません。不審な変更や予期しない管理者アカウントなどが見つかった場合は、通常の設定見直しと区別し、第12章「改ざんや侵害が疑われるときの初動と復旧」で説明する対応判断へ進みます。

関連する説明：更新と保守／侵害時の対応／役割を記録する
この章の目次へ・全体の目次へ

第12章

改ざんや侵害が疑われるときの初動と復旧

サイトに不審な変更が見つかったとき、最初にすべきことは「すぐ元に戻す」ことではありません。 いまも被害が広がっていないかを確認し、発見時の状況を記録して、操作権限を持つ担当者と対応を決めます。不正なページを削除したり、バックアップを上書き復元したりすると、見た目は元に戻っても、侵入に使われた経路や別の不正な変更が残る可能性があります。調査に必要な記録も失われかねません。

この章でわかること

• 侵害を疑う兆候：転送・不正ページ・未知の管理者など
• 被害拡大の防止と証拠保全を優先する理由
• サーバー事業者・保守担当者への連絡
• 侵入経路・不正ファイル・アカウントの調査
• 原因を除去して安全な状態から復旧する
• 顧客情報・第三者被害が疑われるときの対応判断
• 復旧後の確認と再発防止

一方、証拠のために危険な転送や情報送信を放置してよいわけでもありません。被害を止める判断と、後から原因を調べられる状態を残す判断を並行して進めるのが基本です。必要な措置は被害の切迫性、契約上の権限、サーバー構成によって異なります。ここでは、技術に詳しくない運営者も専門担当者と適切に連携できるよう、疑いの発見から再公開までを説明します。出典：WordPress公式の侵害対応・IPAの中小企業向け手引き・NISTのインシデント対応指針

いま必要な判断に合わせて、次の節から確認できます。

• 不審な転送や情報送信などの被害が続いている、または状況が分からない場合は、被害拡大防止と証拠保全の初動へ。
• サーバー会社や保守担当者に状況を伝える場合は、連絡先と伝える事項へ。
• 復旧したサイトを再公開できるか判断する場合は、復旧後の確認と再公開判断へ。

侵害を疑う兆候：転送・不正ページ・未知の管理者など

身に覚えのないページや管理者が見つかったら、侵害の可能性を考えて記録し、関係者に確認します。ただし、その時点で侵害が確定したわけではありません。 WordPressの不正な変更は、公開ページだけでなく管理画面、サーバー上のファイル、データベース、メール送信などにも現れる場合があります。出典：WordPress公式の侵害兆候・WordPress公式のセキュリティ指針

例えば、次のような異常は確認のきっかけになります。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

不審な更新や予期しないログイン障害は調査の入口です。一方、正常に表示されることも侵害がない証明にはなりません。閲覧者の地域や端末、流入元によって不正な転送が出たり出なかったりする可能性があり、表示だけではデータベースや管理権限の状態までは分かりません。

発見者は、気づいた日時とタイムゾーン、対象URL、どの画面・操作で何が起きたか、表示された警告、確認した人、直前に把握している更新や改修を控えます。安全に取得できる範囲でスクリーンショットを残し、後から判明した情報とは分けて追記します。検索結果の表示なら検索語や確認日時も有用です。管理情報や顧客情報が写る画面を無制限に共有しないでください。

不審なリンクを繰り返し開く、疑わしいファイルを実行する、攻撃を再現して確かめる、といった行為は行いません。とくに訪問者が危険な場所へ誘導される疑いがある場合、一般の端末から再訪を重ねず、保守担当者にその条件を伝えます。状況は「兆候を発見」「侵害を疑って調査中」「記録から確認できた事実」「侵害が確認された」のように、根拠に合わせて表現します。

被害拡大の防止と証拠保全を優先する理由

初動対応は、被害を抑えることと、後で何が起きたかを調べる材料を残すことが目的です。 ここでいう証拠保全とは、調査のためにログやファイルなどの状態を、許可された方法で保護することです。専門担当者がどのデータを取得できるかは契約や管理権限によって異なり、運営者がすべての記録を直接取り出せるとは限りません。出典：IPAのインシデント対応手引き・JPCERT/CCの対応資料・NISTのインシデント対応指針

たとえば、不審なプログラムをすぐ削除すると、その内容や作成日時、関係する通信との対応を調べにくくなることがあります。管理画面から何度も保存操作を行うと、変更記録が増え、元の状態との比較が複雑になります。ログの消去、原因不明のままの更新やバックアップ復元、無計画な再起動も、調査に必要な情報を失う要因です。稼働中の処理や通信など、停止によって消える情報もあります。

もっとも、現に情報が外部へ送信されている、危険なページへ閲覧者が誘導され続けている、第三者への不正通信が継続しているといった切迫した状況で、保全のために公開を続けるべきではありません。運営責任者と技術担当者は、緊急連絡と並行して、問題の機能・アクセス経路だけを制限できるか、Web公開全体の一時停止が必要か、ホスティング事業者による通信遮断や隔離が可能かを判断します。

判断の分かれ目は次のとおりです。

• 進行・切迫を示す事実がある場合：利用者や第三者への影響を止める措置を急ぎます。担当者に直ちに連絡し、実施できる範囲で時刻・理由・操作内容を記録します。安全に残せる情報を保全しつつ、証拠収集のために危険を継続させません。
• 現時点で進行の兆候を確認していない場合：不用意な削除・復元・再起動を避け、専門担当者とログやファイル・データベースの複製方法、必要なアクセス制限を協議します。侵害や被害の継続が否定されたわけではないため、放置せず早急に確認します。
• 判断材料が足りない場合：進行していないと扱わず、分からない点と取得できる情報を担当者へ直ちに伝えます。必要な一時制限と保全を並行して判断し、状況が分かったら対応を見直します。操作権限も不明なら、契約者や運用責任者を通じてサーバー会社・保守担当者へ連絡し、緊急停止を含め誰が判断・実行できるか確認します。

状況を確認しつつ、記録・連絡・封じ込めを必要に応じて並行して判断

画像を拡大する ＋

図の内容をテキストで読む

01｜発見と並行して始める対応

異常に気づく（この時点で侵害確定とは限らない）

不審な転送・未知の管理者・不正ページ・異常な通信などを発見した場合

発見時から並行して扱う　／　被害が切迫する場合は制限を優先

• 記録・証拠の保全

  日時・タイムゾーン／URL／症状・操作。取得可能なログや状態を安全に保全

• 担当者への連絡・権限確認

  保守担当・サーバー会社・責任者に連絡。契約・操作権限を確認

• 必要な封じ込め

  危険が続く場合は機能・通信・公開範囲の制限を権限ある担当が判断

現時点の観測事実から、3つの状態を分けて判断

現時点で把握した被害拡大の状況は？

3つの状態を分けて扱う（判断は新しい情報で見直す）

• ① 進行・切迫を示す事実がある

  例：情報送信や危険な転送が続く。権限ある担当が封じ込めを急ぎ、記録・可能な証拠保全も継続

• ② 現時点で進行の兆候を確認していない

  「侵害なし」の証明ではない。専門担当と保全・調査、必要な制限を協議する

• ③ 判断材料が足りない

  不明 ≠ 進行なし。担当へ直ちに連絡し、暫定制限と保全を並行判断する

3つの経路すべて：記録・連絡・必要な保全と制限を続け、判断を更新

02｜担当者と調査・対処・復旧を進める

1. 影響範囲・第三者影響を調査

   ログ、ファイル、DB、権限、外部連携。事実・推定・未確認を区別

2. 侵害経路・不正変更へ対処

   確認された入口・残存物・認証を対処。範囲により再構築も検討

3. 復旧の正常性と監視を確認

   表示・重要機能・転送・権限・ログ・連絡体制を検証

図は担当者間の判断関係であり、実際に個々の操作が必ず左から右に1件ずつ終わってから次へ進む厳密な作業命令ではありません。

対策と残存リスクを踏まえ、責任者が判断

再公開条件を責任者が判断できるか？

対策・機能・第三者影響・残存リスク・監視と制限を確認

• 未確認・対策不足／判断できない

  再公開を見送り、調査・対処と再評価を続ける

• 条件を満たすと責任者が承認

  必要な制限と監視を伴い再公開。記録を残す

※ 原因の完全解明は一律の必須条件ではない／未確認のまま自動承認もしない。

図D07｜侵害が疑われた際の判断と連携。記録・連絡・必要な封じ込めを並行して進め、状況不明の場合も速やかに担当者と判断します。再公開は残存リスクを踏まえた責任者の承認が必要です。

参考資料：NIST SP 800-61 Rev.3／IPA：インシデント対応の手引き／JPCERT/CC：インシデントハンドリング／WordPress公式：侵害時の確認

担当者が証拠を取得する場合は、対象、取得日時、取得者、保管場所、引き渡し先、実施した操作を記録します。取得元をむやみに変更せず、可能なら元データと作業用の複製を分け、ファイルの同一性確認にハッシュ値などを利用します。調査用に確保する、侵害が疑われる状態のバックアップは「安全に再公開できるバックアップ」と別物です。保存先へのアクセスを制限し、パスワード、Cookie、APIキー、顧客情報、秘密鍵などを一般公開の報告書や無保護の連絡手段に載せないよう管理してください。出典：OWASPのログ管理指針・WordPress公式の侵害対応

サーバーの停止・再起動やネットワーク遮断に唯一の正解順序はありません。 稼働中の証拠を失う可能性と、接続を維持することによる被害拡大を比較する必要があります。作業の実行は許可された担当者が行い、契約範囲にない操作は事業者と協議します。保全のための時間が限られている場合も、何を取得できず、どのような判断で封じ込めたかを残すことが重要です。

サーバー事業者・保守担当者への連絡

最初に連絡する相手は、問題が起きている場所と、停止・調査の権限を持つ人によって決まります。 WordPress管理画面で未知の管理者を見つけた場合は制作・保守担当者が調査の入口になり、サーバーから不審な通信が出ているという通知ならホスティング事業者にも早急に連絡する必要があります。実際には双方への連絡を並行させる場面もあります。出典：WordPress公式の侵害対応・WordPress公式のセキュリティ指針

連絡時には、「侵害されたと思う」だけでなく、次の内容を一つの記録にまとめると調査が進みやすくなります。

1. 対象と症状：ドメイン、影響のあるURL、見つかったページ・管理者・転送・警告の内容。証拠の画像や通知は安全な共有方法で渡す。
2. 時系列：最初に異常に気づいた日時と、その後の発生状況。正確な発生開始時刻が不明なら「不明」とする。
3. 直近の正規変更：公開作業、更新、プラグインの追加、担当者・権限・DNS・CDN・メール設定の変更と、その実施者。
4. 現在の危険と実施操作：個人情報送信や不正転送の疑い、公開制限の有無、すでに実施した更新・削除・ログイン操作と時刻。
5. 権限と依頼内容：契約者・連絡窓口、利用サービス、保存期間が短いログの保全依頼、停止や復旧の承認者、回答を必要とする緊急性。

DNS（ドメイン名と接続先を結ぶ設定）、CDN（コンテンツ配信サービス）、メール、外部フォームや決済、連携APIなどが関係する場合は、それぞれの管理者にも調査範囲を広げます。見覚えのない転送がWordPress内の設定ではなく、ドメイン設定や配信経路で起きている可能性もあるためです。

管理者権限や契約情報が分からないときは、社内の契約・請求記録、制作時の引き継ぎ資料、正規の契約窓口をたどります。第三者の資格情報を借りたり、契約外のサーバーを操作したりしません。相談先の例として、JPCERT/CCは国内のセキュリティインシデントの情報提供・相談窓口を案内しています。ただし、相談窓口への連絡と、各契約に基づく有償の調査・復旧作業は別です。出典：JPCERT/CCの相談案内

侵入経路・不正ファイル・アカウントの調査

調査では「侵害が本当に起きたか」「何に影響したか」「どう入り、どう残ったか」を分けて確認します。 不審なファイルがある場所は、攻撃後に設置された場所かもしれません。そこが最初の侵入経路だとは限らず、WordPressの脆弱性が見つかったとしても、その弱点が今回使われた証拠にはなりません。出典：WordPress公式の侵害対応・NISTのインシデント対応指針

技術担当者は、正規の変更履歴と照合しながら、可能な範囲で時系列を組み立てます。主な確認対象は、Webサーバーのアクセスログ（要求されたURLや時刻など）、エラーログ（処理の失敗）、WAFの検知・遮断履歴、サーバーや認証サービスのログイン記録、WordPressの操作・監査ログです。ただし、WordPressの操作履歴は環境やプラグインによって記録の有無と範囲が異なります。

ログの意味は一段ずつ確かめる必要があります。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

ファイルについては、公式配布物や正規の制作記録との比較が手がかりになります。WordPress本体や拡張機能、独自テーマ、アップロード領域、サーバー設定に加え、データベース内の投稿・固定ページ・ユーザー・権限・各種設定も確認の対象です。公開画面だけから、すべての不正変更は見つけられません。

さらに、調査範囲によっては、通常の管理画面以外から再び操作できる「バックドア」、不正な定期実行処理（cron等）、外部と連携するAPIの資格情報、SFTP・SSHなどサーバー管理の認証、ドメインやメールの管理権限を確認する必要があります。知らない管理者の削除だけで、別の経路まで閉じたことにはなりません。 一方、見覚えがないという理由だけで正規の保守用ファイルや予約処理を不正と判断することも避けます。

専門担当者は、ログの保存期間や欠落、共有サーバーで取得できる記録の制約、保存時刻のずれ、攻撃者による変更の可能性も踏まえて結論を出します。何も記録が見つからなかった場合も、「証拠が取得できなかった」と「侵害がなかった」は同じではありません。確定事項、推定事項、調査不能な部分を分けて報告します。出典：OWASPのログ管理指針・JPCERT/CCの対応資料

原因を除去して安全な状態から復旧する

復旧の出発点は、表示を直すことではなく、確認された侵害経路と残された不正な変更を除去できるかを判断することです。 不正な広告ページを消しても、別の管理者アカウントやバックドアが残れば再び改ざんされかねません。パスワード変更やWordPress更新は重要な対策ですが、それだけで侵害後に追加されたファイル、データベースの変更、別の認証経路が自動的に消えるわけではありません。出典：WordPress公式の侵害対応・WordPress公式のセキュリティ指針

専門担当者は、保全した調査資料を失わないようにしたうえで、被害の範囲に合った復旧方法を選びます。WordPress本体やテーマ・プラグインを信頼できる正規の配布物から入れ直すことと、バックアップからファイル・データベースを過去の時点へ戻すことは別の方法です。どちらを選んでも、独自開発部分の正規性、アップロードされたデータ、サーバー側の設定、外部の管理アカウントを別途確認する場合があります。感染や改ざんの範囲が限定できないときには、信頼できる新しい環境への再構築も選択肢となりますが、すべての事案で一律に全削除・初期化するとは限りません。

バックアップは「取得できた」「侵害前の日付だった」だけで安全とは判断できません。侵入の開始が判明していなければ、古いバックアップにも不正なファイル・アカウント・設定が含まれる可能性があります。ファイルだけを戻してもデータベースに不正なページが残る場合があり、逆にデータベースだけを戻せばファイルの問題は残ります。調査用に保全した侵害時の複製と、正常性を評価して復旧用に採用するデータは区別します。出典：WordPress公式のバックアップ・WordPress公式のファイルのバックアップ・WordPress公式のデータベースのバックアップ

復元は新しいデータを失うこともあります。例えば、不審な変更が始まる前のデータベースを丸ごと戻した場合、その後に受け付けた問い合わせや予約、会員登録などの正当な記録まで消えるおそれがあります。担当者は、データの更新時刻・業務上の重要度・不正な変更の混入範囲を確かめ、何を戻し、何を安全に引き継ぎ、何を復元できないかを運営責任者と合意してから作業します。単に「一番新しいバックアップ」を選ぶのも適切ではありません。

原因や範囲に応じて、次の対応を組み合わせます。

1. 残存経路の除去：確認された不正ファイル、設定、アカウント、定期実行処理などを、調査記録を保全したうえで処理し、別の不正な入口がないか確認する。
2. 弱点への対処：侵入に使われた可能性のある製品や設定を特定し、適用対象と互換性を確認した修正版・提供元の修正を適用する。PHPとWordPress、各拡張機能は別々の対象として扱う。
3. 認証の立て直し：WordPress管理者だけでなく、必要に応じてサーバー、SFTP・SSH、データベース、ドメイン・DNS、CDN、メール、外部APIの資格情報を見直し、利用中セッションや発行済みトークンの無効化も検討する。変更操作を攻撃者が観測し得る状況なら、先に安全な管理経路を確保する。
4. 検証環境での確認：複製を持ち込んで起動する前に、検証環境から本番のデータや外部サービスへ書き込めず、メール・決済・定期処理などが実業務へ作用しないよう、隔離と接続設定を確認する。そのうえで再構築・復元後のファイルとデータベースを照合し、公開前に権限、ログイン、フォーム、外部連携、不審な転送、ログを確認する。準備の考え方は第10章の更新・保守手順を参照する。

どの項目も、管理権限と実際の影響範囲によって実施者や順序が変わります。原因不明のまま公開を急げば、同じ入口を通じた再侵害の危険を評価できません。 調査の限界によって原因を確定できない場合もあります。その際は「安全を証明できた」とせず、どの追加措置・監視・制限を条件に運用を再開できるのか、責任者がリスクを把握して決めます。実施操作、復元元、確認結果、承認内容を残すことが不可欠です。

顧客情報・第三者被害が疑われるときの対応判断

Webサイトを復旧しても、顧客や閲覧者、取引先への影響が残る場合があります。 調査では、サイト内に保存された個人データに加え、フォームなどで取得する途中の個人情報も対象に含めて確認します。それぞれについて、外部から閲覧・取得できた可能性があるか、実際に第三者へ渡ったことを示す記録があるかを区別します。アクセスできた可能性と流出の確定は同義ではありません。しかし、確定するまで何もしなくてよいという意味でもありません。

問い合わせフォームの送信先が改ざんされていれば、これから入力される情報が第三者に届く可能性があります。偽のログイン画面や外部サイトへの転送があれば、閲覧者が認証情報を入力してしまう危険もあります。サイトやメール機能が迷惑メール・マルウェアの配布、第三者への不正通信に利用されていた可能性も、必要に応じて調べます。これらは個別の事例で起こり得る影響であり、WordPressが改ざんされたという理由だけで、これらの被害がすべて起きたとは断定できません。出典：WordPress公式の侵害対応・IPAの中小企業向け手引き

個人情報保護法上の判断も、事案の内容によって異なります。日本の個人情報保護委員会は、民間の個人情報取扱事業者に関して、個人データの漏えい等が発生した、またはそのおそれがある場合のうち、一定の類型を報告対象としています。主な類型は、要配慮個人情報を含むもの、不正利用による財産的被害のおそれがあるもの、事業者に対する不正目的が疑われる行為によるもの、本人の数が1,000人を超えるものです。報告対象の判断には、取り扱う情報の種類、実際の事態やそのおそれ、事業者の立場、法令上の例外などを確認する必要があります。単なる表示の不具合や、個人データへの影響が確認されていない異常を、一律に「法定報告が必要」とはしません。出典：個人情報保護委員会の漏えい等対応案内・同委員会のガイドライン

自社のデータベースに保存される前だった、という理由だけで報告対象から除外できるわけではありません。 事業者に対する不正目的が疑われる行為という類型では、事業者が取得し、または取得しようとしている個人情報のうち、個人データとして取り扱う予定の情報も対象に含まれます。例えば、顧客情報を登録する正規フォームが改ざんされ、入力情報が第三者へ送られる場合です。保存済みの顧客台帳に異常が見つからなくても、フォームの改ざん期間、対象項目、送信経路、利用者への影響を確認します。単に第三者の偽サイトが存在するという場合と、自社に対する改ざん等の行為によって情報が取得される場合も、同じ条件と決めつけません。出典：個人情報保護委員会のガイドライン3-5-1・3-5-3・同委員会FAQ：取得前の情報と偽サイトへの誘導

報告対象事態に該当する場合、速報はその事態を知った後、速やかに行います。ガイドライン上の目安は、事態を知った時点から概ね3〜5日以内です。確報は事態を知った日から原則30日以内、上記の不正目的が疑われる行為の類型では60日以内です。法人では、いずれかの部署が報告対象事態を知った時点が基準となるため、経営者の承認や調査完了を待ってから数え始めるものではありません。速報はその時点で把握している内容を報告し、未判明事項は調査を続けます。出典：個人情報保護委員会のガイドライン3-5-3-3・3-5-3-4

報告すべき相手が別の所管機関となる場合や、委託先から委託元への通知による取扱いもあります。これらはすべての侵害に自動適用する期限ではありません。本人への通知についても、法定の報告対象事態か、通知が困難な場合の代替措置が適用されるか等を個別に判断します。対外的な公表、取引先への説明、閲覧者への注意喚起は、法定報告・本人通知とは分けて検討してください。出典：個人情報保護委員会のガイドライン・報告と本人通知・同委員会の漏えい等対応案内

社内の責任者、個人情報管理・法務担当者、保守担当者、必要な専門家が、把握した事実と不明点、影響が及ぶ可能性のある人、二次被害を防ぐために伝えるべき内容を整理します。利用者にパスワード変更や不審なメールへの注意を求める必要がある場合は、正規の連絡手段を確認し、推測を断定せず案内します。警察やJPCERT/CC、IPA等への相談の必要性も事案に応じて検討します。対外説明を先延ばしにして被害を広げず、同時に根拠のない「漏えいなし」「完全復旧」の発表も避けます。出典：JPCERT/CCの相談案内・IPAの中小企業向け手引き

復旧後の確認と再発防止

サイトが再び表示されたことと、通常運用に戻してよいことは同じではありません。 再公開の判断には、不正な変更の対処と侵入経路への対応がどこまで終わったか、重要機能が正常か、顧客・第三者への影響に対する対応が進んでいるかを含めます。確認は担当者による技術的な説明と、運営責任者による事業上の承認の両方が必要です。出典：NISTのインシデント対応指針・WordPress公式の侵害対応

再公開前には、少なくとも次の観点を、確認済み・要再確認・未解決に分けて整理します。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

ただし、一つの画面を確認しただけで、サイト内のすべての不正な変更を排除したことにはなりません。重要な機能は適切な環境でテストし、公開・管理者・外部連携の各経路を確認します。再開後も一定期間は、異常なログイン、ファイルや設定の変更、検索結果に残る不正ページ、外部への不自然な通信などを、取得可能なログと照らして監視します。検索エンジンの表示やセキュリティ警告は、修正直後に必ず消えるとは限らないため、残存する公開ページと、外部サービスの反映待ちを区別して対応します。出典：WordPress公式のログ・不正変更の確認・OWASPのログ管理指針

こうしたセキュリティ上の監視とは別に、サイトへ接続できるか、応答時間が悪化していないかという稼働・性能の監視も再開後の業務継続に役立ちます。監視の種類ごとに担当者、通知先、異常時の判断先を決めます。正常な応答が続いていることだけで、不正な変更がないと判断しません。出典：WordPress公式の稼働・性能監視

調査によっては、当初の侵入方法や影響範囲を完全には特定できません。その場合は、何を確認できなかったか、代わりにどんな制限・再構築・監視を行ったか、残るリスクを誰が了承したかを記録します。必要な判断ができないなら、再公開を延期する、影響する機能だけ停止して運用する、専門調査を追加する、といった選択肢があります。売上への影響だけで安全確認を省略せず、事業継続との両面から承認してください。

復旧が落ち着いたら、なぜ不正な変更に気づくまで時間がかかったのか、誰が緊急連絡を受けるべきだったか、バックアップやログを必要なときに取り出せたか、権限や契約の分担に、担当が決まっていない部分がなかったかを振り返ります。今回の判断と未解決事項を次の管理体制へ反映することが再発防止につながります。長期的にWordPressを使い続けるか、別の構成を選ぶかは、事故直後の復旧判断と分けて、機能・保守体制・費用などを踏まえて検討します。

関連する説明：バックアップと復元試験／ログ監視と検知／再発防止の継続点検
この章の目次へ・全体の目次へ

第13章

WordPressを使い続けるか、別の構成へ移行するか

WordPressを使い続けるかどうかは、製品名だけで決めるものではありません。 自社に必要な機能、記事を更新する人、公開時にサーバーで動く処理、保守を引き受ける人、かけられる費用を確かめ、無理なく管理できる構成を選びます。適切に保守したWordPressの継続も、別方式への移行と同じように検討すべき選択肢です。

この章でわかること

• 適切に保守したWordPressを継続する選択
• 静的HTMLサイトに変更する選択
• 静的公開とCMSを組み合わせる選択
• Next.js・Astro等で再構築する選択
• Studio等のサイト制作プラットフォームを利用する選択
• セキュリティ・更新性・管理負担・費用・機能の比較
• 移行時のURL・フォーム・検索流入・復元リスク
• 自社の条件に応じた判断基準

同じ「WordPressサイト」でも、WordPress自体の欠陥、不要なプラグインを増やした構成、更新担当者が決まっていない運用では、改善すべき点が違います。別の仕組みに移れば減らせる攻撃経路はありますが、新たな管理対象や移行作業も生じます。また、改ざん・侵害が疑われる場合は、構成選定に先立って第12章の被害拡大防止、証拠保全、原因調査、安全な復旧を検討する必要があります。未確認の旧データを新サイトへ移すことは、原因除去の代わりになりません。

適切に保守したWordPressを継続する選択

今のサイトに必要な機能がそろい、更新と保守の担当が確保できるなら、WordPressを継続する合理的な理由があります。 記事や画像の登録、下書き、公開予約、編集権限の分担などを使い慣れた画面から行えます。すでに蓄積した記事、画像、独自のページ、URL、業務で必要なプラグインを維持できる点も、単に「移行しない」以上の価値です。こうした編集・拡張機能はWordPressの公式案内にも示されています。出典：WordPressの機能

ただし、継続の前提は必要な機能を残し、管理できる状態へ整えることです。WordPress本体だけでなく、PHP、テーマ、プラグイン、独自コードの更新・互換性確認が必要になります。使っていない拡張機能を整理し、管理者権限を持つ人と外部委託先のアクセスを見直し、バックアップの取得対象と復元できる条件を確かめます。古い機能の代替や保守契約の見直しによって、サイト全体を移さず問題を解決できる場合もあります。継続に必要な作業と担当を具体化する際は、第10章の更新・保守手順と第11章の防御策の効果・限界を確認してください。出典：WordPressの更新・セキュリティ管理・バックアップ

継続が難しくなるのは、例えば不可欠なプラグインの保守が終了している、独自改修の仕様を誰も説明できない、担当者が交代するたびに編集や復旧の作業が止まるといった場合です。ただし、これはWordPressという製品だけの問題とは限りません。製品の限界、採用した構成の問題、契約・運用の不備を分けて確認し、改善可能な部分と移行を検討すべき部分を整理します。

また、ここで主に想定するのは、WordPress.orgで配布されるソフトウェアを契約サーバーなどで運用する形です。WordPress.comのようなホスティングサービスでは、基盤の管理や使える機能、更新の担当範囲が契約によって変わります。「WordPressだからPHPやサーバーのすべてを自社で更新する」とも「サービスを使えば自社の責任がなくなる」とも一律には言えません。出典：WordPress.orgとWordPress.comの違い

静的HTMLサイトに変更する選択

公開する内容が比較的少なく、ページを頻繁に変更しないなら、静的HTMLサイトは検討しやすい方式です。 静的公開とは、見出しや本文などを含むHTMLファイルを事前に作り、閲覧者からの要求に対して、そのファイルや画像・CSS・JavaScriptを配信する形です。公開ページを表示するたびにWordPressのPHPを実行したり、記事データをデータベースから取得したりしない構成を選べます。

この場合、公開側にWordPress・PHP・データベースを置かず、それらへの公開リクエスト経路をなくせる範囲で、動的な処理に起因する攻撃面を減らせます。ただし、静的なページそのものが脆弱性をなくすわけではありません。配信基盤、ドメインとDNS、管理アカウント、更新用端末、アップロード権限、外部JavaScriptや埋め込み機能は引き続き管理対象です。ブラウザで動くコードや読み込む第三者サービスにも不具合や設定ミスが起こり得ます。

特に、公開ページが静的であることと、サイト全体に動的処理がないことは別です。問い合わせフォームを外部サービスで受ける場合、送信内容はそのサービスで処理されます。検索、予約、決済、会員向け表示なども、ブラウザ側の処理、外部API、別のサーバーなどに任せる設計が必要です。これらの機能について、入力情報の扱い、認証、サービス障害、運用担当を含めて評価します。

更新性にも条件があります。制作担当者が直接HTMLを編集する構成なら、見た目の調整はしやすくても、事務担当者が日々の記事を追加するには不向きかもしれません。逆に、更新が少ない案内ページでは、大きなCMSを維持する必要がない場合があります。ページ数、更新頻度、更新者の技術、必要な機能を確認して初めて、静的化による負担の増減を判断できます。

静的公開とCMSを組み合わせる選択

記事を管理画面から編集したいが、公開ページを毎回CMSで生成する必要はない場合、静的公開とCMSの組み合わせが候補になります。 CMSは文章や画像を管理する場所として残し、閲覧者向けのページは別に事前生成して公開する考え方です。CMSでの編集と、公開ページを配信する仕組みを分けます。

典型的には、①編集担当者がCMSで記事を保存する、②制作・生成側の処理がCMSのデータを取得する、③ビルドという工程で公開用HTMLなどを作る、④生成したファイルを配信基盤へ公開する、という流れです。WordPressを管理用CMSとして利用し、必要なデータをREST APIから取得する構成も技術的には可能です。ただし、実際の権限と利用できるデータはAPIの設計・設定によって変わります。出典：WordPress REST API

静的に生成したページだけを一般公開するなら、閲覧者がCMS本体へ直接アクセスする必要のない構成を取れます。公開側の動的な入口を減らせる半面、CMSの更新、編集アカウントの認証、APIの権限設定、APIキーや秘密情報の保護は残ります。 CMS管理画面をどのネットワークから使えるのか、データ取得時に公開してよい情報だけを扱っているかも確認が必要です。

編集後の公開方法には注意が必要です。更新のたびにビルドと配備が走る場合、その処理に失敗すると、新しい記事がCMSに保存されても公開側へ反映されません。反映までの待ち時間やキャッシュ、公開前プレビュー、公開予約の実現方法も設計次第です。編集担当者、ビルド失敗を検知する人、公開をやり直せる人、配備アカウントを管理する人を先に決めることが重要です。復旧時にはCMSのデータと生成済みサイトの版を対応付けて確認します。

なお、ヘッドレスCMS（表示画面とコンテンツ管理を分けたCMS）を採用しただけでは、公開ページが静的になるとは限りません。 閲覧のたびにサーバーがCMSから情報を取得する構成も、ブラウザがAPIにアクセスする構成もあります。採用する生成・配信方式を確かめ、公開側にどの処理が残るのかを判断します。

Next.js・Astro等で再構築する選択

Next.jsやAstroへの再構築で重要なのは、フレームワーク名より「どこで、いつページを生成するか」です。 フレームワークはWebサイトの作成を助ける開発用の仕組みですが、採用するだけで公開サイトの実行方式が一つに定まるわけではありません。

例えばNext.jsでは、ビルド時にHTMLなどを生成して静的ファイルとして配信する「静的エクスポート」を選べます。一方、リクエスト内容によって動的に処理する機能など、サーバーを必要とする機能は静的エクスポートで利用できないものがあります。Astroもページの事前生成を基本としつつ、必要なページを要求時に生成するオンデマンドレンダリングを選べます。後者では配備先に応じたアダプターと実行環境が必要です。これは両開発元の公式資料で区別されています。出典：Next.jsの静的エクスポート・Astroのオンデマンドレンダリング・Astroの構成設定

静的生成であれば、公開側に常時動くアプリケーションサーバーを置かずに済む構成があります。他方、リクエストごとのページ生成や、サイト側で動かす認証・APIなどの処理を採用するなら、その実行環境や依存パッケージ、認証処理、秘密情報の管理が加わります。ページは事前生成でも、ブラウザが外部APIを呼び出す構成なら、そこで別のサービスに依存します。「PHPを使わないから安全」「新しいフレームワークだから保守不要」という関係にはなりません。

開発・配備側にも継続管理が必要です。フレームワークとライブラリのセキュリティ修正、使用する実行環境、外部APIの仕様変更、ビルド時に使う認証情報、配備できる権限の限定、失敗時の復元方法を管理します。担当者交代時には、ソースコードだけでなく、ビルド方法、環境変数の管理者、ドメインと配信基盤の契約者、障害対応手順が引き継がれる必要があります。Next.jsの公式導入資料にも依存パッケージを含めた開発環境の前提が示されています。出典：Next.jsの導入資料

複雑な表示、独自の検索や外部システム連携を作り込みたい場合には柔軟性が役立ちますが、制作・改修を担当できる人がいなければ、WordPressの管理画面より運用しにくくなる可能性もあります。表示速度やSEOへの影響は、生成方法、実装品質、画像、外部スクリプト、配信環境、検索エンジンが取得できる内容によって変わります。フレームワーク名だけで速さや検索順位は保証できません。

Studio等のサイト制作プラットフォームを利用する選択

自社でサーバー用のプログラムや配備環境を管理する体制がない場合、サイト制作プラットフォームを利用する選択肢があります。 ここでいうStudioは、サイトを作成・公開できるサービス「Studio.Design」であり、この記事の掲載元である「Studio Attrait」とは別です。

プラットフォームでは、サービス提供者が公開基盤や編集環境を運営するため、利用者が個別のWebサーバーやPHPなどを自分で構築・更新する場面を減らせます。一方で、自社が直接管理しないことと、管理そのものが不要であることは違います。 サービス側の保守に依存しながら、利用者は契約、ログイン認証、共同編集者の権限、掲載内容、独自ドメイン、外部連携、問い合わせ情報などを管理します。

StudioではCMSを使った記事・情報の管理や公開状態の設定、フォームなどの機能が案内されています。ただし、必要な機能、利用枠、独自ドメインや権限の条件はプランと設定によって異なります。予約・決済・会員機能を希望するなら、標準機能で対応できるのか、外部サービスを組み合わせるのかを一つずつ確かめます。担当者が管理画面を使いやすいかだけでなく、担当者が退職したときの権限の引き継ぎまで含めて検討します。出典：Studio CMS・Studioのプランと機能・Studioの権限

復元も一括りにはできません。Studioの公式ヘルプによれば、デザイン編集のバージョン履歴は保存期間がプランによって異なり、CMSやフォームのデータは同じバージョン復元の対象ではありません。フォーム回答も、ダッシュボードへ残すかメール通知のみとするかで管理場所が変わります。履歴があるという理由だけで、あらゆるデータを同じ時点へ戻せると考えないことが重要です。出典：Studioのバージョン管理・バックアップ範囲・フォーム回答の保存先

将来サービスを変更する場合には、文章や画像、CMSデータ、URL、デザイン、設定、フォーム回答を何の形式で持ち出せるかが判断材料です。Studio公式では公開サイトのHTMLコードを外部へ出力する機能を提供しない旨が案内されています。契約終了後も同じサイトを別の環境へそのまま持っていけるとは限らず、再制作が必要になる範囲を見積もっておく必要があります。また、サービス障害時の連絡方法と、独自ドメインのDNS・メールを誰が管理するかも確認します。出典：StudioとHTMLコード・Studioの独自ドメイン設定

セキュリティ・更新性・管理負担・費用・機能の比較

比較で先にそろえるべきなのは、各方式で想定する構成です。 ここではWordPressは一般の閲覧要求に応じてPHP等が動く自己管理型、静的HTMLは公開側にCMSを置かない方式、静的公開＋CMSは編集側と配信側を分ける方式を想定します。Next.js・Astro等は静的生成とサーバー処理を条件付きで区別し、Studio等は提供者が公開基盤を運営するサービスとして比較します。

表の五つは、互いに排他的な製品分類ではなく、比較するための代表的な構成例です。例えば、Next.jsやAstroを使って「静的公開とCMSの組み合わせ」を実装できます。WordPressを編集用CMSとして残すことも可能です。名称だけで一つの行を選ばず、自社が採用する公開方式と編集・保守の仕組みを、関係する行にまたがって確認してください。

表T13｜サイト構成と運用方式の比較

この表は安全性の順位でも費用の相場表でもありません。例えば、静的化で公開PHPへの入口をなくしても、問い合わせ処理を新たに外部サービスへ委ねれば、その契約と情報管理が必要になります。反対に、適切に管理されたWordPressが、引き継ぎのない独自システムより運用上の問題が少ない場合もあります。「どこを公開し、誰が何を更新できるか」を比べることに意味があります。出典：WordPressのセキュリティ管理・Next.jsの静的出力・Astroの実行方式

費用も、最初の制作・移行にかかる作業だけでは比較できません。WordPress継続なら定期更新、互換性確認、保守契約や機能整理。静的HTMLなら変更時の編集・制作作業。CMSと静的公開の組み合わせなら、CMSの利用・保守に加えビルドや配信の管理。フレームワークなら開発、依存関係の更新、実行環境と引き継ぎ。プラットフォームなら月額・年額の利用料、機能枠、追加連携、将来の再移行などが比較対象です。ドメイン、フォーム、予約等の外部費用も漏らさず、必要な期間と担当者の作業をそろえて見積もります。費用の削減幅を比べる場合も、同じ機能、保守範囲、契約期間、移行後の運用作業を含めた見積りを用います。

移行時のURL・フォーム・検索流入・復元リスク

サイトの移行では、見た目より先に「現状のどの情報・機能・契約が移るのか」を把握します。 まず全ページのURLだけでなく、記事の本文、画像、PDF、添付ファイル、内部リンク、カテゴリ、検索に表示されているページを棚卸しします。管理画面に残る下書きや非公開情報の扱いも区別し、必要なデータを誰が取り出せるか確認します。

既存のドメインとURLを維持できれば、URL変更に伴う転送作業は減らせます。しかし同じURLでも、本文、内部リンク、見出し、検索エンジンの取得条件などが変われば、検索上の影響がないとは保証できません。URLを変更する場合は旧URLと新URLをページ単位で対応させ、内容に合う移動先へ恒久的なリダイレクトを検討します。無関係な旧ページをすべてトップページへ転送する方法は避け、該当コンテンツが移動しない場合の扱いも決めます。Google Search Centralは、サイト移転に際してURL対応やリダイレクト、移行後の確認を案内しています。出典：GoogleのURL変更を伴う移転・リダイレクトの説明

移行前後に照合したい検索関連の項目は、少なくともページのtitle、主な見出し、canonical（検索エンジンへ優先URLを伝える指定）、robotsによるクロール制御、noindexによるインデックス制御、XMLサイトマップ、内部リンクと画像等へのパスです。制作中の非公開設定がそのまま公開環境へ残っていないかも確認します。切り替え後はSearch Console等でクロールとインデックスの状況、エラー、流入の変化を追い、検索エンジン側の反映には時間がかかり得ることを見込んでおきます。CMSを変えるだけで順位が上がる、同じURLなら順位が下がらない、と約束することはできません。出典：GoogleのURL変更なしの移転・URL変更を伴う移転

フォームは外観だけでなく、送信先、通知先、確認メール、送信データの保存場所、保管期間、迷惑送信対策、個人情報の取り扱いを引き継ぐ必要があります。旧サイトにあった問い合わせ履歴をどう保管するか、外部サービスの契約者が誰かも確認します。サイト内検索、予約、決済、会員ログイン、在庫・顧客管理システムとの連携などは、同じ機能名でも移行先によって実装条件が異なります。対応できない機能や過去データがあるなら、移行を決定する前に影響と代替策を明らかにします。

ドメイン・DNS・SSL証明書・メールもサイトと切り離せません。Webの公開先だけを変えるつもりでも、DNSの設定や証明書の準備により表示へ影響する可能性があります。メールの送受信に使う設定や契約を誤って変更すれば、Web以外の業務も止まり得ます。誰がドメインとDNSを管理し、メールをどのサービスで運用しているかを確認し、切り替え作業の担当・連絡方法・停止を許容できる時間について合意しておきます。出典：Studioの独自ドメインとDNS

更新が続くサイトでは、データを一度複製しただけでは終わりません。移行用のデータを取得した後も記事の追加、フォームの回答、会員情報の更新、予約が発生し得ます。どの時点の内容を新サイトへ反映するか、切り替え中の追加・変更分を誰が引き継ぐかを決め、必要に応じて公開作業や編集の停止期間を設けるか協議します。長時間止められない業務なら、機能別の段階的な移行や別の同期方法を検討します。

移行前には、元のデータと設定を戻せる形で退避し、移行後はページ・リンク・主要機能・権限・データ件数等を適切な環境で確かめる計画を立てます。事前のリハーサルでは、データを複製して起動する前に、本番のデータベースや外部連携への書き込み、実際のメール送信・決済などが起きないように隔離を確認します。検証環境の準備は第10章の考え方と共通です。同時に、どの条件で切り戻すか、旧環境へ戻したときに切り替え後の入力情報を失わないか、誰が切り戻しを承認するかを決めます。退避できたことと、正常に復元できることは別です。侵害が疑われる場合には、第12章の調査と安全性評価を経ずに旧環境・旧バックアップを正常な移行元や切り戻し先として使いません。

移行後は、不要になった旧公開環境、管理用CMS、管理アカウント、APIキー、契約を整理する判断も必要です。ただし、検索用リダイレクト、証拠保全、データ保存義務、復旧計画に必要な部分まで一律に削除してはいけません。旧サービスの停止・解約や認証情報の無効化は、必要なデータと機能の引き継ぎ、責任者の承認を確認してから別途計画します。

自社の条件に応じた判断基準

判断の出発点は「何を残し、何を変えたいか」を説明できることです。 そのためには、次の情報を一枚の資料にまとめると、複数の方式を条件付きで比較できます。

• 必要な機能：記事、検索、フォーム、予約、決済、会員、外部連携のうち、なくせないものと代替可能なもの。
• 更新の実態：ページ数、更新頻度、記事の承認手順、更新者の人数と技術、プレビューや予約公開の必要性。
• 運用・契約の体制：本体・拡張機能・サーバー・ドメイン・データ・障害対応を、誰がどの権限で管理するか。
• 費用と許容できる停止：制作・移行、日々の更新、継続保守、外部サービス、引き継ぎ費用と、停止できる時間。
• 移行で守りたい資産：既存URL、記事・画像、検索流入、問い合わせ履歴、将来の機能追加や別サービスへの移りやすさ。

以下は実在の顧客事例ではない仮定の例です。いずれも、条件が一つ合致しただけで方式を決定するものではありません。

その結果は、①WordPressを適切に保守して継続する、②必要な機能・契約だけを部分的に改善する、③CMSや業務処理と公開サイトを分離する、④別の構成へ全面移行するという複数の方向に整理できます。例えば現状の更新状況が分からないなら、先に第9章で現状を確認します。保守担当者が決まっていないなら、候補方式を問わず担当と契約範囲を明らかにする必要があります。URLやフォームの現状が不明なら、移行の影響を見積もる前に棚卸しを行います。

最も適した構成は、必要な機能を満たし、責任者が分かり、更新・障害・担当者交代に無理なく対応できる構成です。 情報が足りないときは、新しい技術へ急いで置き換えるのではなく、何を確認すれば比較できるかを明確にし、継続と移行の両方を候補に残しましょう。

関連する説明：現在の管理状態の確認／管理責任の分担／移行後も続く点検
この章の目次へ・全体の目次へ

第14章

企業サイトのセキュリティ管理チェックリスト

企業サイトのセキュリティ管理は、点検にチェックを付けて終える作業ではありません。 管理する対象を把握し、確認する人と時期を決め、確認結果に応じた作業を完了まで追いかけることが必要です。サイトが正常に表示されていることも、点検表がすべて埋まっていることも、安全性の証明にはなりません。

この章でわかること

• 最初に確認する項目
• 定期点検に入れる項目
• バックアップと復元可能性の確認
• 新たな脆弱性が公表されたときの確認
• 担当者・サーバー会社・制作会社の役割確認
• 確認できなかった項目の扱い

技術に詳しくない担当者が、PHPの設定やサーバーのログを自分で操作する必要はありません。一方で、「誰に何を聞き、どの回答や記録を根拠に、次に何を依頼するか」は整理できます。本章では、第9章の確認方法、第10章の更新・保守手順、第11章の防御策と管理責任、第12章の侵害時対応を、継続できる管理業務につなげます。出典：IPAの中小企業向けガイドライン・WordPressのセキュリティ指針

最初に確認する項目

最初は対策製品を増やすより、自社が管理すべきサイトと、その管理者を特定します。 同じ会社でも、本番サイトのほかに旧サイト、採用サイト、テスト環境、外部サービス上のフォームなどが残っている場合があります。サイト名だけでなく、対象URL、用途、公開・非公開の別、実際の契約者を記録してください。「以前使っていた」と「現在公開に使っている」は区別します。

管理対象は、次のまとまりで整理すると抜けを見つけやすくなります。

• 公開先と稼働構成：サイト・ドメイン・公開環境、使用中のWordPress本体とPHP、PHPの実行方式、Webサーバー、データベース、必要な独自プログラム。テーマとプラグインは、製品名、版、提供元に加え、有効化の表示と実際の利用・依存関係を分けて控えます。子テーマが使う親テーマは、有効化の表示だけで不要と判断しません。通常のプラグイン一覧だけでは把握しにくいMUプラグイン（常時使用するプラグイン）や、WordPressの特定の処理を置き換えるdrop-inなどの組み込みも、保守担当者に確認します。（出典：WordPress公式：子テーマ・プラグイン管理・サイトヘルス情報の分類）
• 契約と管理権限：サーバー、ドメイン、DNS、SSL/TLS証明書の契約・管理先と更新期限。WordPress等の管理者アカウント、サーバー管理画面、保守会社のアクセス範囲も対象です。管理者本人の確認と、日常の編集権限は分けます。
• 事業に必要な機能：問い合わせフォームと通知メール、予約・決済・会員機能、外部APIや埋め込みサービス。どこが入力を受け、どこへ情報が届き、誰がその設定と契約を管理するかを記録します。
• 記録と緊急対応：バックアップの対象・保存先・管理者、確認できるログの種類と保存期間、監視や通知の受信先。制作・保守・サーバー各社の担当範囲、緊急連絡先、停止や再公開を決める自社の責任者も確認します。

WordPressを使っていない場合、「WordPress本体・テーマ・プラグイン」は対象外です。ただし、静的サイトでも公開用の配信基盤、ドメイン、管理アカウント、フォーム、外部連携、バックアップなどは管理対象に残ります。反対に、WordPressの有無自体が分からない場合は「対象外」ではなく未確認とします。構成を判断する資料や権限がない場合は、納品資料・保守契約・正当な管理画面の情報をもとに、制作会社や保守担当者へ確認します。テーマ・プラグインの分類と確認場所は第9章を参照してください。出典：WordPress公式の権限説明・WordPress公式の管理指針

記録には最低限、対象・確認日・情報源・確認者・結果・次の担当と対応を残します。例えば「PHP 8.x」とだけ書くのではなく、どの公開環境について、いつ、どの管理画面やサーバー事業者の回答で確かめた版なのかを残します。最新版らしい数字を見つけただけでは、配布元によるセキュリティ修正の適用状況まで分かるとは限りません。また、パスワード・秘密鍵・復旧コードを、誰でも閲覧できる点検表に記載してはいけません。必要なのは秘密情報そのものではなく、誰が安全に保管し、必要時に利用できるかという管理情報です。出典：PHP公式の保守に関する案内・WordPress公式のセキュリティ指針

定期点検に入れる項目

定期点検では、初回に把握した状態から何が変わったかを調べます。 前回の表をコピーして同じ印を付けるだけでは、更新の失敗、保守終了、担当者交代、通知の停止などを見落とします。前回の確認結果に対して「変わっていないことを何で確かめたか」も残すのが基本です。

確認頻度をすべて「月1回」などにそろえる根拠はありません。対象の重要性、情報の更新頻度、公開している機能、既存の監視、委託契約、更新・修正に要する時間を踏まえて対象ごとに点検間隔と通知への対応方法を決めます。期限切れで公開停止につながる契約と、年に数回しか変更しない管理台帳とでは、適切な確認方法も異なります。自社が重要な情報を取り扱う場合や保守要員が限られる場合は、事業上の影響も含めて責任者が優先度を判断してください。出典：IPAの中小企業向けガイドライン

また、定期点検とは別に、担当者の退職・交代、拡張機能や外部サービスの追加、サーバー・DNS・認証方式の変更、保守契約の変更・終了をきっかけとする点検を設けます。誰かの権限を外すときは、その人が管理していたドメインやバックアップ、通知先も引き継ぐ必要があります。重大な脆弱性の公表や不審な動作は、次回の定期点検まで待たずに扱います。

点検記録には、実施日と次回確認予定のほか、何を見たか（管理画面、通知、契約書、担当者の回答など）、誰が確認したか、要対応の作業番号と期限、完了を示す根拠を記します。小規模な企業なら一つの共有管理表から始めて構いません。ただし、編集権限と閲覧範囲を定め、秘密情報や顧客データを表へ無制限に貼り付けないようにします。

バックアップと復元可能性の確認

バックアップの取得記録があることと、必要な時点のデータを、必要な範囲で戻せることは別です。 WordPressでは、一般に画像・テーマ・プラグインなどのファイルと、投稿・設定などを保存するデータベースの両方が復元に関係します。片方の保存だけでは、期待するサイト全体を再現できないことがあります。非WordPressの構成でも、公開ファイル、CMSのデータ、外部サービスに保存された内容は、それぞれ管理場所が異なります。出典：WordPress公式のバックアップ説明・ファイルのバックアップ・データベースのバックアップ

管理表では「バックアップあり」と一語で済ませず、取得対象、最終成功日時、保存世代・保持期間、保存場所、取得失敗時の通知先、閲覧・取り出し権限を確認します。保存場所が本番と同じ障害や不正アクセスの影響を受けないかも重要です。バックアップを別の場所へ保管していても、同じ認証情報ですべて削除できる構成なら、分離の実効性を確認する必要があります。取得ジョブが動いているという設定だけで、ファイルが取り出せることまで確認した扱いにしません。

復元可能性については、何を復元するか、復元に使う設定・認証情報と手順の所在、作業する人、事業側の承認者、検証できた範囲と日時を別に残します。復元試験を安全な検証環境で行ったことがあるなら、使用した世代、復元できたデータ・機能、失敗箇所、未確認の部分を報告から転記します。試験をしていなければ、そのまま「復元試験未実施」と記録してください。バックアップ一覧を開けたことを、復元成功とは書きません。試験場所と方法は構成に依存するため、安易に本番サイトへ上書き復元しないでください。出典：WordPress公式のバックアップ説明・NISTのインシデント対応指針

あわせて、「最終的に正常取得できたデータはいつの時点か」「それ以降に受け付けた問い合わせや注文をどう扱うか」を責任者と確認します。これは復旧可能な時点の見込みであり、記録だけから確実な復旧を保証するものではありません。復元にかかる時間、外部サービスのデータやメールが含まれるかも、試験・契約・運用記録で確認できた範囲に限定して判断します。

改ざん・侵害の疑いがある場合は、バックアップの中にも不正な変更が含まれる可能性があります。世代が古いことだけを理由に安全とは判断せず、第12章に沿って被害拡大防止・証拠保全・原因調査と復元データの信頼性確認を優先します。更新・復元作業の計画と検証方法は第10章で説明しています。

新たな脆弱性が公表されたときの確認

重大な脆弱性が公表されたときは、定期点検とは別に、影響の有無と対応の緊急度を判断します。 製品に脆弱性があること、自社が攻撃を受け得る構成であること、攻撃の試行が観測されていること、実際に侵害されたことは、それぞれ異なります。公表されたCVE番号や「緊急」という見出しだけで、自社の侵害を断定してはいけません。情報の区別は第4章の脆弱性と攻撃の関係も参照してください。公的な注意喚起は、開発元が示す対策を見つけて照合する入口として活用します。出典：JPCERT/CCの脆弱性情報提供

臨時確認では、次の順序で判断の根拠と未確定事項を記録します。

1. 情報源を確認する：製品開発元・配布元の公式アドバイザリや修正案内を優先し、必要に応じてJVN、JPCERT/CC、IPA等の公的情報と照合する。情報の確認日時、URL、公表日・更新日を区別して控える。
2. 適用条件を読む：対象製品、影響するバージョン、実行方式、利用中の機能、外部からの到達経路、必要な認証・権限などを整理する。「製品名が一致した」だけでは影響を確定しない。
3. 自社の記録と突き合わせる：対象サイト・公開環境、現在版、実際の構成、ホスト事業者による修正適用情報を照合する。製品の表示版と、配布元が別途適用した修正の有無も分けて確認する。
4. 提供元の対処を確認する：修正版、配布元パッチ、回避策、公開機能の制限など、正式に案内されている選択肢と条件を調べる。WAF等の暫定策を恒久的な修正と同一視しない。
5. 不明点を担当者へ依頼する：影響の判断に必要な版、実行方式、契約上の更新担当が分からなければ、「不明な項目・照合した公式情報・回答が必要な時点」を明記して保守会社や提供元に確認する。
6. 対応を決定・記録する：悪用の状況、外部への公開範囲、取り扱う情報、業務への影響、対処可能性を踏まえて優先度を決め、判断責任者、実施者、予定・暫定対応・未解決事項を残す。
7. 実施後に確かめる：修正の適用記録、設定・機能の確認結果、残った課題を記録し、担当者へ引き継ぐ。更新を伴う場合は第10章の安全な更新工程に従う。

脆弱性情報を読むときは、影響する製品・版、成立条件、修正・回避策、その説明元を別々に整理します。公的な情報提供を入口にしても、同じ製品の情報が後から更新される場合があるため、製品開発元や配布元の最新の説明へ戻って照合します。情報が取得できない場合は確認済みとせず、確認できた資料と不足する条件を担当者へ伝えます。PHPやWordPressの特定の脆弱性の詳細は第7章と第8章を参照してください。出典：JPCERT/CCの脆弱性情報提供・PHP公式の更新に関する説明

悪用が現実に観測され、影響する公開機能があるなど、判断を急ぐ事情があれば通常の点検日を待ちません。一方、影響が未確認という状態も、直ちに侵害された証拠ではありません。 不審な転送や未知の管理者など、すでに侵害を疑う兆候がある場合には、通常の更新作業を先行させず第12章の初動対応に切り替えます。出典：NISTのインシデント対応指針

担当者・サーバー会社・制作会社の役割確認

画像を拡大する ＋

「契約先がある」ことと「必要な作業を引き受けてもらえる」ことは同じではありません。 サーバー事業者が基盤の管理を行っていても、WordPress本体・プラグイン・独自コードの更新まで含むとは限りません。制作会社へサイト制作を依頼していても、納品後の保守、バックアップの復元、緊急調査が契約に含まれない場合があります。サービス形態と契約内容に沿って一件ずつ確かめます。出典：WordPress公式のセキュリティ管理指針・IPAの中小企業向けガイドライン

確認したいのは、会社名の一覧だけではなく、誰が状況を確認し、誰が変更を実施し、誰が費用や業務停止を承認するかです。自社のサイト運営責任者、社内更新担当、サーバー事業者、制作・保守会社、ドメイン・DNS管理者、フォーム・メール等のサービス提供元を整理し、各人が担当する公開環境と権限を明記します。委託先の回答があっても、事業上の停止・再公開や顧客対応の意思決定は自社の責任者と分けておきます。

特に、WordPress・PHP・Webサーバーの更新、認証・権限変更、バックアップの取得と復元、ログの保存と調査、障害・侵害の初動について、契約に含まれる範囲、依頼方法、対応可能な時間帯、緊急時の連絡方法、追加費用の条件、代替連絡先を確認します。「問い合わせ窓口がある」ことは、「深夜の緊急作業が保証される」ことを意味するとは限りません。外部委託先が複数ある場合には、一方の回答待ちで作業が止まらないよう、判断を引き継ぐ窓口も決めます。

契約や担当が変わったときは、管理表だけでなく実際のアカウント権限、更新通知の送信先、バックアップのアクセス権、ドメインの更新連絡先も照合します。退職者・旧委託先の権限を見直す作業は、正当な権限者の承認と手順に沿って実施してください。責任分担の一般的な例は第11章で扱いましたが、ここでは自社の契約と作業の分担を確認し、変更時に更新することが目的です。

確認できなかった項目の扱い

確認できなかった項目は、空欄のままにせず「何を確かめれば判断できるか」を次の作業として残します。 情報不足は、それだけで危険を証明するものでも、問題がないことを意味するものでもありません。「分からなかった理由」と「回答を得る先」があれば、担当者が交代しても管理を続けられます。

確認できたかどうかと、作業が必要か・終わったかは、別の軸で記録します。 問題を確認できた項目を「確認済み」と書いても、それだけで対処済みとはならないためです。第9章の現状確認と同じ二軸を使います。

• 確認状態は「確認済み／未確認／対象外」。確認済みには対象・確認日・根拠を付けます。未確認には情報不足、権限不足、回答待ち、試験未実施などの理由を残します。対象外も、構成や契約に当てはまらない根拠が必要です。
• 対応状態は「対応不要／要対応／対応中／完了」。必要な作業が明らかなら要対応、依頼や作業を進めているなら対応中、定めた作業と確認を終えたなら完了とします。作業の担当・期限・結果を記録します。完了は、その作業の完了であり、サイト全体の安全性の認定ではありません。

例えば、必要な修正が未適用だと公式情報と稼働版で確認できた場合は、「確認：確認済み／対応：要対応」です。バックアップの対象や最終成功日をサーバー会社へ問い合わせて回答待ちなら、「確認：未確認／対応：対応中」とし、問い合わせ中であることと復元可能性が分かったことを分けます。一般利用者向けの会員登録機能がないと確認できたサイトでは、その機能の点検を「確認：対象外／対応：対応不要」とできますが、WordPress管理者のログインまで対象外になるわけではありません。いずれも記録のための仮定の例です。

例えば「バックアップはサーバー会社が管理していると聞いたが、対象データと最終成功日は未回答」という場合、復元できることまで確認済みにはできません。記録には、確認したい情報、確認できなかった理由、問い合わせ先、依頼日、回答を求める時期、返答がないときの再連絡・責任者への相談先を書きます。回答内容が曖昧なら、対象環境や対象期間を明示して追加で尋ねます。

確認期限は一律に決めず、起きた場合の影響、公開範囲、悪用情報、業務継続への重要性をもとに判断します。重大な脆弱性への該当が不明な場合には、通常の確認待ちとして放置せず、保守担当者や提供元への優先確認、必要に応じた責任者による暫定的な制限の判断へ進みます。逆に「未確認」と書かれただけで、停止や全面移行を自動的に決めるのも適切ではありません。出典：JPCERT/CCの脆弱性情報提供・IPAの中小企業向けガイドライン

以下は表T14｜セキュリティ管理チェックリストです。初回の整理、定期的な見直し、構成や人員の変更時、脆弱性公表時の臨時確認を区別しています。これは各社が記入して使うひな型であり、表の空欄は点検済みを意味しません。「結果」には「確認：確認済み／対応：要対応」のように二軸を併記し、根拠、具体的な確認日時、担当者名、期限、完了記録は表に紐付けた管理メモに残してください。一つの行に確認済み部分と未確認部分が混在する場合は、管理メモで対象を分け、行全体を一括して確認済みにしないようにします。「担当」は確認責任を負う人・組織の例であり、実際の作業担当が別なら併記します。未契約・未確定の場合は責任者が確認先を決めます。

表の中を横にスクロールできます。枠にフォーカスすると方向キーでも移動できます。

点検表の「確認済み」は、その項目について何を確かめたかの記録であって、サイト全体の安全を保証するものではありません。また、監視や点検の間に新しい問題が発生する可能性があるため、点検頻度を決めるだけで重大な脆弱性や侵害を見逃さないとはいえません。次回も同じ表を更新し、未確認・要対応の項目を担当者と期限付きで追跡し、完了した根拠を残すことが継続管理の中心です。

WordPressやPHPの更新状況、管理状態がわからない場合は、WordPress無料診断からご相談いただけます。

関連する説明：具体的な確認方法／更新作業の準備／異常発見時の連絡
この章の目次へ・全体の目次へ

第15章

WordPress・PHPのセキュリティに関するよくある質問

この章でわかること

• WordPressは使わない方が安全ですか？
• PHPを更新すればWordPressも安全になりますか？
• WordPress本体の自動更新だけで十分ですか？
• セキュリティプラグインを入れれば大丈夫ですか？
• WAFやHTTPSがあれば攻撃を防げますか？
• 管理画面URLの変更には効果がありますか？
• 長期間更新していなくても表示が正常なら大丈夫ですか？
• 企業規模が小さくても攻撃されますか？
• PHP2Shellとwp2shellは同じ問題ですか？
• バックアップがあれば侵害前に戻せますか？
• サーバー会社に任せれば自社での確認は不要ですか？
• 自社サイトが侵害されているか外部から判断できますか？

WordPressは使わない方が安全ですか？

いいえ、WordPressを使わない方が必ず安全になるわけではありません。必要な機能と保守体制が整っていれば、WordPressを継続することは合理的な選択です。一方、別の構成に移しても管理アカウントや外部サービスなどのリスクは残ります。防御策の考え方は第11章の対策を組み合わせる理由、継続と移行の判断基準は第13章の継続・移行の判断で説明しています。出典：WordPress公式のセキュリティ指針

PHPを更新すればWordPressも安全になりますか？

いいえ、PHPの更新だけではWordPress全体の安全性は確保できません。PHPはサーバー側の実行環境で、WordPress本体、テーマ、プラグインとは修正対象が異なります。各製品の更新状況と互換性を別々に確認する必要があります。仕組みは第2章のPHPの役割、更新の進め方は第10章の更新対象の区別を参照してください。出典：WordPress公式のPHP更新案内

WordPress本体の自動更新だけで十分ですか？

いいえ、WordPress本体の自動更新だけでは十分ではありません。テーマやプラグイン、PHP、管理アカウント、バックアップも確認が必要です。また、自動更新を有効にしていても、実際に適用が成功したとは限りません。確認項目は第9章のテーマ・プラグインと自動更新の確認、更新後の検証は第10章の更新後の動作確認で扱っています。出典：WordPress公式の更新手順

セキュリティプラグインを入れれば大丈夫ですか？

いいえ、セキュリティプラグインの導入だけで安全を保証することはできません。ログイン保護や監視などに役立つ機能はありますが、設定と運用が必要で、プラグイン自体の更新も欠かせません。未修正のPHPやWordPressの問題を、導入しただけで解消できるわけではありません。対策を組み合わせる理由は第11章の対策を組み合わせる理由で説明しています。出典：WordPress公式のセキュリティ指針

WAFやHTTPSがあれば攻撃を防げますか？

いいえ、WAFやHTTPSですべての攻撃を防げるわけではありません。WAFは一定の不審なWeb通信を検知・遮断できますが、ルールや構成によっては防げない攻撃があります。HTTPSは主に通信経路を保護するもので、PHPやWordPressの脆弱性そのものを修正しません。詳しくは第11章のWAFの効果と限界とHTTPS・Cookieの保護を参照してください。出典：OWASPの仮想パッチ解説・OWASPのTLS解説

管理画面URLの変更には効果がありますか？

一定の効果は期待できますが、主要な防御策の代わりにはなりません。標準のログイン画面を探す機械的なアクセスを減らせる場合がある一方、URLの変更は本人確認や権限管理を強化する仕組みではありません。別の公開機能や未修正の脆弱性にも対処が必要です。対策の位置付けは第11章のログインURL等の対策の位置付けで確認できます。出典：WordPress公式のセキュリティ指針

長期間更新していなくても表示が正常なら大丈夫ですか？

いいえ、問題なく表示されていても、安全とは判断できません。脆弱性や不審な変更が画面に現れないこともあり、更新が止まっている理由や修正の適用状況を別に確かめる必要があります。最初の判断は第1章の最初に取る行動、確認する項目は第9章の稼働版の確認、継続的な管理は第14章の定期的な点検にまとめています。出典：PHP公式の継続更新指針

企業規模が小さくても攻撃されますか？

はい、小規模な企業や店舗のサイトも攻撃対象になり得ます。攻撃者は会社の知名度だけでなく、自動探索で見つけた公開機能や、サイトを不正ページの設置先などに使えるかを重視する場合があります。ただし、探索されたことと侵害されたことは別です。理由と起こり得る被害は第6章の攻撃対象を探す仕組みで説明しています。出典：MITRE ATT&CKの自動探索に関する説明

PHP2Shellとwp2shellは同じ問題ですか？

いいえ、名前は似ていますが、原因も修正対象も異なります。PHP2Shellは2026年10月に公表されたPHP本体の2件の脆弱性を指し、wp2shellは同年7月に公表されたWordPress本体の2件を組み合わせる問題です。どちらも対象バージョンや実行環境などの条件を確認する必要があり、PHPの更新とWordPress本体の更新を混同してはいけません。前者は第7章のPHP2Shell、後者は第8章のwp2shellで扱っています。出典：PHP開発元のアドバイザリ・WordPress開発元のアドバイザリ

バックアップがあれば侵害前に戻せますか？

バックアップがあっても、侵害前の安全な状態へ戻せるとは限りません。ファイルとデータベースが必要な時点で揃っているか、復元できるかに加え、バックアップ自体に不正な変更が含まれていないかを確認する必要があります。侵害が疑われる場合は、原因調査や証拠保全を飛ばして上書き復元しないことも重要です。復元の準備は第10章のバックアップと復元確認、侵害時の判断は第12章の初動対応、継続的な確認は第14章の復元可能性の点検を参照してください。出典：WordPress公式のバックアップ案内・NISTのインシデント対応指針

サーバー会社に任せれば自社での確認は不要ですか？

いいえ、サーバー会社に委託していても、自社で責任範囲を確認する必要があります。PHPやサーバー基盤の更新、WordPress本体・拡張機能の保守、監視や復旧の担当は、契約内容や提供形態によって異なります。何が委託範囲に含まれ、誰が対応結果を確認するかを明確にしてください。役割の分け方は第11章の管理責任の分担、管理項目は第14章の委託先との分担確認で説明しています。出典：WordPress公式のセキュリティ指針

自社サイトが侵害されているか外部から判断できますか？

外部から見える情報だけでは、侵害がないことや、被害の全範囲・原因を確認することはできません。ただし、不正な転送やページなど、特定の異常を裏付ける情報が見つかる場合はあります。正常に表示されることは、侵害がない証明にはなりません。管理権限に応じたログ・ファイル・アカウントなどの調査と照合し、確認できた事実と未確認の部分を分けて判断します。外部情報の限界は第9章の外部からの観察の限界、疑わしい場合の対応は第12章の初動対応を参照してください。出典：WordPress公式の侵害対応案内

関連する説明：状況に応じた最初の判断／自社サイトの確認／侵害が疑われる場合
この章の目次へ・全体の目次へ