WordPressの開発チームは、2026年7月17日（米国時間）、複数のセキュリティ問題を修正した「WordPress 7.0.2」を公開しました。深刻度が高いため、対象となるバージョンには自動更新も適用されています。
ただし、更新されたことと、サイトが安全であることは同じではありません。修正版を適用することで、今回の脆弱性を悪用した新たな攻撃への対策になります。一方、更新前にすでに侵入や改ざんを受けていた場合、更新だけでは不正なファイルやアカウントなどが残る可能性があります。
そのため更新後は、修正版が適用されているかを確認するだけでなく、更新前に不正アクセスや改ざんの痕跡が残っていないかまで確認することが大切です。とはいえ、この確認は項目が多く、判断に迷う場面もあります。
この記事では、今回のセキュリティ更新で修正された脆弱性の一つ、CVE-2026-63030（通称wp2shell）を例に、当社が実際の運用の現場で使っている確認フローを紹介します。どこまでを自社で確認でき、どこからは専門的な確認が必要になるのか、その目安としてもお使いください。
– index –
wp2shell（CVE-2026-63030）とは
WordPress 7.0.2は、2件の脆弱性（CVE-2026-60137とCVE-2026-63030）を修正したセキュリティリリースです。このうち、通称wp2shellと呼ばれるのがCVE-2026-63030です。この記事では、更新後の確認という観点から、主にこのCVE-2026-63030を例に説明します。
CVE-2026-63030は、WordPress 6.9.5未満の6.9系と、7.0.2未満の7.0系が対象の脆弱性です。6.9系の利用者は6.9.5へ、7.0系の利用者は7.0.2へ更新することで、修正が適用されます。この対象範囲は、NVD（米国国立標準技術研究所が運営する脆弱性データベース）とWordPress公式リリースの記載と一致しています。
技術的には、REST API（外部のプログラムからWordPressを操作するための仕組み）におけるリクエストの取り扱いの問題が、別の脆弱性と組み合わさることで、データベースへの不正な操作や、リモートからのコード実行につながりうる、というものです。攻撃の詳しい手順はここでは扱いません。管理者にとって重要なのは、自サイトが対象バージョンかどうかと、更新後の状態を確認することです。
WordPress公式は、7.0.2を、重大な問題1件と深刻度の高い問題1件を修正するセキュリティリリースと位置づけ、速やかな更新を推奨しています。ここで押さえておきたいのは、公表されている事実の範囲で判断することです。攻撃がどの程度発生しているかといった件数を、根拠なく語ることは避けます。一方で、公式が速やかな更新を推奨し、対象バージョンに自動更新を適用したこと、そして更新だけでは更新前の改ざんや侵害の有無までは判断できないことを踏まえると、更新後に痕跡を確認しておくことには意味があります。
最初に確認すべきこと
最初に確認するのは、自サイトのWordPressバージョンです。WordPress管理画面のダッシュボードや、管理画面フッターに表示されるバージョン情報で、修正版（6.9系なら6.9.5以降、7.0系なら7.0.2以降）になっているかを確認します。自動更新が有効な場合でも、実際に修正版へ更新されているかを必ず確認してください。
次に、そのサイトの運用形態を把握します。ここで確認しておきたいのは、次の3点です。
- Webサーバーの生アクセスログを、自分で参照できるか
- WAF（不正な通信を遮断する仕組み）やセキュリティプラグインを導入しているか
- バックアップがどこまで遡って残っているか
この3点の把握が、後で述べるユーザーやログの確認で、どこまで踏み込めるかを左右します。逆に言えば、この時点で「自社では確認できない範囲」が見えてくることもあります。
そのうえで、更新前の期間に不正な変更が加えられていないかを確認します。脆弱性が修正されたのは更新後ですが、更新前に攻撃を受けていたかどうかは、更新しただけでは判断できません。だからこそ、更新済みであっても状態の確認が必要になります。
当社が実施した確認フロー
ここからは、当社が対象サイトに対して用いている確認フローの考え方を紹介します。個別のサイトの結果はここでは示しません。あくまで、何を、どの順序で確認するのか、という手順として一般化しています。
前提として、今回の自動更新はWordPress.org側で有効化されたものです。当社では、各サイトについて、修正版が正しく適用されているか、サイトが正常に動作しているか、そしてセキュリティ上の異常がないかを確認しました。この役割の切り分けを明確にしておくことが、正確な報告と、その後の判断につながります。
対応の全体像
修正版・ファイルを確認
ユーザー・ログを確認
状態を記録し、運用を継続
下記の対応へ進む
侵害対応を検討
STEP1
セキュリティ修正版の適用確認およびファイルの整合性・改ざん確認
WordPress本体に修正版が適用されているかを確認します。WordPress管理画面のダッシュボードや、管理画面フッターに表示されるバージョン情報を目視で確認し、修正版が適用されたバージョンであることを確認します。
続いて、各WordPressコアファイル（本体を構成するプログラム）のチェックサムが、WordPress公式で公開されているものと一致するかを確認し、書き換えられたファイルや、本来存在しないはずのコアファイルが存在しないかを調査します。チェックサムとは、ファイルの内容から計算される照合用の値で、内容が1文字でも変わると値が変わります。これを公式の値と突き合わせることで、バージョン表記だけでは分からない、ファイル単位の書き換えを見つけられます。バージョンの確認とこの整合性の確認をあわせて行うことが、当社の確認の起点です。
あわせて、アップロード用ディレクトリ（uploads。画像などの保存先）の中に、見覚えのないPHPファイルがないかを確認します。PHPファイルが見つかった場合は、正規のプラグインや既存の機能によるものかどうかを含めて、個別に内容を確認します。そのうえで不審なPHPファイルであると判断された場合は、侵害の可能性を示す重要な兆候として扱います。
この「正規のものか、不審なものか」の切り分けには、経験が必要になる場面があります。整合性チェックのツールは、正規のプラグインでも「見覚えのないファイル」として検出することがあり、検出結果をそのまま危険と判断すると、過剰反応につながるためです。コアファイルの改ざんや未知のコアファイルは重大な兆候として扱う一方、コア直下などの検出は内容を確認してから判断する、という見極めが求められます。
STEP2
ユーザー・ログ・cron・WAFの確認
ファイルの確認と並行して、サイトの状態を別の角度から確認します。まず、管理者権限のユーザー一覧を確認し、不審なアカウントが追加されていないかを確認します。
次に、アクセスログを確認します。今回の脆弱性はREST APIを経由するため、REST APIに対する不審なリクエストがないかを確認します。ここで注意したいのは、アクセス解析ツール（Google Analyticsなど）と、Webサーバーの生アクセスログは別物だという点です。解析ツールはページの閲覧数を集計するもので、攻撃リクエストの多くはそこに記録されません。攻撃の痕跡を追うには、サーバーが記録する生のアクセスログを確認する必要があります。そして、大量のログの中から不審なリクエストを見分けるには、通常のアクセスとの違いを判断する目が必要になります。
さらに、WordPressのcron（時刻を指定して処理を自動実行する仕組み）に、見覚えのないタスクが登録されていないかを確認します。WAFやセキュリティプラグインを導入している場合は、そのブロックログに攻撃の痕跡がないかもあわせて確認します。
STEP3
侵害が疑われる場合の対応
STEP1やSTEP2で不審な兆候が見つかり、侵害が疑われる場合には、次の対応を検討します。全ユーザーのパスワードの再設定、認証に使われるキーとソルト（wp-config.phpに記載される認証用の文字列）の再発行、そして必要に応じて、侵害前のクリーンなバックアップからの復旧です。これらは、認証情報が漏えいした前提で被害の拡大を防ぐための手当てです。侵害の兆候が確認された場合に実施を検討します。どこまで対応するかの判断は影響が大きいため、慎重に見極める必要があります。
自動更新されていれば何もしなくてよいのか
自動更新が有効だったから何もしなくてよい、とは言えません。自動更新で確認できるのは、主にWordPress本体が修正版へ更新されたことです。サイト全体に侵害や改ざんがないことまで保証するものではありません。更新前に攻撃を受けていた場合、その痕跡や、攻撃者が残した不正なファイルやアカウントなどは、通常の更新だけでは取り除かれない可能性があります。
だからこそ、更新後にファイル、ユーザー、ログを確認します。確認した範囲で不審な兆候が見つからなければ、侵害の可能性を評価するための材料になります。ただし、この確認はサイトごとに行うものであり、更新済みだからすべてのサイトが侵害されていない、と一律に断定することはできません。確認できる範囲で状態を把握し、確認できない部分は、次に述べる方法で補います。
サーバーのアクセスログを確認できない場合
利用しているサービスによっては、Webサーバーの生アクセスログを、管理者側で参照できないことがあります。共用のレンタルサーバーや、一部のマネージド型サービスでは、ログの提供範囲が限られている場合があります。
この場合は、サーバー事業者やホスティングの提供元に、該当する期間のアクセスログを確認できるか、あるいは提供してもらえるかを問い合わせます。ログを確認できないまま「問題なし」と結論づけることはできません。確認できないという事実を認識したうえで、事業者への問い合わせという手段で補うのが、正しい進め方です。事業者とのやり取りや、受け取ったログの読み取りに不安がある場合は、運用を担う会社に間に入ってもらうと、確認がスムーズに進みます。
今後のWordPress運用で必要なこと
今回のような事案を踏まえると、日常の運用で押さえておきたい点がいくつかあります。まず、自動更新は有効のままにし、今後のセキュリティリリースも継続して適用することです。WAFは有効な緩和策ですが、あくまで被害を抑えるための手段であり、根本的な対処はプログラムの更新です。
次に、更新の適用確認とあわせて、動作確認と状態確認を習慣づけることです。更新が適用された事実を確認するだけで終えず、サイトが正しく動いているか、不審な変更が入っていないかまでを、一連の作業として組み込みます。
最後に、いざというときに、ファイルの整合性確認、ユーザー確認、ログ確認を実施できる体制を用意しておくことです。ファイルの確認だけでは十分ではなく、データベースやユーザー、ログの確認とあわせて行う、という考え方を運用に反映しておくと、次の事案への初動が速くなります。こうした体制を社内だけで維持するのが難しい場合は、保守契約という形で外部に任せる選択肢もあります。
まとめ
CVE-2026-63030（wp2shell）への対応は、バージョンの確認から始まります。そのうえで、更新前に不正な変更が加えられていなかったかを、ファイル、データベース、アクセスログの3つの角度から確認します。自動更新の適用確認は出発点であって、調査の完了ではありません。アクセスログを確認できないサービスでは、サーバー事業者への問い合わせが必要であり、確認できないまま安全だと結論づけることはできません。更新済みであっても、状態を確認したうえで判断する、という姿勢が要点です。
そして今回見てきたように、確認の一部には、チェックサムによる整合性の照合や検出結果の切り分け、ログの読み取りなど、判断に経験を要する場面があります。自社だけで進めて迷ったときに、相談できる相手を持っておくことも、有効な備えの一つです。
WordPressの保守やセキュリティ確認でお困りの方へ
修正版が正しく適用されているか。更新前に改ざんや不正アクセスの痕跡がないか。そもそも、自社の環境で生ログをどう確認すればよいのか。こうした確認は、いざ着手すると、専門的な知識や権限が必要になる場面が少なくありません。
「自動更新はされたようだが、これで大丈夫なのか判断がつかない」「確認しておきたいが、社内に見られる人がいない」という場合は、無理に自社だけで抱え込まず、一度ご相談ください。当社では、サイトの構成や運用の状況をうかがったうえで、今回のような脆弱性への確認をご案内します。あわせて、保守体制そのものの見直しや、既存サイトの改修、Webサイトのリニューアルまで、状況に応じてご相談いただけます。
WordPressの保守・改修・Webサイト制作について相談する
よくある質問
Q. 自動更新でWordPressが7.0.2になっていれば、もう対応は不要ですか？
A. バージョンが修正版になったことは、確認の出発点です。それだけで調査完了とは言えません。更新前の期間に不正な変更が加えられていないかを確認しておく必要があります。
Q. アクセス解析を見れば、攻撃されたか分かりますか？
A. アクセス解析ツール（Google Analyticsなど）と、Webサーバーの生アクセスログは別物です。解析ツールはページの閲覧数を集計するもので、攻撃リクエストの多くは記録されません。攻撃の痕跡を追うには、サーバーが記録する生のアクセスログを確認します。
Q. 生アクセスログを自分で見られない場合はどうすればよいですか？
A. サーバー事業者やホスティングの提供元に、該当する期間のログを確認できるか、提供してもらえるかを問い合わせてください。ログを確認できないまま「問題なし」と結論づけることはできません。読み取りや事業者とのやり取りに不安がある場合は、保守会社に間に入ってもらう方法もあります。
Q. 対象のバージョンはどれですか？
A. CVE-2026-63030は、6.9.5未満の6.9系と、7.0.2未満の7.0系が対象です。6.9系は6.9.5へ、7.0系は7.0.2へ更新することで修正が適用されます。これはNVDとWordPress公式の記載に基づいています。
Q. WAFを入れていれば安全ですか？
A. WAFは有効な緩和策ですが、あくまで被害を抑えるための手段であり、根本的な対処ではありません。根本的な対処はプログラムの更新です。自動更新は有効のままにし、今後のリリースも継続して適用してください。
