--- title: "wp2shell とは何か。WordPress 利用者がまず確認したいこと" canonical_url: "https://olein-design.com/blog/wp2shell-you-need-update-wordpress" language: "ja" date_published: "2026-07-21T10:58:29+09:00" date_modified: "2026-07-21T16:39:07+09:00" content_type: "post" author: "久野晃司" taxonomies: category: - "WordPress" post_tag: - "セキュリティ" --- # wp2shell とは何か。WordPress 利用者がまず確認したいこと WordPress を使っている方に向けて、少し大事なセキュリティの話です。 2026年7月17日に、[WordPress 7.0.2 というセキュリティリリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)が公開されました。あわせて、古いバージョン向けにも WordPress 6.9.5、6.8.6、7.1 Beta 2 が公開されています。 このリリースで修正された問題のひとつが、いま「**wp2shell**」という名前で話題になっている脆弱性です。 セキュリティの話は、どうしても専門用語が多くなります。ですが、今回まず押さえておきたいのは次の点です。 - 特定のプラグインだけの問題ではありません - WordPress 本体に関係する問題です - 対象バージョンを使っている場合は、WordPress 本体の更新が必要です - 対象バージョンだったからといって、すでに被害を受けたという意味ではありません - ただし、放置してよい問題でもありません つまり、必要以上に怖がる必要はありませんが、**「あとで時間があるときに見ればいいか」と先延ばしにするのは避けたい**内容です。 ## 今回の流れを時系列で見る 今回の wp2shell は、突然名前だけが出てきたものではありません。脆弱性の発見、WordPress への非公開報告、修正版の公開、防御ルールの配信、そして外部での解析という流れがあります。 全体像としては、「WordPress 側が修正版を出したことで防御は進んだ一方、オープンソースである WordPress は修正内容から問題の場所も推測されやすいため、攻撃方法の解析も進みやすくなった」と考えると分かりやすいと思います。 | 日付 | 起きたこと | どう受け止めればよいか | | --- | --- | --- | | 修正版公開前 | Searchlight Cyber / Assetnote の Adam Kues 氏が WordPress 本体の問題を発見し、WordPress 側へ非公開で報告 | 攻撃者に先回りされないよう、詳細はすぐには公開されませんでした | | 2026年7月17日 | WordPress が [7.0.2、6.9.5、6.8.6、7.1 Beta 2](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/) を公開 | 対象バージョンを使っているサイトは、WordPress 本体の更新が必要になりました | | 2026年7月17日 | Cloudflare が [WAF ルールを配信](https://blog.cloudflare.com/wordpress-vulnerabilities/) | 更新までのリスクを下げる防御策ですが、WordPress 本体の更新の代わりにはなりません | | 2026年7月17日以降 | [CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf) と [CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q) を組み合わせた攻撃手法が wp2shell として広がる | プラグインではなく、WordPress 本体に関係する問題として注目されました | | 2026年7月18日ごろ | 修正内容をもとに技術的な解析や PoC（脆弱性を実際に再現できることを示す検証コード） が出始める | 修正版公開後は、外部から攻撃方法の解析も進みやすくなります | | 2026年7月20日 | Searchlight Cyber が[発見の経緯や詳細](https://slcyber.io/research-center/exploit-brokers-pay-500000-for-a-wordpress-rce-i-found-one-with-gpt5-6/)を公開 | 管理者が更新する時間を確保したうえで、技術的な説明が公開されました | この流れを見ると、今回「すぐに更新してください」と強く呼びかけられている理由も少し分かりやすくなります。 修正版が出たこと自体は良いニュースです。ただし、修正版が出ると、攻撃者も「どこが直されたのか」を調べられるようになります。だからこそ、修正版が公開されたあとは、できるだけ早く自分のサイトも更新しておく必要があります。 ## wp2shell とは何か wp2shell は、WordPress 本体に存在した複数の脆弱性を組み合わせた攻撃手法の通称です。 公式の GitHub Security Advisory では、主に次の2つの問題として整理されています。 | [CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf) | `WP_Query` の `author__not_in` パラメータに関する SQL インジェクションの問題 | | --- | --- | | [CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q) | REST API の batch route confusion に関する問題。上記の SQL インジェクションと組み合わさることで、Remote Code Execution につながると説明されています | この説明だけだと、なかなか分かりにくいですよね。 少し噛み砕くと、まず **SQL インジェクション**というのは、データベースへの問い合わせに外部から細工した値を混ぜ込めてしまう問題です。WordPress は記事、固定ページ、ユーザー情報、設定などをデータベースに保存しています。そのデータベースに対する「探し方」や「問い合わせ方」を、外部から意図しない形で変えられてしまう可能性がある、というイメージです。 もうひとつの **REST API の batch route confusion** は、WordPress の REST API で複数の処理をまとめて扱う仕組みに関係する問題です。ざっくり言えば、「本来通してはいけない処理の呼び出し方が、別の経路から通ってしまう可能性があった」と捉えると近いと思います。 そして、この2つが組み合わさることで、外部の第三者がログインせずに WordPress サイトへ細工した通信を送り、最終的にサーバー上で不正な処理を実行できる可能性がある、と説明されています。 ここで大事なのは、「管理者のパスワードが漏れたから危ない」という話ではないことです。 また、「危険なプラグインを入れていたから起きる」という話でもありません。**今回の中心は WordPress 本体側の問題**です。そのため、**プラグインをほとんど入れていないサイトでも、対象バージョンであれば確認が必要**になります。 ## 影響を受けるバージョン [WordPress 公式リリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)と GitHub Security Advisory（[CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf)、[CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q)）では、影響範囲と修正版が次のように案内されています。 | 使っている WordPress | 影響 | 更新後バージョン | | --- | --- | --- | | 6.8.0 〜 6.8.5 | SQL インジェクションの影響 | 6.8.6 | | 6.9.0 〜 6.9.4 | SQL インジェクションと RCE につながる問題の影響 | 6.9.5 | | 7.0.0 〜 7.0.1 | SQL インジェクションと RCE につながる問題の影響 | 7.0.2 | | 7.1 Beta | 両方の影響 | 7.1 Beta 2 | | 6.8 より前 | 今回の公式発表上は対象外 | 対象外。ただし古い WordPress の利用自体には別のリスクがあります | 特に注意したいのは、**6.9** 系と **7.0** 系です。 WordPress 6.9.0 から 6.9.4、WordPress 7.0.0 から 7.0.1 は、今回大きく取り上げられている「ログインしていない第三者による Remote Code Execution につながる可能性がある問題」の対象として扱われています。 RCE は Remote Code Execution の略で、日本語では「遠隔コード実行」と訳されることが多いです。これは、外部の攻撃者がサーバー上で何らかのコードを実行できてしまう可能性がある、という意味です。 もう少し身近な言い方をすると、サイトの外側から不正な命令を送り、サーバー側で本来実行されるべきではない処理を動かされる可能性がある、ということです。 成功した場合の影響が大きいため、[WordPress 公式も「すぐに更新すること」を推奨](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)し、対象バージョンに対して自動更新を有効化したと説明しています。 ## 「自動更新されたはず」でも確認した方がいい理由 [WordPress 公式リリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)では、影響の大きさを考慮して、対象サイトに対して自動更新が有効化されたと説明されています。 ただ、自動更新があるからといって、すべてのサイトで確実に更新が完了しているとは限りません。 また、WordPress 公式ドキュメントでも、更新には管理画面から行う方法や自動バックグラウンド更新がある一方で、ファイル権限などの影響を受ける場合があると説明されています（参考：[Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/)）。 たとえば、次のような理由で更新が止まる場合があります。 - サーバー側の権限や設定の都合で更新できなかった - WordPress の自動更新が無効化されていた - 保守運用の都合で、更新を制御している - 更新処理中に何らかのエラーが起きた なので、今回まずやるべきことはシンプルです。 「自動更新されているはず」と思い込まず、実際の WordPress バージョンを確認してください。 ## 個人でもできる確認手順 WordPress の管理画面にログインできる場合は、次の順番で確認できます。管理画面の更新画面については、WordPress 公式ドキュメントの [Dashboard Updates screen](https://wordpress.org/documentation/article/dashboard-updates-screen/) でも説明されています。 1. WordPress の管理画面にログインする 2. 左メニューの「ダッシュボード」を開く 3. 「更新」を開く 4. WordPress 本体のバージョンを確認する 5. 更新が必要な場合は、WordPress 本体を更新する 対象バージョンだった場合は、[WordPress 公式リリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)で案内されている次のいずれかへ更新します。 - 6.8 系を使っている場合は 6.8.6 - 6.9 系を使っている場合は 6.9.5 - 7.0 系を使っている場合は 7.0.2 通常は、管理画面の「更新」から案内される最新版へ更新すれば大丈夫です。 ただし、仕事で使っているサイト、EC サイト、会員制サイト、予約システムなど、止まると困るサイトの場合は、バックアップを取った上で更新するか、保守担当者に相談して進める方が安心です。WordPress 公式ドキュメントでも、更新前にサイトのバックアップを取ることが勧められています（参考：[Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/)）。 ## 制作会社や保守担当者に確認する場合 サイト管理を誰かに任せている場合は、難しい説明を全部理解してから問い合わせる必要はありません。 次のように聞けば、十分伝わると思います。 > wp2shell の件について、WordPress 本体の更新は完了していますか？ > > 現在の WordPress バージョンが 6.8.6、6.9.5、7.0.2 以降になっているか確認をお願いします。 > > もし対象バージョンの期間があった場合、不審な管理者ユーザーやファイル変更、アクセスログの確認も必要か教えてください。 ポイントは、「プラグインを止めれば大丈夫ですか？」ではなく、「WordPress 本体の更新が完了しているか」を確認することです。今回の修正版は [WordPress 本体のセキュリティリリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)として公開されています。 今回の中心は WordPress 本体の問題なので、基本的な対応は WordPress 本体の更新になります。技術的な詳細を確認したい場合は、WordPress の GitHub Security Advisory（[CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf)、[CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q)）を保守担当者と共有すると話が早いと思います。 ## 対象バージョンだったら、すでに侵入されているのか そうではありません。 [WordPress 公式リリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)や GitHub Security Advisory（[CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf)、[CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q)）で影響バージョンに該当していたとしても、**対象バージョンを使っていたことと、すでに被害を受けていることは同じではありません。**無駄に不安を煽る情報発信も散見されます。角度の高い情報を得るようにしましょう。 たとえば、次のような状態はそれぞれ意味が違います。 - 脆弱性の対象バージョンだった - 攻撃できるかを調べるような通信が来ていた - 実際に攻撃の通信を受けた - 攻撃が成功した - サイトが改ざんされた - 管理者ユーザーを追加された - サーバー上に不審なファイルを置かれた これらは全部違います。 ただし、攻撃手法の情報が広がると、インターネット上の WordPress サイトに対して機械的なスキャンや攻撃が増える可能性があります。だからこそ、まず更新。そのうえで、必要に応じて追加確認、という順番が現実的です。 ## 更新後に個人で確認したいこと WordPress 本体を更新したあと、不安がある場合は次の点も確認してみてください。前提として、まずは [WordPress 公式リリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)で案内されている修正版になっているかを確認するのが出発点です。 - WordPress 本体が修正版になっているか - 見覚えのない管理者ユーザーが増えていないか - 最近変更した覚えのないプラグインやテーマファイルがないか - サイトの表示に不自然なリダイレクトや広告が出ていないか - サーバー会社から不審な通信やマルウェア検知の通知が来ていないか - 可能であれば、サーバーのアクセスログに不審なリクエストがないか ここまで見ても不安が残る場合や、長時間対象バージョンのままだった場合は、サーバー会社や保守担当者に相談した方がよいと思います。 個人で運営しているサイトの場合、アクセスログやファイル改ざんの確認は少し難しいかもしれません。その場合は、無理に全部自分で判断しようとせず、ホスティング会社のサポートや保守を依頼している方に相談するのが現実的です。 ## WAF があれば更新しなくていいのか [Cloudflare は今回の件について、WAF ルールを提供していると説明](https://blog.cloudflare.com/wordpress-vulnerabilities/)しています。無料プラン向けの Free Ruleset でも保護が提供されると案内されています。 WAF は Web Application Firewall の略で、Web サイトに届く通信を手前でチェックして、危険そうなものをブロックする仕組みです。 イメージとしては、WordPress の前に立ってくれる警備のようなものです。怪しい通信を止めてくれる可能性があります。 ただし、[Cloudflare 自身も、WAF は更新までのリスクを減らすものであり、脆弱なコードそのものを修正するものではないと説明](https://blog.cloudflare.com/wordpress-vulnerabilities/)しています。 つまり、 - WAF はあると心強い - でも、WAF があるから WordPress を更新しなくてよい、とは考えない - 根本対応は WordPress 本体の更新 という理解がよいと思います。 ## 「永続オブジェクトキャッシュがない場合」という条件について [Cloudflare の説明](https://blog.cloudflare.com/wordpress-vulnerabilities/)では、[CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q) について「persistent object cache が使われていない場合」という条件にも触れられています。 persistent object cache は、日本語では「永続オブジェクトキャッシュ」と呼ばれることがあります。WordPress がデータベースなどから取得した情報を一時的に保存して、次回以降の処理を速くする仕組みです。Redis や Memcached などを使って構成されることがあります。 この条件だけを見ると、「では、自分のサイトが永続オブジェクトキャッシュを使っていれば大丈夫なのでは」と思うかもしれません。 ただ、一般のサイト管理者が、自分の環境条件だけで安全だと判断するのは少し危険です。 そもそも、今回の修正版へ更新すれば問題そのものに対応できます。環境条件を調べて「たぶん大丈夫」と判断するより、WordPress 本体を修正版へ更新する方が確実です。 個人的には、この条件は「技術的な影響範囲を理解するための補足」として受け止め、実際の対応としては更新を優先するのがよいと考えています。 ## 今回の騒動をどう受け止めるか 今回の件は、単なる「WordPress は危ない」という話ではありません。 WordPress 本体に重大な問題が見つかり、責任ある報告を受けて[修正版が公開](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)されました。その後、修正内容や公開情報をもとに攻撃手法の解析が進み、利用者側にも早めの更新が求められる状況になっています。脆弱性の詳細は、WordPress の GitHub Security Advisory（[CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf)、[CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q)）で確認できます。 WordPress は非常に多くのサイトで使われています。そのため、WordPress 本体に関係する脆弱性が出ると、どうしても情報が大きく広がります。 その過程で、不安をあおるような表現も出やすいです。 一方で、今回の問題は「大げさに騒がれているだけ」と軽く見てよいものでもありません。[WordPress 公式がすぐに更新することを推奨し、自動更新も有効化した内容](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)です。 なので、受け止め方としては次のくらいがちょうど良いと思います。 1. 慌てすぎない 2. でも放置しない 3. まず WordPress のバージョンを確認する 4. 対象なら更新する 5. 不安が残る場合は、管理者ユーザーやファイル変更、ログを確認する 6. 自分で判断できない部分は、サーバー会社や保守担当者に相談する ## まとめ wp2shell は、WordPress 本体に関係する重大な脆弱性として扱われている問題です。根拠となる一次情報は、[WordPress 7.0.2 の公式リリース](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/)と GitHub Security Advisory（[CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf)、[CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q)）です。 ただし、「WordPress を使っているすべてのサイトが、すでに侵入された」という意味ではありません。 まず確認すべきことは、自分の WordPress のバージョンです。 - 6.8.0 から 6.8.5 なら 6.8.6 へ - 6.9.0 から 6.9.4 なら 6.9.5 へ - 7.0.0 から 7.0.1 なら 7.0.2 へ 管理画面の「ダッシュボード」から「更新」を開いて、WordPress 本体が修正版になっているか確認してください。操作画面については、WordPress 公式ドキュメントの [Dashboard Updates screen](https://wordpress.org/documentation/article/dashboard-updates-screen/) も参考になります。 自動更新されている可能性はありますが、実際のバージョンを見て確認することが大切です。 セキュリティの話は、必要以上に不安になりやすいものです。ですが、こういうときほど、公式情報を確認し、やるべきことをひとつずつ進めるのが一番現実的だと思います。 まずは WordPress 本体のバージョン確認から始めてみてください。 ## 参考情報 - [WordPress 7.0.2 Release - WordPress News](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/) - [CVE-2026-60137 / GHSA-fpp7-x2x2-2mjf - WordPress GitHub Security Advisory](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf) - [CVE-2026-63030 / GHSA-ff9f-jf42-662q - WordPress GitHub Security Advisory](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q) - [Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities](https://blog.cloudflare.com/wordpress-vulnerabilities/)