WordPressコアの緊急脆弱性「wp2shell」──ログイン不要でサイトを乗っ取られる。経営者が今すぐ確認すべきこと

最終更新日：2026年7月20日

2026年7月、WordPressの本体（コア）に、ログインしていない第三者がサイトを乗っ取れる非常に危険な脆弱性が見つかりました。通称「wp2shell」。プラグインの問題ではなく、WordPressそのものの欠陥で、追加のプラグインを一切入れていない標準状態のサイトでも成立します。この記事は、技術に詳しくない経営者・Web担当の方が「自社は大丈夫か」を判断できるように、まず結論と対処を書き、そのあとで技術的な中身を（読みたい人だけが読めるように分けて）正確に解説します。

まず結論──今すぐ確認すべき3つのこと

細かい話の前に、運用している立場の方がやるべきことだけ先に書きます。

• 自社サイトのWordPressのバージョンを確認する。影響を受けるのは 6.9.0〜6.9.4 と 7.0.0〜7.0.1。この範囲なら危険です。
• 修正版に更新されているかを確認する。修正版は 6.9.5 / 7.0.2（6.8系を使っている場合は 6.8.6）。「自動更新が効いているはず」で済ませず、実際に動いているバージョンを目で確認してください。自動更新を切っているサイトには修正が届いていない可能性があります（対象・修正版・強制更新の詳細はWordPress公式のセキュリティリリースで告知されています）。
• 制作・保守を外部に任せているなら、担当会社に「wp2shell（CVE-2026-63030）の対応は済んでいるか」を、できるだけ早く確認する。返答が曖昧なら、それ自体が一つの判断材料になります。

ここまでが「まず動くべきこと」です。以下で、なぜこれほど急ぐ必要があるのかを説明します。

何が起きたのか

WordPressは、世界のWebサイトの相当数を動かしている、いわば「Webサイトの土台」です。今回見つかったのは、その土台そのものにあいた穴です。

WordPressの脆弱性は、あとから追加する「プラグイン（拡張機能）」でも、「テーマ（デザインの土台）」でも、そしてWordPress本体（コア）でも起こり得ます。どれか一つに気をつけていれば安全、というものではありません。今回見つかったのは、その中でも最も影響範囲が広い「本体（コア）」の欠陥です。本体の穴は、どんなプラグイン構成でも、どんなテーマを使っていても、共通して影響を受けます。

そのため今回は、プラグインを一つも入れていない、インストールしたままの標準状態のサイトでも成立します。しかもログイン（管理者アカウント）が一切不要です。攻撃者はIDもパスワードも知らないまま、外から普通のアクセスを送りつけるだけで、最終的にサーバー上で任意のプログラムを実行できてしまう可能性があります。これは「サイトを乗っ取られる」とほぼ同義です。乗っ取られれば、改ざん・情報の抜き取り・別サイトへの攻撃の踏み台化など、何でも起こり得ます。

なぜ今回は特に危険なのか──3つの理由

1. 本体の穴だから、構成を選ばない。プラグインやテーマをどれだけ吟味していても、最小構成であっても影響を受けます。
2. ログイン不要だから、誰でも狙える。総当たりでパスワードを破る必要すらありません。
3. すでに攻撃の「手口」が公開されている。修正版が出た翌日には、攻撃を再現するプログラムがインターネット上に公開されました（詳しくは後述）。つまり「まだ誰も気づいていないから大丈夫」という時間はもうありません。

なお、「世界で5億以上のサイトが危険」といった見出しも見かけますが、これはWordPress全体の設置数であって、危険なサイトの数ではありません。今回いちばん危険な「乗っ取り」まで到達する条件は、6.9系（2025年12月2日リリース）以降を使っているサイトに限られます。とはいえ、該当するなら深刻であることに変わりはありません。

経営者が本当に考えるべきこと──「その仕組み、任せている相手は理解しているか」

ここからは、システム開発を長くやってきた会社としての意見です。

今回のような事故が起きるたびに私が思うのは、WordPressを「気軽に始められるもの」という理解のまま、その中身の構造やセキュリティ上の責任まで軽く見てしまっている現場が多いということです。

WordPressは、確かに気軽に始められます。それは大きな長所です。ただ、「気軽に始められる」ことと「気軽に管理し続けられる」ことは、分けて考えたほうがいいと思います。身近なものにたとえてみます。自転車の整備や、日曜大工でつくる家具くらいなら、多少詳しくなくても自分の手でやってかまいません。壊れても直しはききます。けれども、自動車や、家・ビルのような建築物はそうはいきません。構造を理解した人が設計し、定期的に点検し、不具合が出たら適切に対処する──そうして初めて、安全に使い続けられます。

