WordPressの緊急脆弱性「wp2shell」の概要と対応手順｜初心者向けに解説

「wp2shell」と呼ばれる緊急の脆弱性が、2026年7月17日にWordPress本体で見つかりました。プラグインではなくWordPress本体そのものの問題で、ログインしていない第三者にサイトを乗っ取られるおそれがあります。使っているバージョンが6.9.0〜6.9.4または7.0.0〜7.0.1のサイトは、今すぐ6.9.5または7.0.2への更新が必要です。この記事では、セキュリティにくわしくない方でも「何が起きたのか」「自分のサイトは大丈夫か」「今すぐ何をすればいいか」がわかるように、順を追って解説します。

何が起きたのか

2026年7月17日、WordPressの開発元であるWordPress.orgが、緊急のセキュリティ更新版「WordPress 7.0.2」（および6.9.5・6.8.6）を公開しました。深刻度は最上位の「緊急（Critical）」で、危険度を数値で示すCVSSスコアは最大の9.8（10点満点）です。今回見つかった2つの脆弱性を組み合わせた攻撃手法は、発見者によって「wp2shell」と名付けられました。

問題の深刻さは、その後の動きの速さにも表れています。修正版が公開された翌日の7月18日には、攻撃を再現するためのコード（PoCと呼ばれます）がインターネット上に公開されました。しかも、その更新版では「攻撃者が勝手に管理者アカウントを作り出す」処理まで加えられていました。あるセキュリティ企業は、AIのコーディング支援を使って約6分で攻撃コードを再現できたと報告しています。ちょうど日本は7月18日から三連休に入るタイミングで、対応が遅れれば被害が広がりかねない状況でした。

wp2shellの仕組みを、なるべくやさしく

ここは少し技術的な話になりますが、「なんとなくこういうことか」とつかめれば十分です。専門用語も出てきますが、そのつど短い説明をそえていきます。

WordPressには「外部からデータを読み書きする窓口」がある

私たちが普段ブログを書くときは、管理画面にログインして、タイトルや本文を入力欄に打ち込み、公開ボタンをクリックします。これは「人間が画面を見ながら手で操作している」状態です。

ですが、WordPressにはもう一つ、外部のプログラムから記事やユーザーなどのデータを読み書きするための「窓口」が用意されています。これをREST API（レストエーピーアイ）と呼びます。REST APIとは、外部のプログラムからWordPressのデータを読み書きするための窓口のことです。近年はAIがWordPressを操作する連携も、この窓口を通じて行われます。私自身、AIに指示を出して記事を投稿する仕組みを使っていますが、あれもこの窓口を使って、画面を開かずにWordPressへ記事を書き込んでいる状態です。

窓口である以上、正しい命令文さえ送れば、送り主が誰であっても反応してしまいます。だからこそ、この窓口には「受付のチェック」があります。「この操作をする権限がある人か」「送られてきたデータの形式は正しいか」を確認してから処理する仕組みです。

窓口の命令には「見るだけ」と「書き換える」の2種類がある

この窓口に送る命令は、大きく2種類に分けられます。データを見るだけの命令（参照系）と、データを書き換える命令（更新系）です。データを見るだけの命令は、誰でも実行できるように権限が緩く設定されています。一方、ユーザーを追加したりデータを書き換えたりする命令は、権限が厳しく、本来は簡単には通りません。この「緩い命令」と「厳しい命令」の差が、今回の攻撃で悪用されました。

1つ目の穴：他人の「OK判定」を、危険な命令に付け替えられた

今回見つかった1つ目の脆弱性（CVE-2026-63030）は、複数の命令を束ねて一度に送れる「バッチ処理」という機能にありました。本来は、束の中の命令を1つずつ審査し、「命令Aの審査結果はA自身に」「命令Bの審査結果はBに」と正しく結びつけたうえで、通ったものだけを実行します。

ところが今回のバグでは、この結びつきがずれてしまいました。攻撃者は、誰でも通せる緩い命令と、本来なら権限がなくて弾かれる危険な命令を束にして送り込み、緩い命令に出た「OK」という審査結果を、危険な命令のほうに付け替えることができたのです。他人の通行許可証を、自分の危険な荷物に貼り替えて通してしまう、というイメージです。だからログイン（パスワード）を知らなくても、本来は弾かれるはずの操作が実行できてしまいます。

攻撃の具体的な手順については、悪用を防ぐ観点から、セキュリティ各社も詳細を伏せています。私たち運用する側が知っておくべきなのは、手口の細かい中身ではなく、「ログイン不要で入り込まれる経路が存在した」という事実と、それに対して何をすべきかです。

2つ目の穴：データベースへの命令文に、不正な命令を紛れ込ませられた

