>
>
公開日
WordPressの脆弱性に対応する情シス担当者向けに、2026年10月に修正され米CISAが悪用を確認したCVE-2026-119977（影響は4.7〜7.1.3、修正版は7.1.4）を整理します。自社サイトのバージョンと自動更新設定の確認、更新後の不審なファイル・管理者アカウントの点検、制作会社への照会、公開Web資産の台帳化まで、対応完了の判断に使える確認表とともに示します。
WordPressの脆弱性とは
WordPressの脆弱性とは、本体やプラグイン、テーマに存在する、不正アクセスや改ざんなどにつながり得るセキュリティ上の弱点です。対象読者は、企業サイトを管理する情報システム部門の担当者・管理者です。WordPressのセキュリティ対策を、設定の有無ではなく、対応記録を根拠に判断するための観点を整理します。自動更新の設定を調べている場合も、設定内容と実際の更新結果を分けて扱い、自社運用・外部委託の両方を確認対象に含めます。
本記事のポイント
自動更新の設定と更新完了の記録は別の確認対象です。
更新完了と侵害の有無は別の判断です。
委託サイトも自社の管理対象です。
この記事の根拠とした情報
本記事が根拠とするのは、WordPress公式の「WordPress 7.1.4」リリース案内（2026年10月28日）、米国立標準技術研究所（NIST）の脆弱性データベース（NVD）に登録されたCVE-2026-119977の情報、米CISAのKEVカタログ、IPAの「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell)」です。
IPAは2026年7月22日公開の注意喚起で、WordPress 6.9以降ではCVE-2026-60137とCVE-2026-63030の組み合わせにより、遠隔でのコード実行が生じる可能性があると説明しています。個別の脆弱性は、このように識別番号と出典を対応させて扱います。
管理上の判断では、更新完了の記録があれば更新状況の確認に使い、記録がなければ「設定済み」を理由に対応完了へ進めません。また、更新完了の記録だけで「侵害なし」と判断することも避けます。以降は、この区別を前提に、自社サイトと委託サイトの対応状況を判断するための確認項目を整理します。
更新中を狙う攻撃と一次情報の確認範囲
ここでは、2026年10月に修正されたCVE-2026-119977について、WordPress公式、NVD、米CISAの公表情報で確認できた内容を整理します。
更新処理と競合状態の関係
競合状態とは、複数の処理が同じ資源に関わり、実行順序やタイミングによって結果が変わる状態です。
WordPress公式は「WordPress 7.1.4」の案内で、更新処理の弱点により、更新中の時間帯に遠隔でコードを実行され得る問題を修正したと説明しています。NVDによると、この脆弱性（CVE-2026-119977）は、本体を一括パッケージで更新する際に使う一時的な展開先のパスが推測でき、Webから到達できることが原因です。認証されていない攻撃者が、更新中にサーバー上でコードを実行できる可能性があります。米CISAはこれを、競合状態の一種であるTOCTOU（チェックと使用の時間差）の脆弱性に分類しています。
本記事では、攻撃の再現手順や悪用対象のファイル名は扱いません。
影響範囲・修正版・深刻度の根拠
CVE-2026-119977について、2026年11月9日時点で一次情報から確認できる事項は次のとおりです。
論点 | 確認できた内容 |
|---|---|
影響を受ける版 | WordPress 4.7から7.1.3まで（NVDの登録情報） |
修正版 | 最新版は7.1.4（2026年10月28日公開）です。旧ブランチ向けの修正版（7.0.8、6.9.11、6.8.12など、4.7系まで）も公開されています。WordPress公式は、積極的にサポートしているのは最新版だけだとしています。 |
深刻度 | WordPress公式は数値の評価を示さず、直ちに更新するよう推奨しています。CVEを登録したWordfenceは、CVSS 3.1で8.1（High）と評価しています。 |
悪用状況 | 米CISAが2026年11月3日にKEVカタログへ追加しました。米連邦政府機関への対応期限は11月6日です。 |
確認済みの別件として、WordPress公式はWordPress 7.1.2のリリース案内で、テンプレート解決処理に関する脆弱性CVE-2026-87902の修正をブランチ4.7までバックポートすると案内しています。バックポートは、修正を過去のバージョン系列にも適用することです。この案内は別のCVEに関するものです。7.1.2と7.1.3はCVE-2026-119977の影響範囲に含まれるため、7.1系では7.1.4への更新が必要です。
社内の対応記録に情報を採用する場合は、発信元、対象CVE、主張を支える記述をひとまとまりで残します。対象CVEと修正内容の対応が一次情報で確認できれば判断材料に加え、対応関係が確認できなければ保留情報として分けます。これにより、似たバージョン番号や別件の評価が、対応済みという誤判定につながることを防ぎます。
自社サイトのバージョンと自動更新設定の確認
自動更新の設定だけでは更新完了を判断せず、実際のバージョンと更新結果を照合します。
脆弱性への対応状況は、設定、実行結果、確認日時、証跡を分けて整理します。証跡とは、判断の根拠として残す画面の写しや作業記録です。「自動更新が有効」という記録と「修正が反映された」という記録を混同しなければ、更新作業へ進む対象と、情報収集が先になる対象を区別できます。
稼働バージョンの証跡
稼働バージョンは、対象サイトと確認日時が結び付いた証跡で記録します。
管理画面を閲覧できる場合は、本体の版を「ダッシュボード」→「更新」画面で、プラグインの版を「プラグイン」→「インストール済みプラグイン」画面で、テーマの版を「外観」→「テーマ」のテーマ詳細で確認し、確認日時とともに対象URLを特定できる形で画面の写しを残します。サーバーへSSHで入れる場合は、WP-CLIの「wp core version」「wp plugin list」「wp theme list」の出力を保存すると、管理画面の表示と突き合わせられ、食い違えば版の差異を委託先や管理者へ照会する対象になります。画面に表示された情報だけでは更新結果まで判断できない場合、その部分は未確認として分けます。
閲覧権限がない場合は、管理権限を持つ担当者や委託先から、対象URL、確認日時、稼働版が分かる証跡を受け取る運用にします。「更新済み」という連絡だけでは版を照合できないため、具体的な版が分かる記録を受領するまでは、対応状況を確定させません。
WordPress本体、プラグイン、テーマは別の管理対象として扱います。本体の版を確認できても、それをプラグインやテーマの確認結果に代用せず、各対象の名称と版を別に記録します。
自動更新設定と実行結果
自動更新は、設定内容と実際の更新結果を別々の欄で管理します。
WordPress 3.7以降、本体のマイナーリリース（保守・セキュリティ更新）は既定で自動更新されます。5.6以降の新規インストールでは、メジャーリリースも既定の対象です。プラグインとテーマの自動更新は、既定では一部の例外に限られます（WordPressの公式ドキュメント）。wp-config.phpの定数WP_AUTO_UPDATE_COREやAUTOMATIC_UPDATER_DISABLEDで自動更新が止められている場合もあるため、設定の確認ではこれらの定数も対象にします。WordPress公式は7.1.4の案内で、自動バックグラウンド更新に対応したサイトでは更新が自動的に始まるとしています。
社内で記録様式が決まっていない場合は、次のチェック表を使えます。プラグインとテーマについても、対象ごとに版・設定・結果を分けて追記します。
確認項目 | 記録する内容 |
|---|---|
対象URL | 確認したサイトのURLです。 |
確認日時 | 稼働版や設定を確認した日時です。 |
本体の版 | 証跡から読み取ったバージョンです。 |
自動更新の設定 | 確認できた対象範囲と有効・無効の状態です。不明な範囲は未確認と記載します。 |
更新結果の証跡 | 更新後の版が分かる画面の写しや作業記録の保存先です。 |
担当者 | 証跡の取得や更新判断を担当する人です。 |
次の対応 | 証跡の取得、更新要否の判定、作業準備などの具体的な行動と期限です。 |
設定の記録しかない場合は、結果の欄を推測で埋めません。反対に、更新後の版を確認できても設定が不明なら、版の確認結果は残し、設定だけを未確認とします。情報を分ければ、不足している証跡を担当者へ具体的に依頼できます。ただし、記録項目を設けるだけでは状況は確定しないため、証跡を受領した担当者が内容を照合します。
対応状況の判断基準
対応状況は、対象の修正情報と稼働版を照合できるかどうかで判定します。
IPAはwp2shellの注意喚起で、影響を受ける版の範囲を示しています。その後に公表されたCVE-2026-119977の影響範囲は4.7〜7.1.3と広いため、wp2shellの修正版に更新済みのサイトも再確認の対象になります。どの脆弱性の対象範囲と照合したかを、記録に残します。特定の脆弱性への対応判定を、別の脆弱性にも対応済みという判断へ広げないようにします。
確認結果 | 次の行動 |
|---|---|
対象の修正情報と稼働版を照合できます。 | 更新要否を判定し、必要なら更新作業の準備へ進みます。 |
版の証跡がありません。 | 対応状況は未確認とし、証跡を取得する担当者と期限を決めます。 |
自動更新は有効ですが、結果の証跡がありません。 | 完了扱いにせず、更新後の版と実行結果を取得します。 |
更新が必要と判定できた対象は、確認日時と根拠を添えて作業担当へ引き渡し、更新作業と更新後の点検へ進みます。
▲ 自社サイトの管理画面に対する閲覧権限の有無によるバージョン確認手順の違い。
更新作業と更新後の不審な痕跡の点検
更新後は動作確認に加え、不審なファイルと管理者アカウントの点検結果を記録します。
脆弱性対応を社内で管理する場合は、パッチ適用の完了と侵害調査の完了を別々に扱います。米CISAもCVE-2026-119977をKEVカタログに追加した際、米連邦政府機関に対し、更新の適用とあわせて侵害の有無を確かめるトリアージを求めています。適用する修正や対象範囲は個別の公式案内に従い、作業の進行と未解決事項を次の表で管理します。
フェーズ | 作業 | 担当者 | 残す証跡 | 次へ進む条件 |
|---|---|---|---|---|
着手時 | 対象サイト、変更範囲、承認者、作業担当と調査の引き継ぎ先を整理します。 | 運用責任者が割り当てます。 | 対象一覧、担当者名、承認経路を残します。 | 担当と判断者が決まれば準備へ進みます。 |
更新前 | バックアップの取得状況、復旧方法、変更承認を確かめます。 | 作業担当が確認し、承認者が実施を判断します。 | 取得日時、対象範囲、保存先、復旧手順、承認結果を残します。 | 復旧方法を確保し、承認を得られれば更新へ進みます。 |
更新直後 | 更新結果と公開ページ、利用機能、管理画面を点検します。 | 作業担当と機能の利用部門が分担します。 | 更新前後のバージョン、実施日時、確認結果、不具合を残します。 | 支障がなければ痕跡の点検へ進み、不具合があれば承認者へ対応判断を戻します。 |
点検後 | ファイル差分と管理者を照合し、説明できない項目を切り分けます。 | 点検担当が記録し、疑わしい項目は調査担当へ渡します。 | 確認範囲、照合資料、差分、判断理由、引き継ぎ先を残します。 | 未解決事項があれば調査を継続し、なければ確認範囲を明記して点検を完了します。 |
更新前に復旧方法が分からない場合は、その確保を作業担当へ割り当てます。バックアップの保存先だけでなく、誰がどの手順で戻すかまで整理できれば実施判断に進める運用にします。更新を保留する場合も、保留理由、判断者、暫定対応、その実施担当を記録し、単なる未着手と区別します。暫定対応は自社で実施可能なアクセス制限などを候補とし、公開への影響と併せて判断者が決定する形です。
更新直後の動作確認では、トップページの表示だけで完了にしません。問い合わせを利用しているなら送信と受信、検索を利用しているなら検索結果の表示など、自社で使う機能を点検対象に含めます。管理画面はログインだけでなく、必要な編集操作の利用可否も対象です。不具合が出た場合は、発生した操作、表示内容、更新前との違いを残し、作業担当が継続か復旧かの判断を承認者へ引き継ぎます。
不審なファイルを点検する場合は、既知の正常状態と現在の状態を比較し、追加・変更・削除された箇所を抽出します。差分が更新や承認済みの作業で説明できる場合は、その根拠を記録します。比較元の正常性や対象範囲が分からなければ「比較できなかった範囲」として残し、差分なしとは扱いません。特定のファイル名だけを侵害の判断基準にはしない運用にします。
管理者アカウントは、表示名だけで判断せず、実際の利用者、作成経緯、承認記録と照合します。説明できない管理者やファイル差分が見つかった場合は、削除・変更の前に証跡を保全し、調査担当へ引き継ぎます。あわせてWebサーバーやWAFのアクセスログ、管理画面の操作履歴を保全し、侵害の疑いが強いなら、公開範囲の限定や一時停止、管理者・サーバー・データベースの認証情報の変更を、通常の更新作業とは別の初動判断として社内責任者が決めます。個人情報の漏えいが疑われる場合は法務部門へ、自社で原因を切り分けられない場合は外部の調査支援事業者へ連携します。対象の状態、発見日時、確認した記録を残し、更新済みという理由だけで調査を終了しない扱いです。
差分や不審な管理者を認めなかった場合も、記録は「確認範囲内で異常を認めなかった」とします。これは侵害がなかったという保証ではありません。完了報告には「パッチ適用状況」「動作確認結果」「痕跡の点検結果」「調査の継続有無」を分けて記載すると、更新完了後も調査中の事項を追跡できます。残った課題は担当者とともに対応記録へ引き継ぎます。
▲ WordPress更新作業の着手から点検完了までに実施する4段階の進行手順。
更新対応で避けたい失敗パターン
自動更新の設定、更新済みの報告、不審な痕跡の削除を、それぞれ対応完了の根拠にしません。
以下は、WordPressの脆弱性対応で避けたい運用パターンです。急ぐ場面でも、更新の完了判定と、不正アクセスが疑われる場合の調査完了判定は分けて管理します。
設定だけを根拠にした完了判定
自動更新が有効でも、実行結果を示す記録がなければ、更新対応は未完了として扱います。ここでいう証跡とは、作業の実行と結果を後から確かめられる記録です。
「設定済み」「更新済み」という報告だけで案件を閉じると、管理上は対応済みでも、実際の結果は不明な状態になります。報告を受けた担当者は、記録で結果を裏付けられる場合に完了とし、裏付けがない場合は確認待ちとして担当を残します。
完了を急ぐために「未確認」を「問題なし」へ置き換えない運用にします。確認待ちの案件には判断期限と担当者を明記します。担当が交代しても、未完了の理由と次の対応を台帳に残します。
証跡保全前の削除と復元
不審なファイルやアカウントを見つけた場合は、調査に必要な記録を残さず削除・復元する対応を避けます。見た目を元に戻すことだけを完了条件にしません。
変更前の状態を残さない対応は、後から侵入経路や影響範囲を調べる際の判断材料を減らしかねません。発見時点の状況、対象、発見日時、実施した変更を記録する方針とし、保全の範囲は調査担当と決めます。
被害拡大を抑えるために変更を急ぐ場合も、保全と変更の優先順位を判断する責任者を置きます。削除・復元の判断理由を残し、画面が正常に戻った場合でも、調査上の未解決事項があれば案件を継続します。
更新を止めたままの運用
自動更新を止める場合は、恒久対策として放置せず、停止条件・代替担当・再開判断を一組で設定します。停止の承認だけで運用を終えないための管理案です。
停止時は、更新による不具合など、停止を認める条件と見直し期限を記録します。
停止中は、手動で更新を進める担当者と、不在時の代替担当を決めます。
再開時は、停止理由の解消と更新後の点検体制を責任者が判断し、条件を満たせば再開します。
手動対応には更新作業そのものの負担があり、自動更新にも変更結果を点検する負担があります。作業時間を確保できないから停止するのではなく、どちらの負担を誰が引き受けるかまで決めて運用します。
制作会社・外部委託先の対応状況の確認
委託サイトは、対象サイトを特定できる更新結果と点検記録を受け取って対応状況を判定します。
脆弱性対応を制作会社へ任せる場合も、「対応済み」という連絡だけでは社内の完了扱いにしません。管理画面やサーバーへ直接アクセスできないなら、照会時に報告項目と回答期限を指定し、受領した証跡、つまり作業内容を裏付ける記録で判断する運用にします。
自社で管理権限を持つ場合は、委託先の報告と、自社で確認できる版や作業記録を照合します。相違があれば完了判定を保留し、対象環境や作業内容を再照会します。
自社で管理権限を持たない場合は、対象URLと作業日時が分かる報告書、画面の記録、作業ログなどを受領します。記録から対象サイトを特定できなければ、情報の補足を依頼します。
委託先への照会テンプレート
「下記サイトの脆弱性対応について、以下の項目と、更新結果・点検結果を裏付ける記録をご回答ください。現時点で回答できない項目は、未確認の理由と回答予定日時をご記載ください。回答希望日時：［記入］」として送付します。
対象URL：本番環境など、作業対象を特定できる情報
対象の修正情報：参照した告知のURL、修正対象の本体・プラグイン・テーマの名称
更新前後の版：対象ごとの更新前と更新後のバージョン
作業日時：開始日時と終了日時
更新結果：成功・失敗・未実施の別と、その裏付けとなる記録
更新後の点検範囲：表示・機能の確認、不審な痕跡の点検について、実施範囲と結果
未完了事項：残作業、未確認の範囲、理由、対応予定
作業責任者：氏名または担当部署、連絡先
特定の脆弱性の影響を受けると決めつけず、対象の修正情報と実際の構成を照合した回答を受け取ります。更新後の表示確認しか実施していないなら、侵害の有無まで点検済みとは扱いません。
受領した回答の判定基準
委託先の回答 | 社内での処理 |
|---|---|
サイトを特定できる証跡がそろう場合 | 対象URL・更新前後の版・作業日時・点検結果を社内記録と照合し、未完了事項が残るなら継続管理します。 |
「対応済み」との回答だけの場合 | 不足する証跡を具体的に示して再照会し、受領までは完了扱いにしません。 |
「対象外」との回答の場合 | 構成や版と修正情報を照合した根拠を受領し、根拠が不足するなら判定を保留します。 |
契約上、更新担当・侵害調査担当・緊急連絡先が異なる場合は、役割ごとに担当者と連絡経路を分けて記録します。更新担当の回答範囲に侵害調査が含まれないなら、調査担当への依頼を別に起票します。
回答や作業が得られない場合は、社内責任者が暫定的な公開継続条件と次の判断時点を設定します。例えば、必要な機能だけに公開範囲を限定できるなら、その条件と担当者を記録して期限付きで継続します。条件を満たせないなら、一時停止を含む判断へ進みます。委託した事実を安全性の根拠にせず、回答期限を過ぎた案件は社内責任者へ引き上げます。
▲ 委託先から受領した回答内容に応じた社内判定と処理の分岐フロー。
公開Web資産の台帳化と対応記録の継続管理
公開Web資産は、URLだけでなく運用責任者と更新結果の証跡を結び付けて管理します。
今回の点検結果を次回のWordPressの脆弱性対応へ引き継ぐなら、社内運用と外部委託のサイトを同じ台帳にまとめます。作業の完了報告だけで閉じず、誰が何を確認し、何が残っているかまで記録する運用にします。
台帳の管理項目
点検結果を継続管理する場合は、次の10項目を台帳の基本テンプレートとして使います。
管理項目 | 記入内容 |
|---|---|
URL | 対象サイトの公開URL |
利用目的 | 公開の目的と利用している部署 |
社内責任者 | 対応方針や公開継続を判断する部署・責任者 |
運用担当 | 更新・点検を実施する担当者と連絡先 |
委託先 | 委託先名、窓口、契約上の対応範囲 |
稼働版 | 確認したWordPress本体・プラグイン・テーマの名称と版 |
更新管理方法 | 自動・手動の区別、実施担当、承認の流れ |
最終確認日 | 稼働版と対応状況を確認した日 |
証跡の保存先 | 更新履歴、作業報告、点検記録の保管場所 |
未完了事項 | 残作業、未完了理由、担当者、対応期限 |
不明な項目がある場合は、空欄ではなく「未確認」と記入し、調査担当と期限を未完了事項に残します。委託先から報告を受けた場合も、報告書の保存先と社内で受領・確認した担当者を結び付けます。「更新済み」という記載だけで、点検まで完了した扱いにしない運用です。
未管理サイトの処理基準
未管理サイトが見つかった場合は、責任者の判明状況で対応先を分け、処理結果まで台帳に残します。
判明した状況 | 割り当てと記録 |
|---|---|
責任者が判明 | 担当部署へ点検を割り当て、対応担当と期限を記録します。 |
責任者が不明 | 台帳を統括する社内責任者に、管理者の特定と公開継続の判断を集約します。 |
廃止済みとの申告 | 申告だけでは削除せず、公開停止の確認結果、確認日、判断者を残します。 |
公開停止を確認できれば廃止履歴として保管し、確認できなければ未完了として追跡します。担当部署から返答がない場合も完了にはせず、社内責任者へ判断を戻す扱いにします。
次回の脆弱性情報との照合
新しいWordPressの脆弱性情報を受けた場合は、対象抽出から完了判断までを同じ台帳の対応履歴に追記します。
公表情報の対象製品・影響範囲と稼働版を照合し、対象サイトを抽出します。稼働版が不明なら対象外にせず、確認待ちとして残します。
社内責任者から運用担当へ対応を割り当て、委託サイトは依頼先と回答期限も記録します。
更新前後の版、作業日、更新結果と証跡の保存先を記入します。
更新後の点検結果を別に記録し、未完了なら理由・次の対応・担当・期限を残します。
過去の対応を追えるようにするなら、最新の状態だけに上書きせず、脆弱性情報ごとの履歴を保持します。記録の手間は増えるため、作業報告を台帳にも全文転記するのではなく、判断に必要な要点と保存先を記す形にそろえます。
着手時は、今回点検したURLと委託先の報告を台帳へ移し、未確認欄ごとに担当者と回答期限を割り当てます。まずは、未確認の稼働バージョンと更新結果の証跡を回収してください。
まとめ
WordPressの更新処理の弱点を突く脆弱性CVE-2026-119977は、4.7〜7.1.3が影響を受け、7.1.4（2026年10月28日公開）で修正されました。米CISAは11月3日に、悪用が確認された脆弱性のカタログ（KEV）に追加しています。
対象サイトごとに、本体・プラグイン・テーマの版と確認日時を記録します。7.1系なら7.1.4、旧ブランチなら各ブランチの修正版になっているかを確かめます。
自動更新が有効なサイトも、更新後の版と実行結果の証跡を取得します。
委託サイトは、制作会社へ更新前後の版と作業記録を照会します。
更新とは別に、不審なファイル差分と管理者アカウントを点検し、調査の要否を判断します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
