WordPress本体の脆弱性「wp2shell」に注意|対象バージョンと必要な対応

2026年7月、WordPress本体に関する重大な脆弱性が公表されました。

今回の脆弱性では、対象バージョンを利用している場合、WordPressへログインするための認証情報を持たない第三者によって、遠隔から不正なコードを実行される可能性があります。脆弱性を実証するコードが公開され、実際の攻撃での悪用も確認されているため、WordPressを利用している場合は、現在のバージョンとアップデート状況の確認が必要です。

特に、上場企業、大学、官公庁など、複数の部門や委託先がWebサイトを管理している組織では、組織のメインサイトだけを確認すると、部門サイトや旧サイトなどへの対応が漏れる可能性があります。IR、採用、入試、研究、防災、住民向け情報などを発信する個別サイトや、旧サイト、検証環境も含めた確認が必要です。

また、修正版へアップデートすることと、アップデート前に不正アクセスや改ざんを受けていないか確認することは、別の対応です。

本記事では、今回の脆弱性の概要、対象バージョン、確認対象となるWordPress環境、アップデート時の対応、不審な変更やアクセスの確認、関係者の役割分担を整理します。

WordPress本体の脆弱性「wp2shell」とは

WordPress公式は2026年7月17日、セキュリティ上の問題を修正したWordPress 7.0.2を公開しました。あわせて、WordPress 6.9系向けの6.9.5と、6.8系向けの6.8.6も公開されています。

修正版の内容や対象バージョンについては、WordPress公式の「WordPress 7.0.2 リリース」で確認できます。

IPAも2026年7月22日、「WordPressの脆弱性対策について」として注意喚起を公開し、対象バージョンを利用しているWebサイトに対して、直ちにアップデートすることを推奨しています。

今回公表されたのは、以下の2件の脆弱性です。

  • CVE-2026-60137:データベースを不正に操作される可能性がある、SQLインジェクションの脆弱性
  • CVE-2026-63030:WordPressのREST APIによる一括処理に関する脆弱性

CVEは、公開された脆弱性を識別するために付けられる番号です。

WordPress 6.9以降では、この2件を組み合わせることで、認証情報を持たない第三者が遠隔から不正なコードを実行できる可能性があります。この攻撃手法は「wp2shell」と呼ばれています。

特定のプラグインやテーマを使っている場合だけの問題ではなく、それらを使っていないWordPress環境でも影響を受ける可能性があります。

想定される影響

今回の脆弱性を悪用された場合、次のような影響が考えられます。

  • データベース内の情報を取得される
  • 不正な管理者アカウントを作成される
  • 不正なプラグインやファイルを設置される
  • Webサイトを改ざんされる
  • サーバー上で不正なコードを実行される

WordPressサーバーが組織内のシステムやデータベースへ接続できる構成では、攻撃が成功した場合の影響がWordPressサイト内だけにとどまらない可能性もあります。

対象バージョンと修正版

影響を受けるバージョンと修正版は、以下のとおりです。

利用中のバージョン主な影響修正版
WordPress 6.8.0~6.8.5SQLインジェクション6.8.6以降
WordPress 6.9.0~6.9.4遠隔コード実行の可能性6.9.5以降
WordPress 7.0.0~7.0.1遠隔コード実行の可能性7.0.2以降

WordPress 6.8より前のバージョンは、今回公表された対象バージョンには含まれていません。ただし、古いバージョンには、今回とは別の既知の脆弱性が残っている可能性があります。

「今回の対象外である」という理由だけで、古いバージョンをそのまま利用し続けることは推奨できません。

実際の悪用が確認されている

今回の脆弱性は、将来悪用される可能性があるという段階ではなく、すでに悪用が確認されています。

2026年7月21日には、米国CISAが管理する「悪用が確認された脆弱性一覧(KEV)」に2件とも登録されました。IPAも、脆弱性を実証するコードが公開されており、悪用が拡大する可能性があると注意を促しています。

WordPress公式は、影響を受けるバージョンに対してセキュリティ自動更新を有効化しています。ただし、環境や設定によっては、自動更新が無効になっていたり、アップデートに失敗していたりする可能性があります。

自動更新の設定だけで判断せず、WordPressの管理画面などから、実際に修正版以降へアップデートされているかを確認してください。

管理対象のWordPressとアップデート状況を確認する

複数のWebサイトを運用している組織では、メインサイトが修正版へアップデートされていても、別のWordPress環境が対象バージョンのまま公開されている可能性があります。

最初に、組織内で管理しているWordPress環境を洗い出します。

確認対象には、次のようなサイトや環境を含めます。

  • 組織のメインサイト
  • 採用、IR、入試、研究、観光、防災、イベントなどの個別サイト
  • サブドメインや部門別に運用しているサイト
  • 更新を停止した旧サイトや閉鎖予定のサイト
  • ステージング環境や検証環境
  • Webサイト制作会社や外部事業者が管理しているサイト
  • WordPressのマルチサイト機能で運用している環境

