WordPressの脆弱性（2026年11月）｜7.1.4の更新と今やること

2026年11月4日時点で、WordPress 4.7〜7.1.3 には、本体（コア）の更新の途中に、ログインしていない第三者に外からサーバーでコードを実行されうる脆弱性 CVE-2026-119977 があり、7.1.4（古い系統はそれぞれの修正版）で直っています（WordPress の 7.1.4 の告知・NVD の CVE-2026-119977）。米国政府のサイバーセキュリティの機関 CISA は11月3日（米国時間）、この脆弱性を「悪用が確認された脆弱性」の一覧 KEV に加えました（CISA の KEV）。CVE は脆弱性に付く世界共通の番号です。KEV に付いた11月6日の期限は米国の連邦の行政機関に向けたもので、日本の会社の法的な期限ではありません（CISA の指令 BOD 26-04）。WordPress は、すぐに更新するよう勧めています。

最終更新：2026年11月4日（日本時間）

「うちのサイトは対象なのか」「何をすればいいのか」「もう入られていないか」。今日知りたいのは、この3つだと思います。先に答えを書くと、次の順で動きます。

• 版（バージョン）を確かめる：管理画面の「ダッシュボード」→「更新」か、WP-CLI（WordPress をコマンドで操作する公式の道具）の wp core version で見ます
• 修正版に上げる：7.1 系なら 7.1.4、古い系統ならその系統の修正版に上げます。自動の更新が止まっていないかも見ます
• 入られていないかを確かめる：上げた後に、コアのファイルの照合（wp core verify-checksums）、管理者の一覧、最近できた PHP のファイルを見ます

この記事は、WordPress の告知と HelpHub（WordPress の公式の解説のページ）、米国の脆弱性のデータベース NVD、CISA の一覧と指令を、2026年11月4日時点で確認して書きました。Uravation が運用する WordPress 15 か所で11月4日の朝に確かめたことも載せます。

何が起きたか｜CVE-2026-119977は更新の途中に開く穴

WordPress は10月28日に、セキュリティの更新 7.1.4 を出しました。直した一覧の1番目が今回の穴で、告知は「アップグレードの間（upgrade window）にリモートでコードを実行されうる、WordPress の更新の仕組みの弱さ」と書いています（WordPress の告知）。NVD と CISA の説明では、全部のファイルが入ったパッケージで本体を更新する時（full-package core upgrades）に使う作業用の置き場（staging paths）の場所が予測でき、しかも外（Web）から届くため、ログインしていない攻撃者が、更新している間にサーバーでコードを実行できる可能性があります（NVD・CISA の KEV）。

公式の発表の要点を表にまとめます。

どういう脆弱性か｜更新の時だけ開く窓

たとえるなら、店の改装の間だけ、新しい棚を店の外から手の届く場所に仮置きしていて、その置き場所の見当が外から付いてしまう状態です。普段は閉じている「窓」が、本体の更新が動いている間だけ開き、更新が終わった後はまた閉じます。弱点の種類は CWE-367（確かめた時点と使う時点のずれを突かれる競合状態・TOCTOU）です（NVD・KEV）。

深刻度（CVSS・0〜10で表す物差し）の 8.1 は Wordfence の評価で、内訳は「インターネット越しに届く（AV:N）」「攻撃の条件をそろえるのは難しい（AC:H）」「ログインは要らない（PR:N）」「管理者や社員の操作も要らない（UI:N）」「情報を読まれる・書き換えられる・止められる、のどれも影響が大きい（C:H・I:H・A:H）」です。NVD の画面は11月4日時点で「UNDERGOING ENRICHMENT」（情報を足している途中）で、NVD 自身の評価は「まだ」と表示されています（NVD）。

CISA が NVD に載せた、対応の優先度を決めるための評価（SSVC）では、悪用は「進行中（active）」、攻撃の全部の段を自動で回せるかは「いいえ（no）」、成功した時の影響は「全面（total）」です（NVD の API の記録）。条件がそろいにくい穴でも、すでに使われていると CISA は見ています。

一緒に直った21件

