技術ブログ
【WordPress】外部から乗っ取られる重大な脆弱性 wp2shell（CVE-2026-63030）── いま確認すべきことと対策
2026年7月、WordPressに「外部からサイトを乗っ取られる」重大なセキュリティホールが見つかりました（CVE-2026-63030、通称「wp2shell」）。公表からわずか数日で世界中に攻撃が広がり、アメリカの政府機関も「実際に悪用されている」と警告を出す事態になっています。
「うちの会社のホームページは大丈夫だろうか？」——そう不安に感じた方に向けて、専門知識がなくても分かるように、何が危険なのか・自分のサイトが対象かどうかの見分け方・今すぐできる対策を、順を追って丁寧に説明します。
1. そもそも何が起きたのか（3行まとめ）
1. WordPressに、パスワードを知らなくてもサイトを乗っ取れる重大な欠陥が見つかりました。
2. 対象は古いバージョン。お使いの系列の最新版（7.0.2 / 6.9.5 / 6.8.6 以降）にすれば安全です。
3. すぐにバージョンを確認し、古ければ更新を。更新できない場合は下記の応急対策を。
2. 「セキュリティホール」ってどういうこと？
ホームページの多くは、WordPress（ワードプレス）という仕組みで作られています。世界のWebサイトのおよそ4割を占めるとも言われる、世界で最も使われているソフトです。記事を書いたり写真を載せたりを専門知識なしでできるのが特長で、弊社が制作するサイトの多くもこれを使っています。
このWordPress本体のプログラムに、今回「鍵のかかっているはずの裏口が、実は開いていた」ような欠陥が見つかりました。これが「セキュリティホール（脆弱性）」です。設定ミスではなくWordPress本体そのものの作りの問題なので、どんなに複雑なパスワードにしていても関係なく侵入されてしまう、という点が今回の特徴です。
3. 今回の脆弱性が特に怖い理由
セキュリティの問題は毎年たくさん見つかりますが、今回のものは次の3点で特に危険度が高いと評価されています。
3-1. パスワード不要で「管理者」になれる
通常、サイトを操作するにはログインが必要です。ところが今回の欠陥を突くと、ログインせずに最高権限（管理者）の操作ができてしまいます。記事の改ざん、ウイルスの設置、顧客情報の抜き取りなど、何でもできてしまう状態です。
3-2. 自動化された攻撃が世界中で動いている
この手の欠陥は、公開されると攻撃プログラムがすぐに出回ります。今回も公表からわずか3日で、世界中のサイトを自動で探し回って侵入する攻撃が観測されました。「小さな会社のサイトだから狙われない」は通用しません。機械が無差別に探しているためです。
3-3. 侵入されると「居座られる」
侵入した攻撃者は、こっそり自分専用の裏口プログラム（Webシェルと呼ばれます）を仕込みます。こうなると、後からパスワードを変えても不正アクセスが続いてしまいます。「入られる前に塞ぐ」ことが何より重要な理由がこれです。
4. これまでの経緯（世界のタイムライン）
WordPress公式が脆弱性（CVE-2026-63030）を公表。修正版も同時に公開されました。
公表からわずか数時間で攻撃の実証コードが出回り、3日で世界規模の無差別スキャンが始まりました。
アメリカの政府機関（CISA）が「実際に悪用されている脆弱性」の公式リストに登録。危険度が最高レベルであることが裏付けられました。
攻撃は継続中。古いバージョンのまま放置されているサイトが狙われ続けています。
5. 【技術解説】この脆弱性の仕組み（じっくり読みたい方向け）
ここからは「なぜパスワードなしで乗っ取れてしまうのか」を、専門知識がなくても追えるように、たとえ話と用語解説を交えてじっくり説明します。少し長くなりますが、1つずつ順番に読めば必ず理解できる内容です。読み飛ばしても、対策（次章以降）には影響ありませんので、興味のある方だけどうぞ。
・REST API（レスト・エーピーアイ）：サイトの外側から「記事を取ってきて」「ユーザーを追加して」などの命令を送れる受付窓口のこと。人が使う管理画面とは別に、プログラム同士が会話するための入口です。
・エンドポイント：その受付窓口の中にある「◯◯係」にあたる、個別の受付URL。
・リクエスト：窓口に出す1件の「依頼書」。
・検証（バリデーション）：依頼書の内容が正しいか（変な値が入っていないか）を確かめる受付での審査。
・SQL（エスキューエル）：サイトの裏にあるデータベース（＝会員情報や記事を保管する倉庫）に「◯◯を出して」「◯◯を書き込んで」と指示する専用の命令文。
・SQLインジェクション：本来はただの入力値であるはずの場所に、この「命令文」をこっそり紛れ込ませ、データベースを不正に操作する攻撃手法。
・RCE（リモートコード実行）：攻撃者が遠隔から、そのサーバー上で好きなプログラムを動かせてしまう状態。乗っ取りの最終形で、最も危険なレベルです。
・欠陥①（CVE-2026-63030）：受付の「審査」を素通りできてしまう抜け道（＝ルート混同）
・欠陥②（CVE-2026-60137）：素通りしてきた値を使って、データベースに命令文を注入できる穴（＝SQLインジェクション）
①で審査を突破し、②でデータベースを乗っ取る。この連携技によって、ログインもパスワードも一切なしで（＝認証の手前で）サイトを完全掌握できてしまう、というのが事の全体像です。
5-1. 攻撃の入口：「まとめて依頼」できる受付窓口
WordPressには、外部から命令を送れる受付窓口（REST API）が用意されています。その中に、バージョン5.6以降「複数の依頼を1回でまとめて処理する」窓口があります。これをバッチ処理（batch＝ひとまとめ、の意味）と呼びます。ネットショップで複数の商品をカートにまとめて一括注文するのに似ています。
POST /wp-json/batch/v1
# ↑この窓口に、依頼書を何枚も束ねて送りつけられる
この窓口は、束ねられた依頼を1枚ずつ順番にさばいて、結果をまとめて返します。ここに今回の落とし穴がありました。窓口の仕事は大きく「①依頼書を審査する」→「②審査を通った依頼を実行する」の2段階なのですが、WordPressはこの①審査と②実行を別々の作業として行っていたのです。「審査したときの依頼書」と「実際に実行される依頼書」が必ず同じものだと信じ切っていた——ここに、両者の解釈をずらして割り込む隙が生まれました。
5-2. 欠陥①：審査した扉と、実際に通る扉が違った（ルート混同）
受付窓口は、依頼書に書かれた宛先（URLのパス）を見て「これは記事係への依頼だな」「では記事係用の審査基準でチェックしよう」と判断します。ところが今回の欠陥では、この宛先の読み取りが「審査のとき」と「実行のとき」で食い違うように仕向けられました。
/）を紛れ込ませるなどの細工をします。すると、審査係は「これは審査対象外の宛先だな」と勘違いして素通りさせてしまう一方で、実行係は同じ宛先を「記事係への依頼」と正しく解釈して実行してしまう——という食い違いが起きます。結果として、本来なら審査で弾かれるはずの危険な値が、ノーチェックのまま実行係に届いてしまうのです。これが「ルート混同」（route confusion＝道／宛先の取り違え）と呼ばれる理由です。門番が見張っている扉と、実際に人が通り抜ける扉が、別々だった——そう考えると分かりやすいと思います。門番（審査）は「怪しい奴は来ていない」と思い込んでいるのに、裏では別の扉から侵入されている状態です。
5-3. 欠陥②：除外リストの穴（author__not_in のSQLインジェクション）
次に、素通りしてきた危険な値がどこで悪用されるかです。WordPressには記事を検索するときに「この投稿者が書いた記事は除外して」と指定できる author__not_in という機能があります（not in ＝「〜の中に無いもの」）。本来は投稿者の番号（整数）をリストで渡す想定で、それを元に「その番号以外の記事を出して」というデータベース命令（SQL）を組み立てます。
new WP_Query([ ‘author__not_in’ => [1, 2, 3] ]);
// ↓ 安全なSQL命令が組み立てられる
// … WHERE post_author NOT IN (1, 2, 3)
// 意味＝「投稿者が 1・2・3 でない記事を出して」
問題は、ここに「番号のリスト」ではなく「ただの文字列」を渡したときに起きました。WordPress側の安全チェックは「リスト形式でなければ何もしない」という作りになっていて、リストでない値が来るとエラーを出すでもなく、黙って無害化処理（サニタイズ）をスキップしてしまったのです。この「静かに素通りさせてしまう」挙動を、専門用語でサイレント・フェイル（黙って失敗）と呼びます。
その結果、攻撃者が用意した文字列は一切の無害化を受けないまま、そのままSQL命令の一部として組み込まれてしまいます。たとえるなら、お店の注文票の「備考欄」に書いた文章が、そのままレジの操作コマンドとして実行されてしまうようなものです。「備考：ありがとう」なら無害ですが、「備考：レジを全部開けろ」と書かれてもそのまま実行してしまう——これがSQLインジェクションの恐ろしさです。
author__not_in に「番号のリストのフリをしない、生の文字列」を送り込めます。無害化されないその文字列がSQL命令に直結するので、データベースに対して攻撃者の好きな命令を注入できてしまう——これが、2つの欠陥が「噛み合う」瞬間です。
5-4. データベース操作から「サイト完全掌握」までの道のり
データベースに命令を注入できるようになると、そこから先は階段を一段ずつ上るように権限を奪っていけます。実際の攻撃で観測された典型的な流れが、これです。
1. batch/v1 の窓口で「審査の素通り」を発生させる（欠陥①）
2. author__not_in にSQL命令を注入する（欠陥②）
3. 注入した命令で 攻撃者用の管理者アカウントを新規作成する
4. その管理者アカウントで、堂々と正規ログインする
5. 管理者権限で ウイルス入りプラグインをアップロードして有効化する
6. プラグイン内のプログラムが動く = RCE（サイト完全掌握）
ポイントは、3で攻撃者が「自分専用の管理者アカウントを作ってしまう」ところです。以降はその正規アカウントで堂々とログインするので、パスワードを破る必要すらありません。そして最後（5〜6）に仕込まれるのが、「Webシェル」と呼ばれる裏口プログラムです。これはサーバー上に居座り続ける合鍵付きの勝手口のようなもので、一度設置されると、後から管理者パスワードを変えても侵入され続けます。攻撃ツールの名前が「wp2shell（wp to shell）」なのは、「WordPressからシェル（この裏口）の奪取まで持っていく」という到達点を表しています。
5-5. 結局なぜ「パスワードが無関係」なのか
ここまでを振り返ると分かる通り、攻撃者は最初から最後まで、一度もログイン認証を通っていません。入口のバッチ窓口（REST API）はログインしていなくても誰でも叩けるうえ、そこから審査の素通り（欠陥①）とデータベースへの注入（欠陥②）だけで、管理者権限を「盗む」のではなく「新しく作り出して」しまうからです。
5-6. 「もう攻撃を受けていないか」を見分ける手がかり（IoC）
すでに侵入されていないかを調べるときは、次のような「侵害の痕跡」が手がかりになります。セキュリティの世界ではこれをIoC（アイ・オー・シー／Indicator of Compromise＝侵害の指標）と呼びます。「泥棒が入った家に残る、こじ開けられた窓や足跡」のようなものだと考えてください。
POST /wp-json/batch/v1 や /?rest_route=/batch/v1 といった不審な通信がある（この窓口は、通常のサイト運営ではまず使われません）・「まとめて依頼」が成功したことを示す HTTP 207 という応答が何度も出ている
・身に覚えのない管理者ユーザーが増えている（データベースの
wp_users / wp_usermeta を確認）・
wp-content/uploads/（画像などの保存場所）や plugins フォルダに、覚えのない .php ファイルがある（裏口プログラム。wp2shell_*.php のような名前が実際に見つかっています）・総当たりされた形跡もないのに、いきなり一発でログイン成功している記録がある
これらは、実際に弊社が対応した侵害事例でも観測されたパターンです。心当たりがある場合は、バージョンを上げるだけでは不十分で、専門家による侵害調査（フォレンジック）と、場合によってはサイトの作り直しが必要になります。判断に迷う場合は、そのままにせず必ずご相談ください。
6. あなたのサイトは対象？ 見分け方
影響を受けるかどうかは、WordPressのバージョンで決まります。
| バージョン | 状態 |
|---|---|
| 7.0.2 / 6.9.5 / 6.8.6 以降 | 安全 修正済みです。各系列の最新版に上がっていればOK |
| 7.0 〜 7.0.1 | 危険 対象です。7.0.2 に更新を |
| 6.9 〜 6.9.4 | 危険 対象です。6.9.5 に更新を |
| 6.8 系（6.8.6より前） | 危険 対象です。6.8.6 に更新を |
| 6.7 以前（さらに古い） | 要確認 今回とは別の脆弱性も抱えている可能性が高く、最新版への更新を強く推奨します |
※ 迷ったら考え方はシンプルです。「お使いの系列の、いちばん新しい版に上げる」——これで今回の脆弱性は防げます。可能であれば最新の 7.0.2 系までの更新をおすすめします。
バージョンの確認方法
WordPressの管理画面にログインすると、画面の一番下（フッター）や「ダッシュボード」に現在のバージョンが表示されています。ご不明な場合は、制作・保守をお願いしている会社に「WordPressのバージョンは今いくつですか？」と聞くのが確実です。
7. 今すぐできる対策
6-1. 【最優先】WordPressを最新版に更新する
これが最も確実で、根本的な解決です。管理画面の「更新」から、WordPress本体を お使いの系列の修正版（7.0.2 / 6.9.5 / 6.8.6）以降に上げてください。これだけで今回の脆弱性は塞がれます。可能であれば最新の 7.0 系までの更新がおすすめです。
6-2. すぐに更新できない場合の応急対策
「今すぐ更新するのは怖い」「動作確認の時間が取れない」という場合の、被害を防ぐための応急的な守りです（専門的な作業になるため、制作会社への相談をおすすめします）。
2. 攻撃の入口になりやすい機能を止める（xmlrpc という外部連携機能など、使っていなければ遮断）
3. ログインを試せる回数を制限する（総当たり攻撃を防ぐプラグインの導入）
4. WAF（ワフ）を有効にする（不正な通信を自動でブロックする防御。レンタルサーバーの管理画面で無料で使えることが多いです）
6-3. 侵入された形跡がないか点検する
すでに侵入されていないかは、次のような点で確認します（これも専門的な確認になります）。
- 身に覚えのない管理者アカウントが増えていないか
- 見慣れないファイルやプログラムが設置されていないか
- サイトに勝手な広告・リンクが埋め込まれていないか
8. 弊社の対応について
弊社（ジェイノーム）で制作・保守をお預かりしているWordPressサイトについては、今回の件を受けて全サイトを緊急点検し、必要な一次対応を実施済みです。具体的には、本体バージョンの確認・更新、管理画面への追加認証、攻撃の入口となる機能の遮断、侵入形跡の点検などを行いました。
「自分のサイトは大丈夫だろうか」とご心配な場合は、遠慮なく担当者までお問い合わせください。バージョンの確認から対策まで、状況に合わせてご案内します。
9. まとめ
セキュリティは「難しそうだから後回し」にしがちですが、今回のように放置した数日間が命取りになるケースもあります。「バージョンを上げるだけ」の一手間が、最大の防御です。この機会に、ぜひ一度ご自身のサイトを確認してみてください。
参考リンク（一次情報）
- WordPress公式ニュース（セキュリティリリース）: wordpress.org/news
- アメリカCISA 悪用中脆弱性カタログ（KEV）: cisa.gov
- 脆弱性番号: CVE-2026-63030（通称 wp2shell）
※本記事はWordPress.org公式発表・米CISA発表などの公開情報を基に作成しています（2026年8月5日時点）。バージョンや対応状況は変動するため、実施前に最新情報をご確認ください。
2026-08-05 作成