2つ目の脆弱性（CVE-2026-60137）は、SQLインジェクションと呼ばれるタイプの攻撃です。SQLインジェクションとは、データベースへの命令文に、攻撃者が不正な命令を紛れ込ませる攻撃のことです。WordPressのデータは、記事もユーザー情報もすべてデータベースに保管されています。そこへのやりとりに不正な命令を混ぜ込むことで、本来は見えないはずの情報を引き出したり、データを書き換えたりできてしまいます。

2つの穴がつながると、サイトを乗っ取られる

怖いのは、この2つが連結したときです。1つ目の穴で審査を突破できるようになった攻撃者が、2つ目の穴を使ってデータベースを不正に操作する。これを組み合わせると、最終的にRCE（リモートコード実行）に至ります。RCE（リモートコード実行）とは、攻撃者が遠隔から、サーバー上で好きなプログラムを動かせてしまう状態のことです。ここまで到達されると、サイトの改ざんも、情報の抜き取りも、事実上何でもできてしまいます。

1つ目も2つ目も、単独ではできることが限られています。それが2つ組み合わさることで「ログイン不要でサイト乗っ取り」という最悪の結果になる。この攻撃チェーンが「wp2shell」と名付けられた理由です。

影響を受けるのはどのバージョンか

今回のケースで意外なのは、「新しいバージョンだけが危ない」という点です。1つ目の脆弱性の原因となった不具合は、2025年12月に公開されたWordPress 6.9で初めて持ち込まれました。そのため、6.8系やそれ以前の古いバージョンは、今回の乗っ取りの経路については対象外です。もちろん、WordPressを最新版に保つこと自体は基本であり大切な習慣です。ただ、今回のように新しいバージョンでこそ問題が見つかることもあるため、最新版にしていれば必ず安全、というわけではない、という点は知っておいて損はありません。

使用中のバージョン	乗っ取り（wp2shell）の危険	更新先
6.8.5 以前	この経路では対象外	6.8.6（推奨）
6.9.0 〜 6.9.4	危険（対象）	6.9.5
7.0.0 〜 7.0.1	危険（対象）	7.0.2

なお、6.8系についても関連する脆弱性の一部は含まれているため、更新版の6.8.6が用意されています。どのバージョンであっても、修正版へ更新しておくのが安全です。

今すぐ確認すべき3つのこと

ここからは、実際に手を動かす部分です。順番に見ていきます。

1. 自分のサイトのバージョンを確認する

まずは、いま使っているWordPressのバージョンを確認します。これは管理画面にログインすれば誰でもできます。管理画面の左メニュー「ダッシュボード」を開くと、画面の右下などに現在のバージョンが表示されています。ここが6.9.0〜6.9.4、または7.0.0〜7.0.1になっていたら、今回の対象です。

2. 修正版に更新する（ただし、いきなり押さない）

対象だった場合は、修正版への更新が必要です。ただし、更新ボタンを押すこと自体は簡単でも、いきなり押すのは避けたほうがよい場面があります。WordPressの更新は、まれにプラグインやテーマとの相性で、サイトの表示が崩れることがあるからです。そのため、可能であればまずバックアップを取ってから更新するのが安全です。バックアップの取り方がわからない、更新後の表示崩れが不安、という場合は、制作会社や保守を依頼している業者に相談するのが確実です。ENVY DESIGNでは、他社で制作されたサイトの保守や更新にも対応しています。詳しくはこちらのよくある質問をご覧ください。

なお、今回の脆弱性は深刻度が高いため、WordPress.orgは影響を受けるサイトに対して、自動更新システムを通じた強制的な更新も有効にしています。そのため、自動更新が有効なサイトの多くは、すでに修正版になっている可能性があります。ただし、自動更新をあえて無効にしているサイトもあるため、「自動で更新されているはず」と決めつけず、次の手順で実際に確認することをおすすめします。

なお、本体やプラグインの更新がエラーで進まない場合は、WordPressのプラグインが更新できない原因はファイル所有者のズレ｜FTPでの解決手順で原因の切り分け方を解説しています。

3. 不審な管理者ユーザーが増えていないか確認する

これが今回、特に見落としてはいけないポイントです。前述のとおり、公開された攻撃コードには「攻撃者が勝手に管理者アカウントを作り出す」処理が含まれていました。つまり、更新すれば安心というだけでなく、「更新する前に、すでに侵入されていなかったか」も確認する必要があります。

確認方法はシンプルです。管理画面の左メニュー「ユーザー」を開き、登録されているユーザーの一覧を見ます。そこに、自分たちが作った覚えのないユーザー、とくに権限が「管理者」になっている見慣れないユーザーがいないかをチェックします。もし心当たりのない管理者ユーザーが見つかった場合は、すでに侵入されている可能性があるため、自分で削除して終わりにせず、専門の業者に相談してください。