では、WordPressサイトはどちらに近いでしょうか。見た目こそ手軽ですが、中身にはデータベースがあり、プログラムが動き、外部から常時アクセスを受け付けるサーバーの上で動いています。自転車や家具ではなく、どちらかといえば自動車や建築物の側です。だからこそ問いたいのです。自動車の整備を、内部構造を知らない人に任せていいでしょうか。ビルの設計・施工を、建築の仕組みを知らない人に任せていいでしょうか。WordPressサイトも同じで、「気軽に作れた」ことと「安全に運用し続けられる」ことは、まったく別の話です。

誤解のないように、はっきり書いておきます。私たちはWebサイト制作そのものを否定しているのではありません。WordPressという道具を否定しているのでもありません。WordPressは優れたソフトウェアですし、適切に運用されているサイトは無数にあります。私たちが危ういと考えているのは、構造やセキュリティの仕組みを理解しないまま、「気軽だから」という理由だけで運用の責任を引き受けている（あるいは引き受けさせている）状態です。批判の対象は、道具でも制作という仕事でもなく、この「理解の空白」の部分です。

今日できる現実的な問いは、シンプルです。「うちのサイトを管理しているのは、脆弱性が出たときに自分で判断して動ける人か」。この問いに自信を持って「はい」と答えられないなら、体制を見直す価値があります。

【技術解説】脆弱性の中身──2つの欠陥がどう連鎖するか

（ここから2つの見出しは技術的な詳細です。要点だけ知りたい方は「これから、どう向き合うか」まで読み飛ばしてかまいません。）

「wp2shell」は単独の脆弱性ではなく、2つの脆弱性を連鎖させて成立します。

• CVE-2026-63030：REST APIのバッチ処理（/wp-json/batch/v1）におけるルート混同。パラメータの存在確認・型チェック・権限チェックといった、本来エンドポイント実行前に行われる検証を迂回させる欠陥（攻撃の入口）。
• CVE-2026-60137：WP_Query の author__not_in パラメータに存在するSQLインジェクション。

この2つを組み合わせることで、標準構成のWordPressに対して認証なしでコード実行に至り得ます。

バッチAPIは、複数のリクエストをまとめて処理する仕組みです。今回の欠陥の本質は、配列のインデックスのズレにあります。バッチの中の1つのサブリクエストを意図的に早い段階でエラーにすると、そのエラーは内部の検証用配列には記録されるものの、リクエストとハンドラを対応づける配列（$matches）には積まれません。結果として対応配列が1つ短くなり、以降のリクエストが「隣のリクエスト用の権限チェック・ハンドラ」で処理されてしまうのです。攻撃者はこの並びを操作し、本来は認証が必要な操作を、別の緩いチェックのもとにすり抜けさせます（この配列ズレの詳しい解析は、国内のセキュリティ企業GMO Flatt Securityの検証が参考になります）。

こうして本来の検証をすり抜けた状態で、もう一方の脆弱性──author__not_in のSQLインジェクション（CVE-2026-60137）に到達します。author__not_in は本来「除外する投稿者ID」を配列で受け取り、各要素を整数に変換してから使う想定ですが、配列ではなく文字列（スカラー値）を渡すと、その整数変換を経ずに値がそのままデータベースへの命令に紛れ込みます。バッチのルート混同で検証を迂回して到達すれば、認証なしでこのSQLインジェクションを突けることになります。

この2つを組み合わせると、標準状態のWordPressに対して認証なしでコード実行まで到達し得る──ここまでが、発見者およびセキュリティ各社が確認している事実です。一方で、そこから実際にコードを実行させる「最後の一手」は、攻撃の助長を避けるために各社が意図的に公開を控えています（発見者であるSearchlight Cyber自身も、重大性ゆえ現時点では技術的詳細を公開しないと明言しています）。決め手がSQLインジェクションそのものなのか、迂回した先で本来は権限が必要な機能を呼び出せることなのか、といった内部の詳細も現時点では確定的には公開されていません。本稿でも推測を含めて具体的な手順は書きません。押さえるべきは、「プラグインもテーマも関係なく、素の状態で、認証なしで、乗っ取りに至り得る」という点です。

参考までに影響範囲を整理します。

• 6.8.0〜6.8.5：SQLインジェクション（CVE-2026-60137）のみ影響。バッチの入口が無いため乗っ取りチェーンは成立しない。修正版 6.8.6。
• 6.9.0〜6.9.4：乗っ取りチェーン成立。修正版 6.9.5。
• 7.0.0〜7.0.1：乗っ取りチェーン成立。修正版 7.0.2。

【技術解説】「危険度」の数字をどう読むか

ニュースによって「危険度」の表現がばらついているので、公式の評価を基準に整理します。WordPressの公式では、2つの脆弱性は別々に格付けされています。SQLインジェクション単体（CVE-2026-60137）の深刻度は相対的に低めで、公式のなかでも「Moderate（中）」〜「High（高）」と評価が分かれています。ところが、それがバッチのルート混同と連鎖して乗っ取りに至るチェーン（CVE-2026-63030）になると、最上級の「Critical（緊急）」に跳ね上がります。

