WordPressの脆弱性はどう対応する？ 2026年のwp2shellから最新の7.1.4までの修正版と、影響の確かめ方・アップデートの進め方

「WordPressの脆弱性のニュースを見たけれど、うちのサイトは大丈夫だろうか」。2026年7月、WordPress本体に「wp2shell」と呼ばれる深刻な脆弱性が見つかり、WordPress.orgは影響を受けるサイトへ強制的にアップデートを配りました。その後も、本体の修正版は9月と10月に続けて出ています。

WordPress本体の脆弱性は、修正版へのアップデートで直ります。ただ、自動更新が止まっているサイトや、古いバージョンの系統のまま動いているサイトでは、修正版が入っていないことがあります。

grandworkでは、WordPressのサイトの保守をお受けしています。保守をお引き受けするときに最初に確かめるのも、WordPressのバージョンと、自動更新が動いているかどうかです。

2026年7月のwp2shellで何が起きたか

wp2shellは、WordPress本体の2つの脆弱性を組み合わせた攻撃です。1つはREST APIの一括処理（batch）の不備（CVE-2026-63030）、もう1つは投稿を取り出す処理（WP_Query）のSQLインジェクション（CVE-2026-60137）です。組み合わせると、ログインしていない攻撃者が、標準の構成のWordPressで任意のコードを実行できるおそれがありました。

WordPress.orgは2026年7月17日に、修正版の7.0.2、6.9.5、6.8.6を公開しました。発表の中で、影響を受けるバージョンのサイトには、自動更新の仕組みを使って強制的にアップデートを配ったと説明しています。2026年の本体の修正版で、強制的に配ったと書かれているのはこの回だけです。

6.8より前のバージョンは、この2件の影響を受けません。

公開から4日後の7月21日には、米国のCISA（サイバーセキュリティ・社会基盤安全保障庁）が、実際に悪用された脆弱性の一覧（KEV）に2件とも載せました。翌22日にはIPAも注意喚起を出し、強制アップデートが無効になっていたり失敗していたりする場合があるとして、管理画面でバージョンを確かめるよう呼びかけています。

クラウドセキュリティのWizは7月20日に、複数の攻撃者による悪用を確認したと報告しました。不正なプラグインのアップロードや、外から操作するためのプログラム（Webシェル）の設置が挙がっています。

SQLインジェクションは、どうやって通ってしまったのか

SQLインジェクションのほうは、WP_Queryの「author__not_in」という引数で起きていました。記事の一覧を出すときに、指定した投稿者の記事を一覧から外すための引数です。修正前のWordPressは、この値が配列で渡されたときは数値に直していましたが、文字列で渡されたときは、そのままSQLの文に組み込んでいました。

たとえば、一覧から外したい投稿者のIDをURLのパラメータで受け取るプラグインが、次のように値をそのまま渡していたとします。

$query = new WP_Query( array(
	'author__not_in' => $_GET['exclude'], // URLの値をそのまま渡している
) );