7.1.4 は、今回の穴を含めて22件の脆弱性を直した版です（HelpHub の数え方）。ほかの21件は、寄稿者（Contributor・自分の投稿を書けるが公開はできない権限）以上の権限を持つ利用者が仕込める保存型のクロスサイトスクリプティング（XSS・ページに不正なスクリプトを埋め込まれる穴）が多く、中身は HelpHub の 7.1.4 のページで確かめてください。修正の一覧には、AI の Claude を作る Anthropic が報告者の項目も2つあります。

対象の版と修正版｜4.7〜7.1の系統ごとの表

対象は WordPress 4.7〜7.1.3 です（NVD）。WordPress は最新の 7.1 系に 7.1.4 を出し、古い系統にも同じ修正を戻した版を出しています。告知（10月28日）の時点では古い系統への修正は「準備ができ次第出す」とされていましたが、11月4日に見た HelpHub とリリースの一覧では、4.7 までの各系統の修正版が、どれも10月28日付けで出ています（HelpHub・リリースの一覧）。

系統ごとの修正版は次のとおりです。「22件のうち影響を受ける数」は HelpHub の書き方のまま写し、右の列には NVD に載る今回の CVE の対象の版を並べました（HelpHub・NVD）。

「22件のうち影響を受ける数」は、7.1.4 で直した22件全体の数です。今回の更新の途中の穴は、NVD の対象の版を見ると 4.7 から 7.1 までのどの系統にもあります。4.7〜6.8 の各系統も、4.7 系のように「22件のうち2件」と書かれていても、表の修正版に上げてください。CVE の番号を付けた Wordfence の記録も、直し方として同じ25の修正版を並べています（Wordfence の記録）。

4.6 以前は今回の CVE の対象の版に入っていませんが、HelpHub は、4.6 以前にはもうセキュリティの更新を出さないと書いています。WordPress が積極的に面倒を見るのは最新の版だけでもあります（HelpHub）。古い系統の修正版は急ぎの穴をふさぐ手段として使い、最新の系統へ上げる段取りは別に立てます。

KEVに載ったことの意味｜11月6日は米国の連邦機関の期限

KEV は、CISA が悪用を確認した脆弱性を載せる一覧です。今回の穴は「理屈の上の穴」ではなく、すでに攻撃に使われている穴として扱われています（CISA の KEV・BOD 26-04）。

BOD 26-04 は、米国の連邦の行政機関に向けた拘束力のある指令で、調達の契約で定めない限り委託先の会社にも直接はかからない、と書かれています（BOD 26-04 の Scope の節）。日本の会社に11月6日の義務はありません。それでも、悪用が確認された穴であることは変わりません。日本の会社にとっての意味は「期限」ではなく「急ぐ理由」です。

KEV の注記には、この CVE だけの調べ方は載っていません（11月4日時点・載っているのは告知や NVD などへの案内）。CISA の手引きは、専用の手順が無い時のための一般の手順を示しています（BOD 26-04 の手引き）。

日本の公的な注意喚起は、11月4日13時台に見た範囲では出ていません。JPCERT/CC の注意喚起の一覧（最終更新10月29日）、IPA の重要なセキュリティ情報（いちばん新しい項目は、11月2日に更新された PHP の脆弱性対策）、JVN の新着（11月4日12時の更新まで）に、この脆弱性の項目はありませんでした（JPCERT/CC・IPA・JVN）。IPA は、7月の WordPress の本体の脆弱性（CVE-2026-60137・CVE-2026-63030）では7月22日に注意喚起を出しています。

今日やること｜版を確かめて修正版に上げる

今日やることは3つです。版を確かめ、修正版に上げ、上げた後に入られていないかを確かめます。サイトの保守を外部に任せている会社は、同じ3つを保守会社に頼み、結果（版の番号と、確かめた日時）をもらいます。

1. 版を確かめる：管理画面の「ダッシュボード」→「更新」を開くと、今の版と新しい版の有無が出ます。WP-CLI が使えるなら wp core version で版が出ます。上の表で自分の系統の行にある修正版か、同じ系統の中でそれより新しい版（7.1 系なら 7.1.4 以上）なら、今回の穴は直っています
2. 修正版に上げる：控え（バックアップ）を取ってから（WordPress の更新の文書も最初に勧めています）、管理画面の「ダッシュボード」→「更新」で更新のボタン（英語の画面では「Update Now」）を押すか、wp core update を実行します。終わったら、もう一度版を確かめ、主なページとお問い合わせの送信が動くかを見ます
3. 入られていないかを確かめる：上げた日のうちに、次の節の確かめ方で、コアのファイル・管理者の一覧・最近できた PHP のファイルを見ます