ENVY DESIGNでの対応

参考までに、今回ENVY DESIGNでどう動いたかをお伝えします。私たちが情報をキャッチしたのは、三連休初日の7月18日でした。その日のうちに、保守契約をいただいているクライアントのサイトを順に確認し、対応を完了しています。

確認してみると、ほとんどのサイトは自動更新によってすでに修正版になっていました。一方で、あえて自動更新を無効にしているサイトもあります。これは、先ほど触れた「更新による表示崩れ」を避けるためです。更新が原因でサイトの見た目が崩れるリスクをコントロールするために、こうしたサイトでは自動更新をオフにし、更新の前に必ず検証する運用にしています。

自動更新を無効にしているサイトについては、まずテスト環境で更新して問題がないことを確かめ、そのうえで本番環境のバックアップを取ってから、本番を更新しました。さらに、今回は攻撃コードに管理者アカウントを勝手に作る動きがあるという情報を得ていたため、各サイトのユーザー一覧に不審な管理者が追加されていないかも確認しました。結果として、不審なユーザーが追加されていたサイトはなく、全サイトを無事に対応し終えることができました。三連休の初日に動いたことで、被害が出る前に間に合った形です。

よくある質問

6.8系など古いバージョンを使っていれば安全ですか？

今回のwp2shellによる乗っ取りの経路については、6.8系以前は対象外です。乗っ取りの原因となる不具合が、2025年12月公開の6.9で初めて持ち込まれたためです。ただし、古いバージョンには別の脆弱性が残っている可能性が高く、「古いから安全」とは言えません。6.8系にも更新版（6.8.6）が用意されているため、どのバージョンであっても最新の修正版へ更新しておくことをおすすめします。

自動更新をオンにしておけば大丈夫ですか？

今回は深刻度が高いため、WordPress.org側で影響を受けるサイトへの強制的な更新が有効化されており、自動更新が有効なサイトの多くはすでに修正版になっているとみられます。ただし、自動更新をあえて無効にしているサイトもありますし、自動更新が有効でも実際に適用されたかは確認したほうが確実です。「オンにしてあるから大丈夫」と決めつけず、管理画面でバージョンを確認することをおすすめします。

更新したら表示が崩れてしまいました。どうすればいいですか？

WordPress本体の更新後にプラグインやテーマとの相性で表示が崩れることは、まれにあります。バックアップを取っていれば、いったん元の状態に戻したうえで、テスト環境で原因を切り分けてから対応するのが安全です。バックアップがない、原因がわからないという場合は、無理に自分で操作せず、制作会社や保守業者に相談してください。表示崩れを避けるために、あらかじめテスト環境で検証してから本番を更新する、という運用が本来は理想的です。

もう攻撃されていたら、どうすればいいですか？

管理画面のユーザー一覧に心当たりのない管理者ユーザーがいる、サイトの表示が見覚えのない内容に変わっている、といった兆候があれば、すでに侵入されている可能性があります。その場合は、自分で不審なユーザーを削除するだけで済ませず、専門の業者に相談してください。侵入の痕跡の調査や、安全な状態への復旧には専門的な対応が必要になるためです。

まとめ

今回のwp2shellは、プラグインではなくWordPress本体そのものに見つかった、深刻度「緊急」の脆弱性です。6.9.0〜6.9.4、7.0.0〜7.0.1を使っているサイトは今回の対象となるため、まずは管理画面でバージョンを確認し、修正版（6.9.5または7.0.2）への更新と、不審な管理者ユーザーがいないかの確認を、できるだけ早く行ってください。

日々の更新や不具合対応、セキュリティ面の運用を任せたい場合は、ホームページ保守・更新サポートをご覧ください。

今回のように、深刻な脆弱性は「見つかったその日のうちに攻撃コードが出回る」時代になっています。だからこそ、日頃からバージョンを最新に保ち、いざというときにすぐ動ける体制があるかどうかが、被害の分かれ目になります。自社サイトのバージョン確認や更新に不安がある方、こうした緊急時の対応を任せられる体制を整えたい方は、ホームページ保守・運用サポートのご案内もご覧いただけます。個別のご相談はお問い合わせよりお気軽にどうぞ。

今回のwp2shellに関する技術的な詳細は、GMO Flatt Security（wp2shellの概要と対応指針）やWordPress.org公式のリリース情報にもまとめられています。

あわせて確認しておきたい設定として、WordPressのXML-RPCとは？無効化すべき理由と実際の対応事例もご覧ください。

WordPressの脆弱性対応やアップデートの実務を外部に任せたい制作会社・代理店の方は、KUROCO コーディング外注でも対応しています。