一方、ニュースや脆弱性データベースで見かけるCVSSの数値（7.5や9.8など）には幅があります。これは、SQLインジェクション単体を評価しているのか、乗っ取りチェーン全体を評価しているのかで、採点している対象そのものが違うためです。数字の大小に振り回されず、公式が「Critical」とした事実──認証なしで乗っ取りに至り得る、だから最優先で塞ぐ──と受け止めるのが、実務的に正しい読み方です。

すでに攻撃は始まっているのか──そして「パッチ公開＝安全」ではない理由

実際に悪用されているかについては、観測している各社で報告が分かれています。「すでに悪用の試みを確認した」とするセキュリティ企業がある一方、「公式に確認された実被害はまだ無い」とする企業もあり、米CISAの「悪用が確認された脆弱性リスト（KEV）」には本稿時点で未掲載です。ただし、これは「まだ安全」を意味しません。

むしろ注目すべきはスピードです。修正版が公開された翌日には、攻撃を再現する実証コード（PoC）がインターネット上に公開され、防御側（WAFベンダー）も公開当日に対応ルールを配布しています。ここに、私たちが最近ずっと感じている構造変化があります。

かつては、修正版が出てから攻撃が本格化するまでに、数日から数週間の猶予がありました。攻撃者が修正内容を解析し、攻撃コードを組み立てるのに時間がかかったからです。ところが今は、その「修正公開 → 攻撃コード完成」までの時間が急速に縮んでいます。修正の差分は誰でも見られ、その解析や攻撃コードの生成をAIが高速に手伝えるようになったことが、一因として指摘されています。実際、今回の件でも「AIコーディングツールを使えば数分で実証コードを再構成できた」とする報告（※一社の主張で、コード自体は非公開・検証はできていません）まで出ています。

この報告の真偽はさておき、確実に言えるのは、「修正版が出た瞬間から、攻撃側との時間の勝負が始まっている」ということです。「あとで落ち着いたら更新しよう」という先延ばしのコストは、以前とは比べものにならないほど上がっています。

これから、どう向き合うか

今回に限らない、日常の備えとして整理します。

• 更新を「人手のタイミング」に依存させない。今回WordPressは強制的な自動更新を発動しましたが、自動更新を切っているサイトには届きません。更新が確実に当たる運用になっているかを確認してください。
• WAF（Webアプリケーションファイアウォール）やホスティング側の防御を活用する。今回、国内の大手レンタルサーバーがサーバー側で緩和策を講じたように、土台の下でもう一段守る仕組みが有効な場面があります（ただし、これは応急処置であって、更新そのものの代わりにはなりません）。
• 脆弱性が出たときに、誰が・どれくらいの速さで対応できるかを事前に決めておく。体制が決まっていないと、いちばん時間が惜しい瞬間に「誰が対応するのか」から始めることになります。

より根本的には、「そもそも攻撃されやすい部品を最小限にする」という発想もあります。たとえば、更新のたびに管理が発生する動的なCMSに全面依存せず、用途によっては静的なサイト構成を選ぶ、といった選択肢もあります（これはこれで別の記事として掘り下げたいテーマなので、ここでは一つの方向性として触れるに留めます）。

ただ、どんな構成を選ぶにせよ、結局は最初の問いに戻ります。その土台のリスクを理解し、いざというときに自分で判断して動ける人に任せているか。今回の「wp2shell」は、まず該当バージョンなら即更新、というのが答えです。そのうえで、この機会に自社のWeb運用の「任せ方」を一度点検してみてください。

まとめ

• WordPress本体に、認証不要で乗っ取りに至り得る緊急脆弱性「wp2shell」（CVE-2026-63030 / CVE-2026-60137）が見つかった。
• 影響は 6.9.0〜6.9.4 と 7.0.0〜7.0.1。修正版は 6.9.5 / 7.0.2（旧系列は 6.8.6）。該当するなら即更新・実バージョンを目視確認。
• プラグインではなく本体の穴で、素の状態でも成立する。すでに攻撃コードは公開済みで、「修正公開＝安全」ではない。
• この機会に「サイトの土台を、仕組みを理解した人に任せているか」を点検する価値がある。

一次情報

本文中の各記述の出典は、該当箇所にリンクしています。中でも一次情報にあたるのは以下です。

• WordPress公式：WordPress 7.0.2 セキュリティリリース
• GitHub Security Advisory：CVE-2026-63030（RESTバッチのルート混同・Critical）
• GitHub Security Advisory：CVE-2026-60137（SQLインジェクション・Moderate）
• Searchlight Cyber（発見者）：wp2shell 技術ブログ

関連記事

• WordPressサイトのリニューアルという選択肢
• システムの老朽化に気づくためのチェックポイント
• システム開発会社の選び方