例えば、上場企業ではIR・採用・グループ会社のサイト、大学では学部・研究室・入試サイト、官公庁では防災・観光・申請案内などの個別サイトが、メインサイトとは別に管理されている場合があります。

管理部門や委託先が異なるサイトも含め、組織全体で確認することが重要です。

旧サイトや検証環境であっても、インターネットからアクセスできる状態であれば、確認対象から外すべきではありません。

サイトごとに、以下を整理します。

確認項目確認する内容
WordPressの利用有無対象サイトがWordPressで構築されているか
現在のバージョン修正版以降へアップデートされているか
公開状態インターネットからアクセスできるか
公開期間修正版の公開後も対象バージョンで公開していたか
管理担当どの部門がサイトを管理しているか
委託先制作・CMS保守・サーバー運用を誰に委託しているか
契約範囲WordPressのアップデートが保守契約に含まれるか

組織内の管理台帳だけで対象サイトを把握できない場合は、情報システム部門、Webサイト制作会社、CMS保守会社、サーバー運用会社にも確認します。

CMS保守の契約範囲と対応体制を確認する

WordPressの脆弱性対応は、Web担当者だけでは完結しない場合があります。

Webサイト制作会社、CMS保守会社、サーバー運用会社など、複数の事業者が関わっている場合は、アップデート作業を始める前に、それぞれが何を担当する契約なのかを確認します。

一般的な役割分担の目安は、以下のとおりです。

確認・対応内容主な相談先
WordPress本体・プラグインのアップデートCMS保守会社・Webサイト制作会社
アップデート後の表示・機能確認Web担当部門・Webサイト制作会社
サーバー・WAF・アクセスログの確認サーバー運用会社
不具合や異常の原因切り分けCMS保守会社・Webサイト制作会社・サーバー運用会社の連携

WAFは「Webアプリケーションファイアウォール」の略で、Webサイトへの攻撃通信を検知・遮断する仕組みです。

実際の担当範囲は、契約によって異なります。

少なくとも、次の内容を誰が担当するのか確認してください。

  • 脆弱性情報の確認と案内
  • WordPress本体・プラグインのアップデート
  • 検証環境の用意
  • アップデート前のバックアップ
  • アップデート後の表示・機能確認
  • サーバーやアクセスログの確認
  • 不具合や異常が起きた場合の原因切り分け
  • 緊急時の連絡先と連絡方法

委託先にアップデート作業を依頼する場合も、発注側で対象サイト、実施日時、アップデート前後のバージョン、動作確認結果を確認できるようにします。

複数のサイトや委託先がある組織では、「対応済み」という報告だけでなく、どの環境に、いつ、どのような対応を行ったのかを記録することが重要です。

組織内でも、対象サイトを取りまとめる担当、本番環境へのアップデートを承認する担当、異常が見つかった場合の報告先を決めておく必要があります。

クロジカが支援できること

クロジカでは、契約内容やご利用環境に応じて、以下のような対応を行っています。

  • CMSの脆弱性情報やセキュリティアップデート情報の提供
  • 重大な脆弱性が発生した場合のWordPress本体・プラグインのアップデート
  • 必要に応じた検証環境の構築
  • CMSに異常がある場合のログ調査
  • ログ調査結果を踏まえた対応方針の案内
  • CMSに関するお問い合わせ対応

WordPressのカスタマイズ状況や現在の契約内容によって、対応できる範囲は異なります。まずは利用環境と保守範囲を確認したうえで、必要な対応を整理します。

バックアップと検証を行って修正版へアップデートする

対象バージョンを利用している場合は、修正版以降へアップデートします。

ただし、WordPress本体をアップデートすると、利用しているテーマやプラグイン、独自機能に影響する可能性があります。重要なWebサイトでは、本番環境へ直接適用するのではなく、バックアップや検証、アップデート後の動作確認まで含めて対応します。

WordPress公式も、アップデート前にデータベースとファイルをバックアップするよう案内しています。詳しい考え方は、WordPress公式のバックアップに関する解説で確認できます。

WordPressのデータベースとファイルは別に管理されているため、復元可能な状態にするには、両方のバックアップが必要です。

対応は、次の順番で進めます。

  1. データベースとWordPressファイルをバックアップする
  2. アップデート前のWordPress、プラグイン、テーマのバージョンを記録する
  3. 検証環境がある場合は、先にアップデートを適用する
  4. WordPress本体、プラグイン、テーマの互換性を確認する
  5. 本番環境へ修正版を適用する
  6. 実際に修正版以降へアップデートされたことを確認する
  7. 主要ページと機能を確認する
  8. 作業内容と確認結果を記録する

アップデート後は、ページが表示されることだけでなく、次のような機能も確認します。

  • 管理画面へのログイン
  • 記事やページの更新
  • 問い合わせ・申請フォーム
  • サイト内検索
  • 資料ダウンロード
  • 外部システムとの連携
  • 独自テーマやプラグインの機能
  • メールの送信や通知

