2026年7月17日、WordPressの本体（コア）に、深刻度「緊急」の脆弱性が見つかりました。「wp2shell」と呼ばれています。
何が緊急なのか。ひとことで言うと、プラグインを1つも入れていない、ごく普通のWordPressサイトでも、ログイン情報なしに、外部からサイトを乗っ取られる——そういう種類の脆弱性だからです。攻撃に使うコード（PoC）は同じ日に公開され、その翌日には管理者アカウントを勝手に作る処理まで追加されました。セキュリティ企業は、すでに攻撃の試みを観測したと報告しています。
この記事は、2つの読者に向けて書いています。ひとつは「うちのサイトは大丈夫なのか、今すぐ何をすればいいのか」を知りたい方。もうひとつは「そもそもWordPressは危ないのか、これからどう付き合えばいいのか」を考えている方です。
私たちGrowGroupは、これまで1,200社を超える企業のWeb制作・運用に携わってきました。翔泳社からWordPressの解説書を2冊出しており、WordPress日本語コミュニティの運営にも関わっています。作って終わりではなく、動き続けるサイトを守る側の視点で書きます。
まず、今すぐの話から。
目次
wp2shellとは何か——3行でわかる要点
- 対象は、WordPress本体のバージョン 6.9.0〜6.9.4 と 7.0.0〜7.0.1。プラグインやテーマではなく、本体そのものの問題です
- これらのバージョンなら、修正版（6.9.5 または 7.0.2）へ今すぐ更新してください。それだけで、この脆弱性は塞がります
- それより前のバージョン（6.8系以前）は、この脆弱性の直接の対象ではありません。ただし、別の理由で更新は必要です（後述します）
ここから先は、なぜそう言えるのかを順に説明します。急いでいる方は、次の「まず自分のバージョンを確認する」だけ読んで、あとで戻ってきてください。
まず、自分のバージョンを確認する
WordPressの管理画面にログインし、左メニューの「ダッシュボード」→「更新」を開いてください。画面の上部に、今使っているバージョンが表示されます。あるいは、ダッシュボードの右下（「概要」ウィジェット）にも出ています。
確認したバージョンが、次のどれに当たるかを見てください。
| 今のバージョン | 状態 | やること |
|---|---|---|
| 6.9.0〜6.9.4 | 危険（wp2shellの対象） | 今すぐ 6.9.5 へ更新 |
| 7.0.0〜7.0.1 | 危険（wp2shellの対象） | 今すぐ 7.0.2 へ更新 |
| 6.9.5 / 7.0.2 以降 | 対策済み | 問題なし。更新を止めない |
| 6.8.6 | 対策済み（6.8系の修正版） | 問題なし |
| 6.8.5 以前 | wp2shellの直接対象ではない | 別の理由で更新が必要（後述） |
WordPressは今回、強制的な自動更新を有効にしています。そのため、自動更新を止めていない多くのサイトは、すでに修正版へ上がっているはずです。ただし「上がっているはず」で終わらせず、実際にバージョンを目で確認してください。自動更新を切っている、あるいは制作会社の運用ルールで手動更新にしている場合は、上がっていません。
もし対象バージョンで、事情があってすぐに更新できない場合。理想は「今すぐ更新」ですが、どうしても検証の時間が要るなら、その間だけ緩和策のプラグインを入れるという手もあります（Searchlight Cyber社が公開しています）。ただしこれは応急処置で、本筋はあくまで本体の更新です。
技術的に、何が起きているのか
「バージョンを上げればいい」で実務は足ります。ここは、もう少し詳しく知りたい方向けです。飛ばして構いません。
wp2shellは、2つの脆弱性を組み合わせた攻撃手法の名前です。単体ではなく、連鎖させることで威力が出ます。
1つ目（CVE-2026-63030）は、WordPressのREST APIというしくみの中にあります。複数の処理をまとめて実行する「バッチ処理」で、どの要求がどの処理に対応するかの紐づけがずれる不具合です。これにより、本来は呼び出せないはずの処理を動かしたり、入力のチェックをすり抜けたりできてしまいます。
2つ目（CVE-2026-60137）は、投稿を検索する内部のしくみ（WP_Query）にあります。特定のパラメータ（author__not_in）に細工した値を渡すと、SQLインジェクション——データベースに対して意図しない命令を送り込める状態が生じます。
この2つがつながると、ログインしていない外部の攻撃者が、データベースを読み、さらに管理者アカウントを作り、最終的にサイト上で任意のプログラムを実行できるところまで到達します。これが「wp2shell（WordPressからシェル＝乗っ取りへ）」という名前の由来です。
ひとつ補足しておきます。この攻撃が成立するには、サイトが「オブジェクトキャッシュ」（RedisやMemcachedといった、表示を速くするしくみ）を使っていないことが条件だと報告されています。裏を返せば、そうしたキャッシュを本番に入れているサイトは、この経路の条件を満たさない場合があります。ただし、これを「だから安全」と受け取らないでください。キャッシュの設定次第ですし、他の攻撃経路まで塞ぐわけではありません。条件に頼らず、更新するのが正解です。
いちばん重要な事実：これは「新しいバージョンで生まれたバグ」
時系列を見てください。
6.9で混入した脆弱性が、約7ヶ月後の修正リリースと同じ日に攻撃コード公開へ
このバージョンで、今回の脆弱性が作り込まれた
6.9.5 / 7.0.2 が出た同じ日に、攻撃コードが公開された
「約6分で再構成できる」との報告も
セキュリティ企業が、実際の攻撃の試みを報告
出典：piyolog、Rapid7、Patchstack、TechCrunch の解析・報道（2026年7月）。CVE-2026-63030／CVE-2026-60137。
この不具合が作り込まれたのは、2025年12月2日に公開されたWordPress 6.9です。つまり、比較的新しいバージョンにだけ存在する脆弱性です。古い6.8系や、それ以前のサイトは、この特定の穴に関しては影響を受けません。
この事実は、次の章の伏線になります。「とにかく最新にすれば安全」という思い込みが、必ずしも正しくない、という話です。
なぜWordPressは、繰り返し狙われるのか
wp2shellは特別に運が悪い事故ではありません。WordPressの脆弱性は、毎週のように報告されています。理由は、WordPressというソフトウェアの性質にあります。
理由1：世界で最も使われているから。Webサイトの相当数がWordPressで動いています。攻撃する側から見れば、1つの穴を見つければ、世界中の膨大な数のサイトを一度に狙えます。費用対効果が高い標的なのです。
理由2：構造が公開されているから。WordPressはオープンソースで、ソースコードが誰でも読めます。これは改善が速いという長所の裏返しで、攻撃者も同じコードを読んで穴を探せます。今回も、修正版が出たその日に攻撃コードが公開されました。「修正が出た＝攻撃者に穴の場所を教えた」でもあるため、公開から悪用までの時間はどんどん短くなっています。
理由3：放置されたサイトが多いから。これが、制作会社として最も強調したい点です。作ったきり更新されていないWordPressサイトは、世の中に無数にあります。攻撃者が本当に狙うのは、最新版のサイトではなく、更新が止まったサイトです。穴が塞がれないまま、何ヶ月も、何年も放置されているからです。
この章で言えること：WordPressが危険なのではありません。更新されないWordPressが危険なのです。この区別が、次の話につながります。
「とにかく最新にすれば安全」の落とし穴
ここは、制作会社の現場からしか書けない話です。
セキュリティの一般論として、「常に最新版にしましょう」と言われます。基本的には正しい。ですが、今回のwp2shellは、その常識が万能ではないことを示しました。
思い出してください。wp2shellの脆弱性は、2025年12月に出た新しいバージョン6.9で生まれました。もし「新しいものが出たら即座に、検証もせず本番へ適用する」という運用をしていたら、脆弱性が公表されるまでの約7ヶ月間、いち早く危険なバージョンに乗り換えていたことになります。
これは「更新するな」という話ではありません。更新には2種類ある、という話です。
- 機能を増やす大型更新（メジャーアップデート）：6.8から6.9へ、のような大きな更新。新機能が入るぶん、新しいバグも入りやすい。本番へ入れる前に、検証環境で確認する時間を取るべき
- 穴を塞ぐ緊急更新（セキュリティパッチ）：6.9.4から6.9.5へ、のような小さな更新。既知の脆弱性を塞ぐためのもの。これは、ためらわず即座に当てる
今回でいえば、6.9.5や7.0.2は後者です。迷わず即更新すべきものです。一方で、まだ様子を見るべき大型更新もある。この2つを見分けて、当てる速度を変える。これが、サイトを預かる側の運用判断です。「全部即最新」でも「怖いから全部止める」でもありません。
この章で決めること：自社サイトの更新方針が「全部自動で最新」なのか「全部手動で保留」なのか、いま一度確認する。そのどちらも、実は危険です。前者は大型更新の地雷を踏み、後者はセキュリティパッチを取り逃します。分けて運用できているかが、判断の分かれ目です。
制作会社は、WordPressサイトをどう守っているのか
では、数多くのWordPressサイトの保守・運用を預かる立場で、実際に何をしているのか。特別な魔法はありません。地味な運用の積み重ねです。順に書きます。自社でやるにせよ、任せるにせよ、この項目が回っているかが基準になります。
1. 脆弱性の情報を、毎週拾う体制
今回のwp2shellも、気づかなければ対応できません。WordPress本体・プラグイン・テーマの脆弱性情報は、毎週まとまった数が公開されています。それを毎週チェックし、自分たちが使っている部品に該当がないかを突き合わせる体制が要ります。個人サイトで毎週これをやるのは現実的でない、というのが保守契約の存在理由でもあります。
2. バージョンとプラグインの棚卸し
いざ「6.9.0〜6.9.4が危険」と分かったとき、どのサイトがどのバージョンで動いているかを即座に一覧化できるか。これができないと、緊急時に1サイトずつ手作業で確認することになります。何を使っているかを常に把握していることが、対応速度を決めます。
3. WAF（Webアプリケーションファイアウォール）
不審なアクセスを、サイトに届く前でブロックするしくみです。脆弱性が公表されてから更新を当てるまでの、わずかな時間差を埋める防御になります。多くのレンタルサーバーが提供しているので、まず有効になっているかを確認してください。
4. 管理画面の保護と、最小権限
ログインページに総当たり攻撃を許さない（試行回数の制限、二要素認証）。そして、全員に管理者権限を配らない。更新だけする人に管理者権限は要りません。万一アカウントが乗っ取られても、被害を最小限に抑える考え方です。
5. バックアップと、戻せる状態
どれだけ守っても、被害がゼロになることはありません。だから「万一やられても、きれいな状態に戻せる」備えが要ります。定期的なバックアップと、そこから実際に復旧できることの確認。バックアップは「取っている」だけでは不十分で、「戻せる」ことまで確認して初めて意味を持ちます。
6. 定期的な棚卸しと監査
使わなくなったプラグイン、退職者のアカウント、放置されたテーマ。これらは全部、穴になります。定期的に棚卸しして、不要なものを削る。私たちは以前、8年間運用してきた20サイトを全件あらためて調査し直しました。その記録は別記事にまとめています。
本体を更新しても、まだ半分——プラグインとテーマ
ここで、多くの人が見落とす点を書きます。wp2shellは「WordPress本体」の脆弱性ですが、危険なのは本体だけではありません。
実は、wp2shellと同じ2026年7月、プラグインの側でも重大な脆弱性が相次いで公表されています。たとえば、ログイン連携（OAuth／SSO）を提供するあるプラグインでは、深刻度が10点満点中9.8という、本体のwp2shellに匹敵する脆弱性が公表されました。翻訳系や、キャッシュ系の人気プラグインでも、緊急対応が必要なものが出ています。
WordPressは、本体・プラグイン・テーマの3つで成り立っています。本体を最新にしても、プラグインやテーマが古ければ、そこから入られます。むしろ、脆弱性の報告件数でいえば、プラグイン・テーマの方が本体よりずっと多いのが実情です。毎週、数十件の単位で報告されています。
ここで個別のプラグイン名を挙げても、来週には別のプラグインの番になります。だから大事なのは、特定の製品を警戒することではありません。「自分のサイトが、どのプラグインを、どのバージョンで使っているか」を把握し、脆弱性情報と毎週突き合わせることです。使っていないプラグインを消すこと。これが効いてきます。
この章で決めること：プラグインの一覧を開き、使っていないものを無効化ではなく「削除」する。無効化しただけのプラグインも、ファイルが残っていれば攻撃の入口になり得ます。そして、残したプラグインに更新の通知が出ていないかを確認する。
もし、すでに侵入されていたら——確認のしかた
更新は「これ以上入られない」ための対策です。すでに入られていた場合、更新だけでは侵入の痕跡は消えません。対象バージョンで長く運用していて心配な場合は、次の兆候がないかを確認してください。
- 身に覚えのない管理者アカウントがないか。「ユーザー」の一覧を開き、自分たちが作った覚えのないユーザー、特に管理者権限のアカウントがないかを見ます。wp2shellの攻撃コードは、まさにこの「管理者アカウントの作成」を狙っていました
- 身に覚えのない投稿・固定ページがないか。スパムのリンクが埋め込まれた投稿が、勝手に作られていることがあります
- サイトの表示に不審な点がないか。見覚えのないリダイレクト、海外の通販サイトへの転送、文字化けなど
- ファイルが書き換えられていないか。これは専門的な確認になりますが、本体やテーマのファイルに、覚えのないコードが追記されていないか
ひとつでも心当たりがあれば、その時点で自己判断で消すのは避けてください。痕跡を消すと、どこから、どこまで入られたのかが分からなくなります。バックアップからの復旧や、被害範囲の特定は、経験のある相手に相談した方が安全です。
この章で決めること：上の4点を確認する。心当たりがなければ、まずは一安心。あれば、触る前に相談する。
自分でやるか、任せるか
ここまでの6項目を見て、「これを自社で回せるか」を考えてみてください。判断の目安を書きます。
自社で回せる可能性が高いケース：社内にWordPressに詳しい担当者がいて、毎週の脆弱性情報を追える時間があり、検証環境を持っていて、更新の可否を判断できる。この条件がそろうなら、自社運用で十分です。
任せた方がいいケース：担当者はいるが本業と兼任で、脆弱性情報を毎週追う時間はない。あるいは、いざ緊急対応というときに、検証環境も復旧手段もない。この状態で放置されているサイトが、攻撃者にとって最も狙いやすい——これが、この記事で繰り返してきた一点です。
保守を任せる場合、契約内容に「本体・プラグインの更新」「脆弱性の監視」「バックアップと復旧」「緊急時の対応時間」が含まれているかを確認してください。「サーバー代込みで月◯円」だけで、中身が更新を含まない契約も少なくありません。
この章で決めること：今のサイトが「更新され続けているか」を確認する。答えられないなら、それ自体がリスクのサインです。
6.8.5以前のバージョンを使っている方へ
冒頭で「6.8.5以前はwp2shellの直接対象ではない」と書きました。ただし、安心してよいという意味ではありません。
古いバージョンには、wp2shellとは別の、すでに公表されている脆弱性が積み重なっています。今回の穴は避けられても、過去の穴は開いたままです。むしろ、長く更新されていないサイトほど、既知の脆弱性を複数抱えている可能性が高い。
「今回は対象じゃなかった」で終わらせず、これを機に、更新が止まっていないかを点検してください。更新が止まっているなら、なぜ止まっているのか（互換性が不安、担当者がいない、触ると壊れそう）を洗い出すところが出発点です。
よくある質問
更新ボタンを押すだけで、本当に直りますか？
wp2shellに関しては、対象バージョンから修正版（6.9.5 または 7.0.2）へ更新すれば、この脆弱性は塞がります。ただし更新後、実際にバージョンが上がったかを必ず確認してください。まれに更新が失敗して、古いまま残ることがあります。また、すでに侵入されていた場合は、更新だけでは侵入の痕跡（不正な管理者アカウントなど）は消えません。心当たりがあれば、痕跡の調査もあわせて必要です。
更新したら、サイトが壊れないか心配です。
その不安は正当です。だからこそ、更新前にバックアップを取ることが大前提です。特にプラグインを多く使っているサイトは、本体の更新でどこかが動かなくなることがあります。可能なら、本番と同じ構成の検証環境で先に試すのが安全です。とはいえ、今回のような緊急のセキュリティ更新は、「壊れるリスク」より「放置するリスク」の方が大きい局面です。バックアップを取ったうえで、当ててください。
プラグインで対策すれば、更新しなくても大丈夫ですか？
緩和策のプラグインは、あくまですぐに更新できない場合の応急処置です。恒久的な対策は本体の更新です。応急処置に頼り続けると、次の脆弱性で同じ問題を繰り返します。
WordPressをやめれば、この手の問題から解放されますか？
他のCMSや、いわゆるノーコードツールに移れば、WordPress固有の脆弱性からは離れられます。ただし、どんなソフトウェアにも脆弱性はあります。WordPressが狙われやすいのは、シェアが大きく、更新されない放置サイトが多いからです。移行先を検討する価値はありますが、「更新し続ける運用」から逃れられるわけではない点は同じです。乗り換えの判断は、脆弱性だけでなく、機能・費用・運用体制を含めて考えるべきテーマです。
なぜ制作会社が、こんな解説を無料で公開するのですか？
放置されたWordPressサイトが攻撃者に狙われ、実際に被害が出ているからです。私たちは数多くのWordPressサイトの保守・運用を預かる立場として、「作って終わり」ではなく「動き続けるサイトを守る」ことこそが制作会社の仕事だと考えています。その考え方を知っていただくことが、結果的に相談につながればと思っています。
まとめ：今日やること、これから続けること
今日やること：
- WordPressの管理画面で、今のバージョンを確認する
- 6.9.0〜6.9.4 または 7.0.0〜7.0.1 なら、今すぐ 6.9.5 / 7.0.2 へ更新（更新前にバックアップ）
- 更新後、実際にバージョンが上がったかを目で確認する
これから続けること：
- 脆弱性を塞ぐ緊急更新は即座に、機能を増やす大型更新は検証してから。この2つを分けて運用する
- 脆弱性情報の監視・棚卸し・WAF・最小権限・バックアップ・定期監査。この6つが回っているかを点検する
- 自社で回せないなら、更新と監視を含む保守を検討する。「サーバー代込み」だけの契約と混同しない
WordPressが危険なのではありません。更新されずに放置されたWordPressが危険なのです。wp2shellは、そのことを、いつもより短い時間で突きつけてきた事例でした。
自社のサイトが「今どのバージョンで、更新され続けているのか」を答えられない——もしそうなら、それがいちばん先に手を打つべきサインです。私たちは1,200社を超える企業のWeb制作を支援し、翔泳社からWordPressの解説書を2冊出しています。お使いのサイトの状態が分からない、更新が止まっていて不安、という段階からご相談いただけます。
