※本稿は、2026年8月30日時点で公開されているIPA、JPCERT/CC、WordPress公式資料に基づいています。WordPressの最新版や修正版は今後更新される可能性があるため、公開時点の情報を必ず再確認してください。
※wp2shellの対象バージョンや修正状況は公表資料に基づく事実です。一方、責任分担表、契約項目、確認頻度などは中小企業向けの実務上の提案です。実際の責任範囲は、契約書、見積書、仕様書、利用規約などによって異なります。
「ホームページのことは、制作会社に任せています」
自社サイトの管理について尋ねると、このように答える会社があります。
しかし、ここで確認したいのは、制作会社へ依頼しているかどうかではありません。
- WordPress本体を更新するのは誰か
- プラグインやテーマを更新するのは誰か
- 緊急の脆弱性情報を確認するのは誰か
- 更新後にサイトが正常に動くか確認するのは誰か
- 不正アクセスの疑いがあるときにログを調べるのは誰か
- サイトを一時停止する判断をするのは誰か
これらについて、会社と制作会社の回答が一致しているかが重要です。
IPAは2026年7月22日、WordPressの脆弱性「wp2shell」について注意喚起を公表しました。
二つの脆弱性を組み合わせることで、WordPress 6.9以降の一部バージョンでは、標準的な構成で管理者権限を持たない攻撃者が、遠隔からコードを実行できる可能性が指摘されています。脆弱性を悪用するための実証コードも公開され、米国CISAの「既に悪用が確認された脆弱性」の一覧にも追加されました。IPAは、影響を受けるサイトに対して直ちに更新するよう推奨しています。
JPCERT/CCも、認証なしで遠隔コード実行につながる脆弱性であり、複数のセキュリティ企業が悪用を確認しているとして、修正版への更新と侵害有無の確認を呼び掛けています。
今回の問題は、WordPressの技術的な脆弱性だけでなく、緊急の更新が必要になったときに、誰が何をするのか決まっているかを確認する機会でもあります。
wp2shellとは何か
wp2shellは、WordPress本体に存在した次の二つの脆弱性を組み合わせた攻撃手法の通称です。
- CVE-2026-60137
- CVE-2026-63030
WordPress公式は、SQLインジェクションに関する問題と、REST APIのバッチ処理に関する問題を組み合わせることで、遠隔コード実行につながる可能性があると説明しています。WordPress 7.0.2は、このうち一件の重大度を「Critical」、もう一件を「High」として修正したセキュリティリリースです。
影響を受ける主なバージョンは次のとおりです。
| WordPressのバージョン | wp2shellとの関係 | 公表された修正版 |
|---|---|---|
| 6.8.0～6.8.5 | CVE-2026-60137の影響を受ける | 6.8.6 |
| 6.9.0～6.9.4 | 二つの脆弱性の影響を受ける | 6.9.5 |
| 7.0.0～7.0.1 | 二つの脆弱性の影響を受ける | 7.0.2 |
| 6.8より前 | この二つの脆弱性の影響は受けないとされる | 別の脆弱性やサポート状況は別途確認 |
IPAは、影響を受けるサイトについて、WordPress 6.8.6、6.9.5または7.0.2への更新を案内しています。
ただし、これはwp2shellに対する最低限の修正バージョンです。
その後もWordPress 7.0.3、7.0.4がセキュリティリリースとして公開され、2026年8月19日にはWordPress 7.1が公開されています。WordPress公式は、原則として最も新しいバージョンのみを積極的なサポート対象とし、古い系列への修正提供は便宜上のバックポートであると説明しています。したがって、「7.0.2になっているから今後も安心」と判断せず、現在の最新版とプラグイン・テーマの対応状況を確認する必要があります。
なお、「6.8より前ならwp2shellの影響を受けない」という情報だけを見て、古いWordPressを使い続けるべきではありません。
特定の脆弱性に該当しないことと、サイト全体が安全であることは別の話です。
「自動更新されたはず」で終わらせない
wp2shellについては、深刻度が高いことから、WordPress.orgが影響を受けるバージョンに対して強制的な自動更新を有効にしました。
しかし、IPAは次の可能性を指摘しています。
- WordPressの構成や設定により自動更新が有効になっていない
- 自動更新が無効化されている
- 更新処理が途中で失敗している
- サーバー環境などの理由で更新できていない
そのため、管理画面を開き、実際のバージョンを確認する必要があります。
「自動更新を設定している」と「更新が完了した」は同じではありません。
プラグインやテーマについても、WordPress公式資料では、自動更新が通常1日2回実行され、成功または失敗した場合に通知メールが送られる仕組みが案内されています。一方、サーバーやWordPress Cronの状態などにより、自動更新が正常に動作しない場合もあります。
自動更新を利用する場合でも、次の担当者を決めてください。
| 確認事項 | 担当者を決める |
|---|---|
| 更新通知を受け取る | 誰のメールアドレスを登録するか |
| 更新失敗を確認する | 誰が通知メールを読むか |
| サイトを確認する | 誰が表示、フォーム、管理画面をテストするか |
| 不具合に対応する | 誰がロールバックや修正を行うか |
| 作業結果を残す | 誰が更新記録を作成するか |
制作会社の担当者だけに通知が届いている場合、その担当者が退職したり、保守契約が終了したりすると、会社側では更新失敗に気付けない可能性があります。
会社側でも、少なくとも更新結果を確認できる連絡先を一つ用意しておくことが重要です。
制作会社へ依頼していることと、保守を契約していることは別
Webサイトを制作会社へ発注していても、納品後にどこまで対応するかは契約によって異なります。
例えば、次の契約は内容が異なります。
- Webサイトのデザインと制作のみ
- 毎月の記事や画像の更新
- WordPress本体とプラグインの更新
- サーバーやPHPを含む技術保守
- バックアップと復旧
- 不正アクセスの監視
- 緊急時の調査と復旧
- 平日営業時間外や休日の対応
「月額の管理費を払っている」というだけでは、どこまで含まれているか分かりません。
月額費用の内容が、文章や画像の差し替えだけであり、WordPress本体の更新や脆弱性対応は含まれていない場合も考えられます。
反対に、技術保守が契約に含まれていても、休日の緊急作業、侵害調査、ログ解析、外部専門会社への依頼などが別料金になっていることもあります。
どちらが正しいという話ではありません。
重要なのは、会社と制作会社が同じ認識を持っていることです。
IPAの「情報システム・モデル取引・契約書」も、ユーザー企業とITベンダーが、契約時に仕様、プロジェクト管理、検収方法、セキュリティなどについて共通理解を持つことの重要性を示しています。保守・運用についても、開発とは分けて契約内容を確認できる構成になっています。
レンタルサーバー会社が全部守ってくれるわけではない
WordPressをレンタルサーバー上で運用している場合、サーバー会社が一定のセキュリティ対策を実施しています。
しかし、サーバー会社の責任範囲と、Webサイト運営者の責任範囲は同じではありません。
WordPress公式のセキュリティ資料では、ホスティング事業者はサーバー基盤を管理することが多い一方、利用者がインストールしたWordPressなどのアプリケーションまで、当然に責任を負うわけではないと説明しています。
IPAも、クラウドやホスティングサービスを利用する場合、サービス事業者が実施する作業と自社側の責任範囲を把握し、不足する対策を自組織で補う必要があるとしています。
例えば、レンタルサーバー会社が次の作業を行っていても、WordPressの管理までは契約に含まれていない場合があります。
- サーバー設備の管理
- OSや基盤ソフトウェアの保守
- ネットワーク監視
- サーバー全体のバックアップ
- 障害時の設備復旧
- WAFや不正通信対策の提供
一方、次の作業は、会社または制作・保守会社側の担当となることがあります。
- WordPress本体の更新
- プラグインとテーマの更新
- 不要なプラグインの削除
- 管理者アカウントの管理
- 問い合わせフォームの確認
- 独自プログラムの修正
- 更新後の表示・動作確認
- 改ざんや不正ファイルの調査
実際の担当は、利用中のサービスと契約によって異なります。
「レンタルサーバーなので安全」「制作会社に任せているので安全」という言葉で終わらせず、作業単位で確認してください。
WordPress保守で確認する対象
WordPressサイトは、WordPress本体だけで構成されているわけではありません。
少なくとも、次の対象を分けて管理する必要があります。
| 対象 | 確認する内容 |
|---|---|
| ドメイン | 契約者、管理ID、更新期限、DNS設定 |
| レンタルサーバー | 契約者、管理画面、サポート期限 |
| OS・Webサーバー | 更新主体、サポート状況 |
| PHP | バージョン、WordPress・プラグインとの互換性 |
| データベース | バージョン、バックアップ、障害時の復旧 |
| WordPress本体 | 現在のバージョン、自動更新、更新履歴 |
| プラグイン | 名称、用途、バージョン、提供元、更新停止の有無 |
| テーマ | 親テーマ、子テーマ、独自改修、更新方法 |
| 独自プログラム | 制作会社が作成したコード、修正担当 |
| 管理者アカウント | 自社、制作会社、保守会社、退職者の権限 |
| バックアップ | ファイル、データベース、保存先、復元方法 |
| ログ | Web、管理画面、サーバー、WAFなど |
| WAF・CDN | 提供会社、設定主体、検知時の連絡先 |
| フォーム | 入力情報、保存先、通知先、外部連携 |
| SSL証明書 | 更新方法、自動更新失敗時の連絡先 |
例えば、制作会社がWordPress本体を更新していても、PHPの更新はレンタルサーバー会社または自社側の操作が必要な場合があります。
プラグインを更新できても、独自改修したテーマが新しいバージョンに対応できない場合もあります。
一つの会社が全て担当する必要はありません。
ただし、各項目について、主担当と確認者が一人もいない状態をなくすことが必要です。
役割分担表を一枚作る
次の表は、公的機関が定めた統一的な責任分担ではありません。
自社、制作会社、サーバー会社などの分担を確認するためのたたき台です。
| 作業 | 自社 | 制作・保守会社 | サーバー会社 | 完了を確認する記録 |
|---|---|---|---|---|
| 脆弱性情報の収集 | 確認 | 主担当候補 | 契約範囲を通知 | 注意喚起、受付記録 |
| 対象バージョンの確認 | 確認 | 主担当候補 | 基盤情報を提供 | バージョン一覧 |
| WordPress本体の更新 | 承認 | 主担当候補 | － | 更新前後のバージョン |
| プラグイン・テーマ更新 | 承認 | 主担当候補 | － | 更新一覧、テスト結果 |
| PHP・データベース更新 | 影響判断 | 互換性確認 | 主担当候補 | 作業報告 |
| 更新前バックアップ | 確認 | 主担当候補 | 機能提供 | バックアップ日時 |
| 更新後の動作確認 | 業務確認 | 技術確認 | － | テスト結果 |
| 管理者アカウント整理 | 承認 | 作業 | － | アカウント一覧 |
| ログの保存 | 保存要件決定 | アプリ側確認 | 基盤側確認 | 保存期間・保管場所 |
| 不正アクセス調査 | 経営判断 | 初期確認 | ログ提供 | 調査記録 |
| サイトの一時停止 | 最終判断 | 技術作業 | 必要に応じて協力 | 停止・再開記録 |
| 顧客・取引先への連絡 | 主担当 | 技術情報を提供 | 事実情報を提供 | 通知文、承認記録 |
「主担当候補」と記載している部分も、実際の契約では自社側の担当になることがあります。
表を作った後、制作会社と一緒に確認し、認識が異なる部分を契約書や仕様書へ反映してください。
wp2shellへの対応で、まず確認すること
WordPressを利用している場合は、次の順序で確認します。
1．自社が運営するWordPressサイトを全て洗い出す
公式サイトだけでなく、次のサイトも確認します。
- 採用サイト
- 店舗別サイト
- キャンペーンサイト
- 会員サイト
- 社内向けサイト
- 開発・テストサイト
- 過去に使用していたサブドメイン
- 制作会社が管理している旧サイト
IPAは、不要になったページや管理できていないWebサイトを公開し続けると、脆弱性への対応が行き届かないおそれがあるため、不要なサイトは閉鎖するよう案内しています。
2．WordPressのバージョンを確認する
管理画面だけで判断できない場合は、制作会社またはサーバー会社へ確認します。
確認結果は、次のように記録します。
| サイト名 | URL・識別名 | 確認日時 | 更新前バージョン | 更新後バージョン | 確認者 |
|---|---|---|---|---|---|
| 会社公式サイト | 本番環境 | 2026年○月○日 | 7.0.1 | 7.1 | 制作会社○○氏 |
| 採用サイト | 本番環境 | 2026年○月○日 | 6.9.4 | 6.9.5以降 | 自社○○氏 |
3．修正版または最新の安定版へ更新する
wp2shellの対象バージョンを使用している場合は、公式資料で修正済みとされるバージョン以上へ更新します。
ただし、2026年8月時点ではwp2shell修正後にも複数のセキュリティリリースが公表されています。更新先は「wp2shellだけが直った最小バージョン」で固定せず、最新版、プラグイン・テーマの互換性、サーバー環境、制作会社のサポート状況を確認して決定してください。
4．更新前にバックアップと復旧方法を確認する
WordPress公式は、更新前にバックアップを取得することを推奨しています。
一般的なWordPressサイトを復元するには、Webサーバー上のファイルとデータベースの両方が必要です。ファイルだけ、またはデータベースだけでは、サイト全体を元の状態へ戻せない場合があります。
ただし、緊急性の高い脆弱性では、バックアップ作業を理由に更新を長期間先延ばしにしてはいけません。
短時間でバックアップを取得できる体制と、緊急更新に対応できる手順を平時から準備する必要があります。
5．更新後の動作を確認する
最低限、次の機能を確認します。
- トップページが表示される
- スマートフォン表示が崩れていない
- 問い合わせフォームを送信できる
- 自動返信メールが届く
- 管理画面へログインできる
- 記事や画像を更新できる
- 予約、注文、会員登録などの主要機能が動く
- 外部サービスとの連携が動く
- エラーや警告が表示されていない
技術的な確認を制作会社が行い、業務上の確認を自社が行う形が現実的です。
例えば、制作会社は「フォーム送信処理が正常」と確認できても、問い合わせメールが実際の営業担当者へ届いているかまでは分からない場合があります。
更新しただけでは、過去に侵入されていない証明にはならない
wp2shellは、悪用が確認された脆弱性です。
影響を受けるバージョンをインターネット上で公開していた場合、修正版へ更新することで今後の攻撃を防ぐことはできますが、更新前に侵入されていなかったことまでは証明できません。JPCERT/CCも、修正版への更新とともに、侵害調査に関する情報を確認するよう案内しています。
実務上は、次のような点も確認します。
- 見覚えのない管理者アカウントが追加されていないか
- 不要または不明なプラグインが追加されていないか
- テーマやプラグインのファイルが改変されていないか
- 不審なPHPファイルなどが置かれていないか
- サイトから別のページへ不審に転送されないか
- 表示内容やリンクが改ざんされていないか
- 管理者パスワードが変更されていないか
- サーバーやWAFのログに不審なアクセスがないか
- フォームの送信先や通知先が変更されていないか
- 外部サービス用のAPIキーや認証情報が窃取されていないか
これはwp2shellに関する公的な完全チェックリストではなく、侵害の可能性を確認する際の一般的な項目です。
不審なファイルやアカウントを見つけた場合、自己判断ですぐに削除すると、原因調査に必要な情報を失う可能性があります。
画面、ファイル名、日時、ログなどを保全し、必要に応じてサイトを一時停止したうえで、制作会社、サーバー会社、セキュリティ専門家へ相談してください。
IPAも、Webサーバーのアクセスログやアプリケーションログなどは、不正アクセスに気付く手掛かりとなり、原因調査の重要な情報源になるとして、保存と定期的な確認を求めています。
保守契約で確認したい十二の項目
WordPressの保守契約や仕様書には、少なくとも次の項目を記載します。
| 項目 | 確認する内容 |
|---|---|
| 1．対象サイト | 本番、採用、キャンペーン、テスト環境のどこまで含むか |
| 2．対象ソフトウェア | WordPress本体、プラグイン、テーマ、PHP、データベースのどこまで含むか |
| 3．情報収集 | IPA、JPCERT/CC、WordPress公式、プラグイン提供元などを誰が確認するか |
| 4．影響判定 | 自社サイトが対象か、誰が調査するか |
| 5．連絡期限 | 緊急情報を確認後、何時間・何営業日以内に連絡するか |
| 6．更新期限 | 緊急、重要、通常の更新をそれぞれいつまでに行うか |
| 7．緊急更新権限 | 自社の事前承認なしで更新してよい条件を定めるか |
| 8．バックアップ | 更新前に何を保存し、誰が復旧できるか |
| 9．動作確認 | どのページ・フォーム・機能を確認するか |
| 10．異常時対応 | ロールバック、一時停止、調査を誰が行うか |
| 11．作業報告 | 更新前後のバージョン、日時、結果をどう報告するか |
| 12．契約終了時 | アカウント、ソースコード、バックアップ、設定、ログをどう引き継ぐか |
特に重要なのは、「脆弱性情報を確認する」だけでなく、自社サイトが対象か判断し、更新結果まで確認する作業を含めることです。
「情報が出たら連絡します」という契約でも、連絡後の更新作業が別料金であれば、社内承認に時間がかかる可能性があります。
緊急性の高い脆弱性については、一定の条件を満たす場合に、保守会社が事前承認なく更新できる仕組みも検討します。
緊急度を三段階に分ける
全ての更新を同じ扱いにすると、通常の機能更新と緊急の脆弱性対応が混在します。
実務上は、例えば次のように分類できます。
| 区分 | 判断例 | 対応例 |
|---|---|---|
| 緊急 | 悪用が確認済み、認証なしで攻撃可能、遠隔コード実行、外部公開中 | 直ちに影響確認、バックアップ、更新または一時停止 |
| 重要 | 重大な脆弱性だが、攻撃条件が限定される | 指定した短期間内に検証・更新 |
| 通常 | 機能改善、軽微な不具合、低リスクの修正 | 定期保守日に更新 |
wp2shellは、悪用が確認され、認証なしで遠隔コード実行につながる可能性があり、実証コードも公開されたため、緊急対応を検討すべき条件に該当します。
ただし、具体的な対応期限を一律に決める公的基準があるわけではありません。
自社サイトの役割、個人情報の有無、停止時の影響、更新による不具合の可能性、保守体制を踏まえて、契約上の目標時間を決めてください。
更新を待つ間の判断も決めておく
更新に互換性確認が必要な場合、すぐに適用できないことがあります。
その場合に、「制作会社の確認が終わるまで公開を続ける」と自動的に判断するのは危険です。
次の選択肢を検討します。
- サイトをメンテナンス表示にする
- 問い合わせフォームなど一部機能を停止する
- WAFやアクセス制御による暫定対策を行う
- 管理画面へのアクセス元を制限する
- 不要なプラグインや機能を停止する
- 代替ページへ切り替える
- 全面停止せず、静的ページだけを公開する
どの方法が有効かは、脆弱性とサイト構成によって異なります。
脆弱性の仕組みを確認せず、「管理画面のURLを変える」「パスワードを強くする」といった一般的な対策だけで安全だと判断しないでください。
wp2shellは管理者アカウントへのログインを前提としない可能性があるため、管理者パスワードの変更だけでは、脆弱性そのものの解消にはなりません。
作業報告を残す
更新作業が完了したら、メールで「対応しました」と連絡を受けるだけで終わらせず、最低限の記録を残します。
| 記録項目 | 記載例 |
|---|---|
| 対象サイト | 会社公式サイト |
| 対応理由 | CVE-2026-60137、CVE-2026-63030 |
| 情報源 | IPA、WordPress公式 |
| 対応日時 | 2026年○月○日 ○時○分 |
| 更新前 | WordPress 7.0.1 |
| 更新後 | WordPress 7.1 |
| バックアップ | ファイル・DB取得済み、保存先○○ |
| 更新者 | 株式会社○○ 担当○○氏 |
| 確認者 | 自社広報担当○○ |
| 確認項目 | 表示、フォーム、メール、管理画面 |
| 異常 | なし、または未解決事項 |
| ログ確認 | 実施、未実施、別途調査中 |
| 次回確認 | 2026年○月○日 |
この記録があれば、経営者への報告、取引先からの質問、SCS評価制度への準備、事故発生時の調査にも利用できます。
一方、「制作会社がやっているはず」という状態では、いつ、誰が、どのバージョンへ更新したか説明できません。
保守仕様の記載例
保守契約書や仕様書には、例えば次のように記載できます。
受託者は、契約対象となるWordPress本体、プラグイン、テーマその他のソフトウェアについて、公式提供元、IPA、JPCERT/CCその他双方が合意した情報源から脆弱性情報を収集する。
契約対象が脆弱性の影響を受ける可能性がある場合、受託者は影響の有無、想定される影響、修正版、暫定対策および作業予定を委託者へ報告する。
現に悪用が確認されている脆弱性、認証を必要としない遠隔コード実行その他双方が緊急と定めた条件に該当する場合は、別途定める緊急変更手順に従う。
受託者は、更新前に必要なバックアップを取得し、更新後に双方が定めた動作確認を実施する。更新に失敗した場合は、復旧またはロールバックを実施する。
受託者は、対応日時、更新前後のバージョン、作業内容、確認結果、未解決事項を記載した作業記録を提出する。
不正アクセス、改ざんその他の侵害が疑われる場合は、証拠となるログやファイルを保全し、委託者へ速やかに報告する。
これは一般的な記載例であり、法的な契約書の完成形ではありません。
具体的な期限、料金、損害賠償、再委託、秘密保持、個人情報、契約終了時の引継ぎなどについては、契約当事者と必要に応じて弁護士へ確認してください。
制作会社を変更するときにも確認する
Webサイトの管理で事故が起きやすいのは、制作会社を変更したときです。
前の制作会社のアカウントが残っている、新しい制作会社がサーバーへ入れない、ドメインの契約者が不明、バックアップが引き継がれていないといった問題があります。
契約終了時には、次の情報を受け取ります。
- ドメイン管理情報
- DNS設定
- サーバー管理情報
- WordPress管理者情報
- ソースコード
- 独自テーマ・プラグイン
- 使用中プラグイン一覧
- PHP・データベース等の構成情報
- バックアップ
- 復旧手順
- WAF・CDN・外部サービスの設定
- アクセス解析や広告タグの管理情報
- 更新履歴
- 障害・脆弱性の未解決事項
- 制作会社側アカウントの削除記録
パスワードをメール本文や引継書へ直接記載する場合は、送信方法や保管方法にも注意が必要です。
旧制作会社のアカウントを削除する前に、必要なデータと権限が新しい担当者へ引き継がれていることを確認します。
経営者が確認したい五つの質問
経営者がWordPressの技術的な仕組みを全て理解する必要はありません。
まず、担当者または制作会社へ次の五つを確認してください。
- 自社が運営しているWordPressサイトを全て一覧にできるか
- WordPress本体、プラグイン、PHPをそれぞれ誰が更新するか
- 緊急の脆弱性情報を、誰が何時間・何営業日以内に確認するか
- 不正アクセスが疑われた場合、誰がログを保全し、サイト停止を判断するか
- 更新前後のバージョン、バックアップ、確認結果を記録しているか
一つでも回答が曖昧であれば、制作会社との役割分担を確認する必要があります。
まとめ
wp2shellは、WordPress本体に存在した二つの脆弱性を組み合わせ、認証なしで遠隔コード実行につながる可能性がある問題です。
影響を受けるバージョンについては修正版が公開され、自動更新による強制更新も行われました。しかし、構成や設定によっては自動更新されていなかったり、更新に失敗していたりする可能性があります。
そのため、管理画面や制作会社への確認によって、実際のバージョンを確認しなければなりません。
同時に確認したいのが、制作会社との役割分担です。
「ホームページは制作会社に任せている」という説明だけでは、次のことは分かりません。
- 誰が脆弱性情報を確認するのか
- 誰が対象バージョンを調べるのか
- 誰がバックアップを取得するのか
- 誰が緊急更新を承認するのか
- 誰が更新後の動作を確認するのか
- 誰がログを保存し、不正アクセスを調査するのか
まずは、契約書、見積書、仕様書、過去の作業報告を確認してください。
そのうえで、WordPress本体、プラグイン、テーマ、PHP、サーバー、バックアップ、ログ、緊急停止について、主担当と確認者を一枚の表にまとめます。
Webサイトを制作会社へ任せることはできます。
しかし、何を任せたのかを把握することまで、制作会社任せにしてはいけません。
ライトハウスコンサルタントでは、専任の情報システム担当者がいない中小企業を対象に、Webサイト、WordPress、サーバー、クラウドサービス、委託先の管理状況を確認し、制作会社や保守会社へ確認すべき事項を整理する支援を行っています。
既存の制作会社を否定するのではなく、自社と委託先の役割を明確にし、対応漏れをなくすことが目的です。