WP-CLI での版の確かめ方と更新のしかた

サーバーで WP-CLI が使える場合のコマンドです。どれも WP-CLI の公式の説明にある書き方です（wp core version・wp core update）。

wp core version
wp core version --extra
wp core update
wp core update --minor

• wp core version は今の版を出します。--extra を付けると、データベースの改訂番号や言語も出ます
• wp core update は、既定で最新の版に上げます
• wp core update --minor は、同じ系統の中の小さな更新だけを当てます（説明の例では、4.3 から 4.4.2 ではなく 4.3.3 へ上げる）。6.9 系のまま 6.9.11 に上げたい時に使えます

自動の更新が止まっていないかを確かめる

WordPress の文書では、本体の更新は「開発版」「マイナー（保守とセキュリティの更新）」「メジャー」の3つに分かれ、既存のサイトはマイナーな更新を既定で自動で受け、5.6 以降で新しく作ったサイトはメジャーな更新も既定で自動です（バージョン管理のフォルダが見つかった場合を除く）。7.1.3 から 7.1.4 への更新はこのマイナーな更新に当たり、告知も「自動の更新に対応したサイトでは、更新は自動で始まる」と書いています（Upgrading WordPress・WordPress の告知）。ただし、次のような設定や状態があると、自動の更新は動きません。

保守会社が手で更新するために、わざと止めていることもあります。その場合は、修正版が出た日に誰が上げるかを決めておきます。更新の結果（成功・失敗など）をメールで知らせる仕組みも既定で動くので（Upgrading WordPress）、7.1.4 への更新の知らせが届いているかも手がかりになります。

レンタルサーバーや保守会社に任せている場合

レンタルサーバーやホスティングの管理ツールにも、WordPress の更新や自動の更新の設定がある場合があります（Upgrading WordPress）。使っている会社の管理画面とお知らせで、今の版と自動の更新の設定を確かめます。WordPress の下で動く PHP の脆弱性（10月）への動き方はPHPの緊急脆弱性（php2shell）｜レンタルサーバーの対応と今やることに、緊急の更新が出た日の一般の動き方（どの層を誰が直すか・一時対策・記録の残し方）はWordPressの脆弱性対応｜緊急の更新が出た日に最初にやることに書いています。

入られていないかの確かめ方｜公式の手順と一般の確認

修正版に上げると、今回の穴はふさがります。ただ、上げる前に入られていた場合、置かれたファイルや作られたユーザーは残ります。CISA も米国の連邦の行政機関には、修正に加えて入られていないかの調べを求めています（KEV の Forensic triage required）。確かめ方を、WordPress と WP-CLI の公式の文書にあるものと、公式の手順ではない一般の確認に分けて書きます。

公式の文書にある確かめ方

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator

• wp core verify-checksums：WordPress.org から今の版のチェックサム（ファイルの指紋のような値）を取り寄せ、コアのファイルと照らします。結果が合わない時は、管理画面の「更新」に出る版と言語に合わせて --version と --locale を付ける（日本語版なら --locale=ja）よう説明されています。--include-root を付けると、フォルダの一番上に WordPress 以外の物があれば警告します（wp core verify-checksums）
• wp plugin verify-checksums --all：入っているプラグインのファイルを、WordPress.org の値と照らします（wp plugin verify-checksums）
• wp user list --role=administrator：管理者の一覧を出します。登録日（user_registered）も出るので、知らない管理者や最近増えた管理者がいないかを見ます（wp user list）

WordPress の FAQ「My site was hacked」は、入られた印として、検索エンジンやセキュリティソフトの警告、サーバーの会社（ホスト）によるサイトの停止、許可していない動き（新しいユーザーの作成など）を挙げています（FAQ My site was hacked）。WordPress のセキュリティの文書は、攻撃は記録（ログ）かファイル（新しいファイル・書き換えられたファイル）に跡を残すと書き、.php のような実行できるファイルに絞って見張る方法も挙げています（Hardening WordPress）。