「?exclude=3」なら、SQLの条件は「post_author NOT IN (3)」になり、投稿者IDが3の人の記事が一覧から外れるだけです。ところが「?exclude=3) OR (1=1」のように、かっこを閉じる文字を混ぜた値を送ると、条件は「post_author NOT IN (3) OR (1=1)」になります。数値だけが入るはずの場所に、SQLの文が通ってしまったということです。

この弱点だけなら、影響を受けるのは、プラグインやテーマが値をそのまま渡しているサイトに限られます。ただ、6.9以降はREST APIの一括処理の不備（CVE-2026-63030）と組み合わさり、標準の構成のWordPressでも、ログインしていない攻撃者が任意のコードを実行できる状態になっていました。修正版では、author__not_inの値が文字列でも配列でも、数値の並びに直してからSQLに組み込むように変わっています。

2026年に出たWordPress本体の修正版

wp2shellのあとも、本体の修正版は続いています。2026年に出た、セキュリティの修正を含む修正版は次のとおりです。

公開日は、WordPress.orgの発表記事の日付です。「悪用を確認」と書いた3回は、CISAが実際に悪用された脆弱性の一覧に載せたものです（7月のwp2shellは2件とも）。CVE-2026-87902は9月25日、CVE-2026-119977は11月3日に追加されました。

10月28日の7.1.4は、深刻度の評価が分かれています。WordPress側はアップデート中の問題を「low」としていますが、米国の脆弱性データベース（NVD）では10点中8.1の「high」です。WordPress側の発表にはCVEの番号が書かれておらず、CVE-2026-119977が7.1.4で直った問題と同じであることは、NVDの説明と参照先から分かります。評価が「low」でも、すでに悪用が確認されているので、7.1.4（またはそれぞれの系統の修正版）に上げておく必要があります。

古いバージョンにも修正版は出るが、サポートは最新版だけ

「最新版にしないと、修正版は入らないのか」と思われるかもしれません。WordPressでは、最新版の修正と同じ日に、古いバージョンの系統（ブランチ）にも修正版が出ます。2026年10月28日の時点で、各系統の修正版は次のとおりです。

ただし、WordPress.orgが公式にサポートしているのは最新版だけです。古い系統への修正は「好意で」戻しているもので、範囲はいまのところ4.7までとされています。WordPress.orgのバージョン確認の仕組みでも、最新版の7.1.4だけが「最新」、各系統の修正版は「古い」と判定されます。

当社では、古い系統の修正版は、最新版へ移るまでのつなぎと考えています。古い系統のままにしている理由（テーマやプラグインが新しいバージョンに対応していない、PHPのバージョンが古いなど）を確かめて、最新版へ移る予定を立てることを勧めています。

自社のサイトが影響を受けるかを確かめる

確かめることは、WordPressのバージョンと、自動更新が動いているかどうかの2つです。

WordPressのバージョンを確かめる

WordPressの管理画面で「ダッシュボード」の「更新」を開くと、いまのバージョンと、新しいバージョンがあるかどうかが表示されます。最新版になっていれば、今後のセキュリティ更新は自動で適用される、という案内が出ます。

サーバーにSSHで入れる場合は、WP-CLI（WordPressをコマンドで操作する道具）でも確かめられます。

wp core version

表示されたバージョンが、上の表の「上げる先の修正版」と同じか新しければ、2026年10月までに出た本体の修正は入っています。

自動更新が動いているかを確かめる

WordPressの自動更新は、多くのサイトで最初から有効になっています。セキュリティの修正を含むマイナーアップデート（7.1.3から7.1.4のような更新）は、既定で自動です。5.6以降に新しくインストールしたサイトは、メジャーアップデート（7.0から7.1のような更新）も既定で自動になります。

ただ、自動更新は、wp-config.phpの設定（WP_AUTO_UPDATE_CORE）や、プラグイン、レンタルサーバーの機能で止められます。自動更新が有効かどうかにかかわらず、管理画面で、バージョンが修正版になっているかを見るのがいちばん確実です。

メジャーアップデートを自動にするかどうかの考え方は、「WordPressのメジャーアップデートは公開されたらすぐ入れる？ 更新の頻度・自動更新の設定・検証環境での進め方」をご覧ください。

プラグインとテーマは別に確かめる

本体を修正版にしても、プラグインとテーマの脆弱性は直りません。プラグインとテーマは、それぞれの開発元が修正版を出し、管理画面の「更新」からそれぞれアップデートします。wp2shellのSQLインジェクションのように、プラグインやテーマの書き方しだいで、本体の弱いところに攻撃が届くこともあります。自社で作ったプラグインやテーマがある場合は、URLやフォームから受け取った値を、数値に直して（absint()やwp_parse_id_list()を通して）からWordPressに渡しているかも確かめてください。

WordPressのアップデートの進め方

修正版になっていなかった場合は、次の順でアップデートします。

1. バックアップを取るデータベースとファイル一式のバックアップを取ります。アップデートのあとに表示が崩れたときに、元に戻せるようにするためです。
2. 修正版へ上げる管理画面の「ダッシュボード」の「更新」から、修正版へアップデートします。古い系統を使っていて、最新版へ一度に上げると表示が崩れそうな場合は、まず同じ系統の修正版へ上げます。
3. 表示と動きを確かめるトップページ、主要なページ、問い合わせフォーム、管理画面のログインを確かめます。ネットショップなら、カートと注文の流れも確かめます。
4. プラグインとテーマも更新する本体とは別に、更新が出ているプラグインとテーマをアップデートします。

修正版にする前に、すでに攻撃を受けていた可能性もあります。Wizの報告では、wp2shellを悪用した攻撃者が、不正なプラグインのアップロードやWebシェルの設置を行っていました。次のどれかに当てはまる場合は、アップデートだけで済ませず、調べる必要があります。

• 身に覚えのない管理者アカウントがある
• 入れた覚えのないプラグインがある
• サイトが真っ白になる、別のサイトへ転送される
• 見覚えのないページや投稿が増えている

当社では、このような場合、ファイルを消したりパスワードを一括で変えたりする前に、いまの状態を保存してから調べます。先に消してしまうと、どこから入られたのかが分からなくなるためです。詳しくは「改ざん復旧・脆弱性対策」をご覧ください。

WordPressのアップデートは誰がするのか

自動更新が動いているサイトでも、アップデートのあとに表示や動きを確かめる人は必要です。自動更新を止めているサイトなら、修正版が出るたびに誰かが上げなければなりません。

サイトを作った会社が保守も受けているなら、まずその会社に、修正版が入っているかを確かめてください。制作の契約が終わっていて、保守の契約がない場合は、誰もアップデートしていないことがあります。レンタルサーバー会社の中には、WordPressの自動更新の機能を用意しているところもあります。ただ、アップデートのあとに表示や動きを確かめるのは、サイトを運用する側です。

社内で担当する場合は、WordPress.orgの発表（日本語版はWordPress.org日本語版のサイト）と、IPAの注意喚起を見ておくと、修正版が出たことに気づけます。担当者がいない場合は、保守を受ける会社に任せることになります。

当社のWordPress保守でお引き受けしていること

当社では、WordPressのサイトの保守を月額でお受けしています。他社が作ったサイトも、状態を拝見したうえでご相談いただけます。

• 本体・テーマ・プラグインの更新修正版が出たら、更新の対象とバックアップを確かめてから更新し、主要なページとフォームの動きを確かめます。
• 毎日のバックアップ毎日1回取得し、データベースは30日分、ファイル一式は3日分を保管します。
• 監視と障害時の一次対応不審な動きがないかを見張り、障害が起きたときは一次対応をします。
• 月次のご報告何を更新したか、いま気になる点はあるかを、毎月お伝えします。

いまのサイトの状態が分からない場合は、保守の前に、脆弱性とマルウェアの点検（1回だけ）から始めることもできます。改ざんや乗っ取りが疑われる場合は、改ざん復旧・脆弱性対策でお受けしています。