検証環境がない場合は、問題が起きた際に元へ戻せるバックアップを確保し、Webサイト制作会社やCMS保守会社とアップデート手順、確認項目、復旧方法を決めてから進めます。

ただし、検証に時間をかけすぎて、対象バージョンを長期間公開し続けることも避ける必要があります。

WAFを導入していてもアップデートは必要

WAFは、攻撃通信の遮断やアクセスログの取得に役立ちます。

一方で、WAFの導入はWordPress本体のアップデートに代わるものではありません。WAFを導入している場合も、現在のWordPressのバージョンを確認してください。

また、WAFを通らずにサーバーへ直接アクセスできる経路がないか、必要に応じてサーバー運用会社へ確認します。

アップデート前に不審な変更やアクセスがなかったか確認する

修正版へのアップデートは、今回の脆弱性を悪用した新たな攻撃を防ぐための対策になります。

一方で、アップデート前に不正な管理者アカウントやファイルが設置されていた場合、それらがアップデートによって自動的に削除されるとは限りません。

JPCERT/CCも、修正版へのアップデートに加えて、セキュリティ企業から公開されている侵害調査の参考情報を確認するよう案内しています。詳細は、JPCERT/CCのWeekly Reportで確認できます。

修正版の公開後も対象バージョンで公開していた期間がある場合は、アップデートとは別に、不審な変更やアクセスがないか確認します。

自社のWordPress運用担当者が確認できること

  • 身に覚えのない管理者アカウントが追加されていないか
  • 身に覚えのないプラグインが追加されていないか
  • ページや記事が改ざんされていないか
  • サイトの表示や機能に異常がないか
  • 身に覚えのない記事・ページの更新履歴がないか

Webサイト制作会社やサーバー運用会社へ確認を依頼すること

  • 不審なファイルの追加や変更
  • WordPress管理画面へのアクセス履歴
  • WebサーバーやWAFなどのアクセスログ
  • WordPressサーバーから外部への不審な通信
  • サーバー内部で実行されている不審な処理

特に、IR(投資家向け情報)や適時開示、入試・学生向け情報、住民・事業者向け情報など、改ざんや停止による影響が大きいサイトでは、確認の優先度を上げる必要があります。

個人情報への不正アクセスや公式情報の改ざんが疑われる場合は、Web担当者と委託先だけで判断せず、情報システム、セキュリティ、法務、広報などの関係部門へ共有します。

不審な点を見つけた場合

不審なアカウントやファイルを見つけても、担当者の判断だけですぐに削除すると、原因や影響範囲を確認するための情報が失われる可能性があります。

まずは、発見した内容、日時、サーバーの状態、アクセスログなどを記録・保全し、情報システム部門やセキュリティ担当へ報告します。

そのうえで、必要に応じてサイトやサーバーの隔離、専門会社による調査、法務・広報・経営層などの関係者への共有を進めます。

まとめ|アップデート状況と不審な兆候を分けて確認する

今回の「wp2shell」は、プラグインやテーマではなく、WordPress本体に関する脆弱性です。対象バージョンでは、認証情報を持たない第三者から不正なコードを実行される可能性があり、すでに実際の悪用も確認されています。

WordPressを利用している場合は、まず次の内容を確認してください。

  • メインサイト以外も含め、管理対象のWordPressを洗い出す
  • 自動更新の設定ではなく、実際のバージョンを確認する
  • CMS保守の契約範囲と担当者を確認する
  • 対象バージョンを利用している場合は、バックアップと検証を行って修正版へアップデートする
  • アップデート後は、主要ページやフォームなどの動作を確認する
  • 対象バージョンで公開していた場合は、不審な変更やアクセスがなかったか確認する
  • 不審な点がある場合は、担当者だけで削除せず、状況とログを保全する

上場企業、大学、官公庁など、複数のサイトを複数の部門・事業者で管理している組織では、1つのサイトをアップデートして終わりではありません。

対象環境の洗い出し、委託先ごとの対応確認、アップデート結果の記録、不審な兆候の確認までを組織全体で進める必要があります。

WordPressのバージョンやアップデート状況が分からない場合や、現在のCMS保守契約でどこまで対応されるか判断できない場合は、クロジカへご相談ください。

ご利用環境や契約内容を確認し、脆弱性情報の提供、WordPress本体・プラグインのアップデート、検証環境の構築、異常時のログ調査、対応方針の整理など、必要な対応をご案内します。

コーポレートサイトクラウドでセキュアに

コーポレートサイトをクラウドでセキュアに クロジカガイドブック

クラウドサーバー管理
クロジカガイドブック

「クロジカクラウドサーバー管理」の詳しい内容がわかる資料をご用意しました。
  • コーポレートサイト構築・運用の課題を解決
  • クロジカクラウドサーバー管理の主な機能
  • 導入事例
  • 導入までの流れ

詳しい資料をご覧いただけます

クロジカクラウドサーバー管理のサービス内容を記載した資料をダウンロードできます。
クロジカの機能や事例が分かる
資料ダウンロード