一般の確認（公式の手順ではありません）

次の3つは公式の手順ではなく、上の考え方に沿って Uravation が使った一般の確認です。サーバーのファイルを見られる担当者か保守会社に頼みます。

• 更新の作業用のフォルダに残った物：wp-content/upgrade（WordPress が更新の作業に使うフォルダ）に、更新が終わっているのにファイルやフォルダが残っていないか。Uravation が見た15か所では、index.php 以外のファイルはありませんでした
• 最近できた PHP のファイル：wp-content/uploads（画像などを置くフォルダ）と wp-content/upgrade に、最近作られた .php のファイルが無いか。プラグインが置く物もあるので、見つけたら作られた日時と中身を保守会社と確かめます
• アクセスの記録：Web サーバーのアクセスの記録（ログ）を消さずに残し、更新した日時の前後に見覚えのないアクセスがないかを見ます。WordPress のセキュリティの文書は、記録があれば、どこから・いつ・何をされたかを追えると書いています

AI に確認を手伝わせる時

AI に読ませるなら、人がコマンドを打ち、その出力だけを渡します。wp-config.php（データベースのパスワードや秘密の鍵が入ったファイル）や .env は渡しません。「中身を表示しないで」と頼んでも、AI が読んだ中身はモデルに送られます。AI のエージェントにサーバーで直接打たせるなら、書き込みと鍵のファイルの読み込みを設定で止め（Claude Code なら permissions の deny）、本番では書き込みの権限の無いアカウントで動かします。AI に CVE の番号や対象の版を要約させた時は、NVD と WordPress の告知で確かめます（AIが作った偽の脆弱性情報｜業務利用前の検証5ステップ）。

入られていたら｜止める・残す・戻す・届け出る

印が見つかった、または見つかったかもしれない時は、あわてて消す前に次の4つを順に進めます。WordPress の FAQ「My site was hacked」と CISA の手引き（米国の連邦の行政機関向け）をもとにした一般の流れで、判断がつかない時は早めに保守会社や専門の会社に相談します。

• 止める：これ以上書き換えられないよう、サイトを外から見えない状態にします（メンテナンスの表示・サーバーの会社に止めてもらう、など）。WordPress の FAQ は、全員（とくに管理者）のパスワードを替え、wp-config.php の秘密の鍵（secret keys）を作り直して、ログインしたままの人を外すよう書いています。置かれたファイルを消したり、ファイルを上書きして戻したりするのは、次の「残す」の後にします
• 残す：見えたこと・気づいた日時（時間帯も）・最近やった作業を書き留め、掃除の前に入られたままの状態の控え（スナップショット）も取ります（WordPress の FAQ）。CISA の手引きも、できる限り記録を集めてから直すよう書いています。アクセスの記録（ログ）は消しません
• 戻す：入られる前の時点の控えから戻すか、同じ版のコアのファイルで wp-admin と wp-includes を置き換えます。WordPress の FAQ は、管理画面からの再インストールではなく、ファイルを置き換える方法を勧めています（新しいファイルを足す種類の攻撃は、上書きでは消えないため）。テーマやプラグインの入った wp-content と .htaccess は、とくに念入りに見ます。掃除が終わったら最新の版に上げ、パスワードをもう一度替えます。データベースのユーザーとパスワードを替えることも検討するよう書かれています（WordPress の FAQ）
• 届け出る：問い合わせフォームの記録などの個人データが漏れたおそれがあれば、個人情報保護委員会への報告が要るかを確かめます。報告が要る時の期限は、速報が発覚日から3〜5日以内、確報が30日以内（不正な目的で行われたおそれがある時は60日以内）です（個人情報保護委員会）。不正アクセスの届出は IPA、対応の依頼は JPCERT/CC、相談は警察の窓口が受けています（IPA の相談・届出窓口・JPCERT/CC のインシデント対応依頼・警察庁の相談窓口）

戻せるかを今のうちに確かめる

WordPress のセキュリティの文書は、定期的にサイト全体の控えを取っていれば、5月1日に入られて12日に気づいた場合でも、入られる前の控えから立て直せる、と例を挙げています（Hardening WordPress）。逆に、更新の前に取ったサイト全体とデータベースの控えが無いと、元の版に戻すことはほぼできない、と更新の文書は書いています（Upgrading WordPress）。次の4点を、入られる前に確かめておきます。

• ファイルとデータベースの両方の控えがあるか（片方だけでは、入られる前の状態に戻せない）
• 控えが、同じサーバーの外の信頼できる場所にもあるか（同じサーバーの中だけだと、一緒に消されたり書き換えられたりしうる）
• 何日前の時点まで戻せるか（入られた日と気づいた日がずれても、入られる前の控えが残っている必要がある）
• 実際に戻す手順を試したことがあるか

サーバーに置いた鍵を替える（AI のサービスを含む）

サーバーでコードを動かされた疑いがあるなら、サーバーに置いた鍵は漏れた前提で替えます。データベースのパスワード、wp-config.php の秘密の鍵、プラグインの設定に入れた AI のサービスや外部のサービス（メールの送信・フォーム・決済など）の API キーです。JPCERT/CC は10月の注意喚起で、ほかのシステムへの侵入で盗まれた API キーが使われる手口を挙げ、「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」と書いています（JPCERT/CC の注意喚起 JPCERT-AT-2026-0030）。AI のサービスの API キーは、使われると料金がかかり、つないだデータに届くこともあるので、サイトの掃除を待たずに先に無効にして作り直す、というのが Uravation の考えです。

Uravationが運用するWordPressで確かめたこと

Uravation は、会社のサイトとメディアを WordPress で15か所運用しています。11月4日の朝に、全部の版と、コアのファイルが WordPress.org の公式のファイルと同じかを確かめました。結果は次のとおりです。

これは、見た範囲で印が見つからなかった、という結果です。データベースの中身、プラグインとテーマのファイル、アクセスの記録までは、この表の確認に入っていません。この結果で「入られていない」と言い切れるわけではありません。

【要注意】よくある読み違い4つ

読み違い1：自動の更新にしていれば何もしなくてよい

❌ 自動の更新が有効なはずだから、版を確かめなくてよい

⭕ 本体のマイナーな更新は多くのサイトで既定で自動ですが、wp-config.php の設定、フィルター、バージョン管理のフォルダ、レンタルサーバーの管理ツールの設定で止まっていることがあります。版は管理画面か wp core version で確かめ、上がった後も入られていないかを見ます

なぜ重要か：自動の更新は穴をふさぐまでで、それより前に置かれた物は消しません。止まっていれば、穴は開いたままです。

読み違い2：プラグインの脆弱性の話だ

❌ プラグインをほとんど入れていないから関係ない

⭕ 今回の穴は WordPress の本体の更新の仕組みにあります。プラグインやテーマの穴ではなく、プラグインの数に関係なく、版が 4.7〜7.1.3 なら対象です（NVD）

なぜ重要か：「WordPress の脆弱性」と聞くとプラグインを思い浮かべる人もいますが、今回は本体の穴です。プラグインの更新は、これとは別に進めます。

読み違い3：7.1.4 に上げればもう大丈夫で、確認は要らない

❌ 7.1.4 になったので、今回の件は終わり

⭕ 修正版は穴をふさぎますが、上げる前に置かれたファイルや作られたユーザーは消しません。CISA も米国の連邦の行政機関に、修正に加えて入られていないかの調べを求めています。上げた日のうちに、コアのファイルの照合・管理者の一覧・最近できた PHP のファイルを見ます

なぜ重要か：KEV に載ったのは、悪用が確認されたからです。上げる前に何が起きたかは、版の番号からは分かりません。

読み違い4：日本の会社も11月6日が期限だ

❌ 11月6日までに直さないと、日本の会社も罰を受ける

⭕ 11月6日は、BOD 26-04 に従う米国の連邦の行政機関の期限です。日本の会社に罰則のある期限ではありません。ただし、悪用が確認されているので、期限を待たずに今日上げます

なぜ重要か：「6日までに間に合えばよい」と読むと、急ぐ理由を見誤ります。見るべきなのは期限の日ではなく、悪用が確認されたという事実です。

Uravationならこう判断する

ここからは Uravation の考えです。今回の穴は、ログインも利用者の操作も要らない（CVSS の PR:N・UI:N）ので、社員への注意や研修では止まりません。更新と確認の仕組みで対応します。

• 本体の自動の更新（マイナー）は切らない：CISA の KEV の JSON（11月3日版）で WordPress の本体の項目を数えると、2026年は7月21日に2件、9月25日に1件、11月3日に今回の1件が加わっています。年に何度も来るものとして自動の更新を基本にし、切っているなら誰が上げるかを決めます
• 上げた日に確かめる：版の確認で終わらせず、wp core verify-checksums、管理者の一覧、最近できた PHP のファイルまでを同じ日に見ます。Uravation の15か所でも、版とあわせて11月4日の朝に見ました
• 鍵の一覧を先に作る：サーバーに置いた API キー（AI のサービスを含む）と、無効にできる人の一覧を作っておきます。疑いが出てから探すと遅れます
• 修正の公開から悪用までが短くなる前提で動く：CISA は BOD 26-04 の背景の節で、攻撃者が AI を使うことで、修正の公開から悪用までに守る側が使える時間がさらに縮みうると書いています。今回も、10月28日に修正が出てから6日後の11月3日に、CISA は KEV に加えています（悪用がいつ始まったかは、11月4日時点で見た KEV・NVD・Wordfence の記録には書かれていません）。修正版が出た日に動ける段取りが要ります

先に決めておくことを表にします。

よくある質問

自分のサイトの WordPress の版（バージョン）と、今回の脆弱性の対象かを確認する方法は？

管理画面の「ダッシュボード」→「更新」か、WP-CLI の wp core version で分かります。どちらも使えない場合は、保守会社やレンタルサーバーの会社に聞きます。7.1 系なら 7.1.4 以上、古い系統ならその系統の行にある修正版以上（同じ系統の中で比べます）なら、今回の穴は直っています（HelpHub）。

レンタルサーバーで WordPress を使っています。自動で更新されているはずですが、何か必要ですか？

版を自分で確かめてください。本体のマイナーな更新は既定で自動ですが、wp-config.php の設定などで止まっていることがあり、レンタルサーバーの管理ツールに別の更新の設定がある場合もあります（Upgrading WordPress）。版が上がっていたら、入られていないかの確認に進みます。サーバーのファイルを見られない契約なら、確認は保守会社かレンタルサーバーの会社に頼みます。

6.9 などの古い系統を使っています。7.1.4 まで上げないといけませんか？

今回の穴をふさぐだけなら、その系統の修正版（6.9 系なら 6.9.11）で足ります。WP-CLI なら wp core update --minor で同じ系統の中だけで上げられます（wp core update）。ただし HelpHub は、WordPress が積極的に面倒を見るのは最新の版だけと書いています。古いプラグインが新しい本体と合わずに表示が崩れることもあるので（Upgrading WordPress のトラブルの節）、最新の系統への移行は検証用の環境で試してから進めます。

更新の途中に開く穴なら、更新しないほうが安全ではありませんか？

いいえ。WordPress は、すぐに更新するよう勧めています（WordPress の告知）。修正版に上げれば今回の穴は直り、7.1.4・7.0.8・6.9.11 では22件すべて、古い系統ではその系統に影響するほかの脆弱性も同じ版で直ります（HelpHub）。古い版のままにすると、どちらも直らないままです。また、自動の更新に対応したサイトでは更新は自動で始まるので、「更新しない」を選んだつもりでも、設定しだいで更新は動きます。版を確かめ、控えを取ってから早めに済ませます。

入られていたかもしれない時、どこに相談すればいいですか？

まず保守会社やレンタルサーバーの会社に知らせ、記録と控えを残します。IPA の企業組織向けの相談窓口は初動の相談と不正アクセスの届出を受け付けています（IPA）。JPCERT/CC はインシデントの対応の依頼を受け付け（JPCERT/CC）、警察庁はサイバー事案の通報と相談の窓口を設けています（警察庁）。個人データが漏れたおそれがある時は、個人情報保護委員会への報告が要るかを確かめます（個人情報保護委員会）。

まとめ

CVE-2026-119977 は、WordPress の本体を更新している間だけ開く穴で、4.7〜7.1.3 が対象です。WordPress は10月28日に 7.1.4 と古い系統の修正版を出し、CISA は11月3日に悪用を確認したとして KEV に加えました。11月6日の期限は米国の連邦の行政機関向けですが、悪用が確認されている以上、今日のうちに版を確かめて修正版に上げ、上げた後にコアのファイルの照合・管理者の一覧・最近できた PHP のファイルを見ます。経営者や部門の責任者は、保守会社に「今の版」「上げた日時」「入られていないかを確かめた結果」の3つを聞くところから始めてください。

あわせて読みたい

• WordPressの脆弱性対応｜緊急の更新が出た日に最初にやること
• PHP脆弱性CVE-2026-109618｜対象版と今日の対応

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・書籍シリーズ累計66,000部）、『AI推進担当になったら読む本』（大和書房）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

今日から始める3つのアクション

• 今日やること：管理画面か wp core version で版を確かめ、表の自分の系統の修正版より古ければ控えを取ってから上げ、上げた日のうちに wp core verify-checksums・管理者の一覧・最近できた PHP のファイルを確かめる
• 今週中：自動の更新の設定（wp-config.php とレンタルサーバーの管理ツール）を見直し、wp plugin verify-checksums --all でプラグインのファイルも照らす
• 今月中：控えから戻せるかを試し、サーバーに置いた鍵（AI のサービスの API キーを含む）の一覧と、修正版が出た日に誰が上げるかを決める

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

参考・出典

• WordPress 7.1.4（WordPress.org News・2026年10月28日）（参照日: 2026-11-04）
• WordPress News の配信（RSS）（7.1.4 の告知の配信の記録 2026-10-28 17:13 UTC を確認／参照日: 2026-11-04）
• Version 7.1.4（WordPress.org HelpHub）（参照日: 2026-11-04）
• Releases（WordPress.org・リリースの一覧）（参照日: 2026-11-04）
• Upgrading WordPress（WordPress Developer Resources・2026年10月28日更新）（参照日: 2026-11-04）
• Hardening WordPress（WordPress Developer Resources・2026年10月14日更新）（参照日: 2026-11-04）
• FAQ My site was hacked（WordPress.org Documentation・2026年7月26日更新）（参照日: 2026-11-04）
• wp core version（WP-CLI Commands）（参照日: 2026-11-04）
• wp core update（WP-CLI Commands）（参照日: 2026-11-04）
• wp core verify-checksums（WP-CLI Commands）（参照日: 2026-11-04）
• wp plugin verify-checksums（WP-CLI Commands）（参照日: 2026-11-04）
• wp user list（WP-CLI Commands）（参照日: 2026-11-04）
• CVE-2026-119977 Detail（NVD）（画面と NVD の API の記録の両方で確認／参照日: 2026-11-04）
• Known Exploited Vulnerabilities Catalog: CVE-2026-119977（CISA）（参照日: 2026-11-04）
• Known Exploited Vulnerabilities Catalog の JSON（CISA・2026年11月3日版）（WordPress の本体の項目の数を確認／参照日: 2026-11-04）
• BOD 26-04: Prioritizing Security Updates Based on Risk（CISA・2026年6月10日）（参照日: 2026-11-04）
• BOD 26-04 Implementation Guidance: Prioritizing Security Updates Based on Risk（CISA）（参照日: 2026-11-04）
• WordPress Core 4.7.0 – 7.1.3 – Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution（Wordfence Intelligence・2026年10月31日更新）（参照日: 2026-11-04）
• 注意喚起 2026年（JPCERT/CC・2026年10月29日更新）（参照日: 2026-11-04）
• 重要なセキュリティ情報 2026年度（IPA）（参照日: 2026-11-04）
• JVN（Japan Vulnerability Notes）（新着の一覧と RSS で確認／参照日: 2026-11-04）
• 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT/CC・JPCERT-AT-2026-0030・2026年10月8日公開・10月23日更新）（参照日: 2026-11-04）
• 漏えい等の対応とお役立ち資料（個人情報保護委員会）（参照日: 2026-11-04）
• サイバーセキュリティ 相談・届出窓口一覧（IPA）（参照日: 2026-11-04）
• インシデント対応依頼（JPCERT/CC）（参照日: 2026-11-04）
• サイバー事案に関する相談窓口（警察庁）（参照日: 2026-11-04）