【緊急】2026年7月発表
WordPressの脆弱性
2026年7月17日、WordPress 7.0.2・6.9.5・6.8.6が緊急のセキュリティリリースとして公開されました。対象はWordPress公式のリリースノートにある通り2件の脆弱性で、プラグインを一切使っていない標準構成のサイトでも、ログインパスワードを知らなくてもサイトを乗っ取られる恐れがある内容です。Rapid7やQualysなど複数のセキュリティ企業は、この脆弱性の組み合わせを「wp2shell」と呼んでいます。
この問題は、公的なデータベース(NVD)でWordPressの脆弱性としては最上位クラスの深刻度(緊急・Critical)と評価されています。
対象バージョンは6.8.0〜7.0.1です。とくに6.9.0以降を使っている場合は、パスワード不要でサイトを乗っ取られる恐れがある重い方の症状に当てはまります(詳しいバージョン範囲は04章の表で確認できます)。
すでに修正版が公開され、深刻さから自動更新も強制的に有効化されていますが、自動更新を無効化・カスタマイズしている環境は自分で確認・更新する必要があります。米国の政府機関(CISA)は2026年7月21日、実際の悪用を確認したと公表しました。難しい専門用語は後回しにして、まず「何が危険で、何をすればいいか」から見ていきます。
01.まず結論:今すぐ確認すべきこと
詳しい説明の前に、サイト運営者がまず着手すべきことを3点にまとめます。詳しい手順は07章で解説します。
| 優先度 | やること | 確認先 |
|---|---|---|
| ① 最優先 | 管理画面のバージョンが7.0.2 / 6.9.5 / 6.8.6以降か確認し、違えば今すぐ更新する | 管理画面「ダッシュボード」→「更新」 |
| ② 更新できない場合 | WAF(Web Application Firewall)で該当パスへのアクセスを遮断する | 利用中のセキュリティプラグイン・ホスティング事業者 |
| ③ 念のため | 見慣れない管理者アカウントや不審なファイル変更がないか確認する | ユーザー一覧・ファイル更新日時 |
02.何が起きたのか
wp2shellは、プラグインやテーマではなく、WordPress本体(コア)そのものに見つかった問題です。専門用語を使わずに言うと、管理画面にログインしなくても、外部の第三者がサイトの中身を勝手に書き換えられてしまう状態です。心当たりのある不審なメールを開いた、パスワードを使い回していた、といった利用者側の落ち度は関係ありません。サイトが公開されているだけで対象になり得ます。
WordPressはW3Techsの調査によれば全世界のWebサイトの4割超(2026年7月時点で41.2%)で使われている、圧倒的なシェアを持つCMSです。特定の企業や業界に限らず、更新をしていない標準的なサイトすべてが対象になり得る点が、今回の問題を軽視できない理由です。
03.具体的にどんな被害につながるのか
「サイトを書き換えられる」と言われても、実際に何が起こるのかは分かりにくいものです。過去に起きた同種の被害も踏まえ、具体的にどんな被害につながりうるかを整理します。
| リスク | 具体的に何が起こるか |
|---|---|
| サイトの乗っ取り・改ざん | 管理画面にログインしなくても、外部の攻撃者がページの内容を自由に書き換えられる。見た目には気づきにくい改ざんも起こりうる |
| 悪意あるコードの埋め込み | 訪問者のパソコン・スマートフォンをウイルス感染させるコードや、フィッシング詐欺サイトへ誘導する仕掛けが埋め込まれる |
| 検索エンジンからの警告・順位低下 | Googleがサイトを「危険」と判定し、検索結果や訪問時に警告が表示されたり、検索順位が下がったりする |
| 個人情報・顧客情報の流出 | 問い合わせフォームや会員情報を扱うサイトの場合、保存されているデータが盗み見られる恐れがある |
| 迷惑メール送信の踏み台 | サーバーを乗っ取られ、気づかないうちに大量の迷惑メールの送信元として悪用される |
| 気づかないまま被害が継続する | パッチを当てても、事前に仕込まれた裏口(バックドア)が残っていると、被害に気づかないまま長期化することがある |
上に挙げたのは「対応しないまま放置した場合に起こりうる被害」です。修正版はすでに公開されており、正しく対応すれば防げます。次の章以降で対象バージョンと具体的な対応手順を説明します。急いで確認したい方は07章から読み進めてください。
04.影響を受けるバージョンと修正版
影響範囲はバージョン系列によって異なります。軽い方の問題はWordPress 6.8系から、重い方(パスワード不要での乗っ取りにつながる組み合わせ)は6.9系からが対象です。
| バージョン系列 | 影響 | 修正版 |
|---|---|---|
| 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 |
| 6.8.0未満 | 本脆弱性の対象外 | 最新版への更新を推奨 |
自分のサイトがどのバージョンかは、管理画面ダッシュボードの右下、または「更新」画面で確認できます。表示されているバージョンが上記の修正版より古ければ、更新が必要です。なお、6.8.0より前のさらに古いバージョンを使っている場合、今回のwp2shell自体の対象ではありませんが、それだけ長期間セキュリティ更新を受けていないサイトである可能性が高く、別の脆弱性を抱えているおそれがあります。対応が必須ではないとはいえ、この機会に最新版へのアップデートを検討することをおすすめします。
05.発見の経緯とタイムライン
WordPress公式のリリースノートによれば、この問題はAssetnote(Searchlight Cyberの攻撃対象領域管理部門)のAdam Kues氏が、WordPressのHackerOneプログラムを通じて報告しました。もう一方の問題は、TF1T・dtro・haongoの3者が共同で報告しています。報告から修正版公開までの流れは次の通りです。
| 日付 | できごと |
|---|---|
| 2026-07-17 | WordPress.orgが7.0.2・6.9.5・6.8.6を公開。深刻度の高さから自動更新も強制適用 |
| 2026-07-17週末〜 | ハニーポットで悪用の試みを観測(セキュリティベンダー各社の報告) |
| 2026-07-18頃 | セキュリティベンダー各社が技術詳報を公開。概念実証(PoC、実際に攻撃が成立することを示すコード)も公開される |
| 2026-07-21 | 米国の政府機関CISAが「実際に悪用されている脆弱性」の一覧に追加し、悪用を確認したと公表 |
06.悪用状況:KEVカタログ入りとPoC公開
修正版の公開直後から技術的な詳細や概念実証コードが公開されたこともあり、BleepingComputerなど複数のセキュリティ媒体が、公開翌週末から悪用の試みが観測されたと報じています。CISAの既知の悪用済み脆弱性(KEV)カタログにも2026年7月21日付で追加され、米連邦機関に対しては期限内の対応が義務付けられています。「まだ狙われていないから大丈夫」と考えるのではなく、すでに無差別スキャンの対象になっている前提で対応するのが適切です。
Cloudflareは同社の公式ブログで、無料プランを含む全プランのWAFにこの脆弱性向けのルールを展開したと発表しています。Cloudflareを経由しているサイトは、パッチ適用までの時間を稼げる可能性がありますが、WAFはあくまで一時的な緩和策であり、本体の更新を先送りする理由にはなりません。
WordPress運用でよくある10の課題と対策|「作りっぱなし」で失敗しないためのチェックリスト
本体・プラグインの更新停止は、WordPress運用で最も繰り返される失敗の1つです。今回のような緊急パッチを見逃さない運用体制の作り方を整理した記事です。あわせてご覧ください。
パッチ公開からわずか数日で悪用が始まる今回の展開は、WordPressの脆弱性の歴史を振り返ると繰り返し起きてきたパターンでもあります。過去の主要な事例は別記事で詳しく整理しています。あわせてご覧ください。
WordPressの脆弱性の歴史|15年間の主なハッキング事例と教訓
TimThumb(2011年)からwp2shell(2026年)まで、15年間の主要インシデントを年表で振り返り、プラグイン同梱コードの脆弱性・パッチ公開後も残る未更新サイト・公表から悪用までの短さという共通パターンを整理した記事です。
07.今すぐやるべき対応
対応は「バージョン確認」「更新(または緩和策)」「侵害有無の確認」の3ステップです。技術者がいないメディア担当者でも、以下の順番で進めれば判断できます。
自動更新の状況を確認する
WordPressはマイナーバージョン(今回のような7.0.1→7.0.2)を既定で自動更新する仕組みを持っており、今回はさらにWordPress.org側が強制的に自動更新を有効化する措置を取っています。管理画面の「ダッシュボード」→「更新」で、現在のバージョンが7.0.2・6.9.5・6.8.6のいずれか、またはそれ以降になっているかを確認しましょう。レンタルサーバーやマネージド型のホスティングを使っている場合も、念のため管理画面で実際のバージョンを目視確認するのがおすすめです。
手動アップデートが必要なケース
次のような環境では自動更新が効かず、手動での対応が必要です。
| 状況 | 対応 |
|---|---|
| 自動更新をプラグインや設定で無効化している | 管理画面「更新」から手動でコアを更新する |
| 本体のコードを直接カスタマイズし、独自管理している | 開発担当・外注先と連携し、差分を確認したうえで更新する |
| 複数サイトをまとめて管理している | サイトごとにバージョンを一覧化し、更新漏れがないか確認する |
すぐにパッチを当てられない場合の緩和策
社内承認や検証環境でのテストに時間がかかり、即日更新が難しい場合は、次の緩和策で被害を抑えられます。あくまで一時しのぎであり、更新の代わりにはならない点に注意してください。
| 緩和策 | 内容 |
|---|---|
| WAFでの遮断 | /wp-json/batch/v1 と ?rest_route=/batch/v1 の両方のパターンを、Web Application Firewallで遮断する |
| 不審な外部アクセスの制限 | ログインなしでの一括データ操作リクエストを拒否するセキュリティプラグイン・設定を一時的に導入する |
| CDN/WAFサービスの活用 | Cloudflareなど、脆弱性対応ルールを展開しているサービスを利用している場合は適用状況を確認する |
08.よくある誤解
| 誤解 | 実際 |
|---|---|
| プラグインの脆弱性だから、プラグインを止めれば防げる | WordPress本体(コア)の脆弱性で、プラグインの有無は関係ない。標準構成だけで成立する |
| 自動更新が有効だから確認不要 | 自動更新を無効化・カスタマイズしている環境では適用されない。バージョン表示での目視確認が必要 |
| 小規模サイトは狙われない | 攻撃はサイト規模に関係ない自動スキャンで行われるため、規模は防御にならない |
| PoCが出回っているから、今から更新しても手遅れ | 手遅れではない。更新前のサイトが今も狙われ続けているため、未更新なら今すぐの対応が最優先 |
09.よくある質問(FAQ)
wp2shellはプラグインの脆弱性ですか?
いいえ。WordPress本体(コア)の脆弱性で、プラグインやテーマは無関係です。本体の内部処理に見つかった2つの問題が組み合わさることで、プラグインを何も使っていない標準構成のサイトでも、パスワードなしでの乗っ取りにつながります。技術的な仕組みは11章で詳しく解説しています。
自動更新を有効にしていれば、何もしなくて大丈夫ですか?
多くの環境では自動的に修正版へ更新されているはずです。ただし自動更新をプラグインや設定で無効化している場合、本体を直接カスタマイズして独自管理している場合は適用されません。管理画面の「ダッシュボード」または「更新」でバージョンを目視確認するのがおすすめです。
まだ更新していません。今から何をすればいいですか?
管理画面の「更新」から、今すぐWordPressを7.0.2(6.9系なら6.9.5、6.8系なら6.8.6)以降に更新しましょう。社内承認や検証に時間がかかりすぐ更新できない場合は、WAFで/wp-json/batch/v1と?rest_route=/batch/v1へのアクセスを遮断する緩和策を先に導入します。
すでに攻撃を受けていないか、どう確認すればいいですか?
見慣れない管理者アカウントが追加されていないか、テーマ・プラグインのファイルが不自然な日時で更新されていないかを確認します。心当たりのある変更が見つかった場合は、パスワードの再発行やバックアップからの復旧、必要に応じて専門業者への調査依頼を検討しましょう。
今後もこうした緊急パッチは起こりますか?
起こり得ます。WordPressに限らずソフトウェアである以上、脆弱性の発見と修正は継続的に発生します。1回の対応で終わらせず、本体・プラグインの更新を継続する運用体制を持つことが欠かせません。更新が止まりがちなWordPress運用の課題はWordPress運用でよくある10の課題と対策で整理しています。
10.まとめ
wp2shellは、WordPress本体に見つかった2つの問題が組み合わさることで、標準構成のサイトでもパスワードなしで乗っ取られてしまう脆弱性です。すでに修正版(7.0.2・6.9.5・6.8.6)が公開され、CISAが実際の悪用を確認したと公表するほど事態は深刻です。まず管理画面でバージョンを確認し、未更新であれば今すぐの更新を、更新できない場合はWAFでの遮断を優先しましょう。
今回のような緊急パッチを見逃さずに済むかどうかは、日頃の更新運用が整っているかで決まります。本体・プラグインの更新が止まりがちなWordPressサイトの運用課題は、WordPress運用でよくある10の課題と対策でチェックリスト形式にまとめています。
11.技術的な仕組み(詳しく知りたい方向け)
ここから先は、なぜこの脆弱性が成立するのかという技術的な仕組みを知りたい方向けの内容です。読まなくても、対応そのものには支障ありません。
技術的な仕組みwp2shellが成立する4つの段階を見る
攻撃が成立するまでの流れを、NVD(National Vulnerability Database)の説明をもとに4段階に整理します。攻撃の再現に使えるような具体的なリクエストの中身には触れず、防御に必要な「どこで何が壊れているか」に絞って解説します。
- 1未認証のリクエスト
ログイン不要のREST APIバッチ処理エンドポイント(/wp-json/batch/v1)に、細工したリクエストが送られる。
- 2ルートの混同
バッチ処理は複数のリクエストを検証する配列と実行する配列を別々に持つ。一部の処理で片方の配列だけがずれ、以降のリクエストが本来とは別のハンドラで実行されてしまう。
- 3SQLインジェクション
ずれた実行経路が、WP_Queryの検索条件を指定するauthor__not_inパラメータに未検証の入力を渡し、データベースへの問い合わせ文が改ざんされる。
- 4任意のコード実行
改ざんしたデータベース問い合わせを足がかりに、ログインなしでサーバー上のコードが実行される。
どちらか一方だけなら影響は限定的だが、連鎖すると認証を一切必要としないRCEに発展する。
REST APIバッチ処理のルート混同(CVE-2026-63030):WordPressのREST APIには、複数のリクエストをまとめて処理する「バッチ」機能があります。この処理は「各リクエストが妥当かを検証する工程」と「実際に実行する工程」を別々の配列で管理していますが、いずれかのサブリクエストでURLの解析に失敗すると、エラーが片方の配列にだけ記録され、もう片方には記録されません。結果として2つの配列がずれ、以降のリクエストが意図しないハンドラに渡ってしまいます。CVSS v3.1で9.8(Critical)、認証不要・ユーザー操作不要という高スコアが付いているのは、このロジックの誤りだけで攻撃の入口が開いてしまうためです。
WP_Queryのパラメータを狙うSQLインジェクション(CVE-2026-60137):CVE-2026-60137は、投稿を検索するWP_Queryのauthor__not_inパラメータが原因のSQLインジェクションです。このパラメータ単体は、配列ではなく文字列を受け取った際の検証が甘く、プラグインやテーマがここへ未検証の入力を渡して初めて悪用が成立する、比較的限定的な脆弱性でした。単独評価では中程度のスコアにとどまるという指摘がある一方、CVE-2026-63030のルート混同と組み合わせると、プラグインが1つも無い標準構成でもこのパラメータへ到達できてしまい、深刻度の評価が大きく変わります。2つのCVEが別々の会社から報告されていながら同時に修正されたのは、この組み合わせによる相乗効果が理由です。
自社サイトの更新確認や緩和策の導入判断に技術者のリソースを割けない場合、対応そのものを外部に任せる選択肢もあります。弊社では、AIをフル活用したWordPress運用の保守・監視・改善までを伴走支援しています。
WordPressサイトの保守・セキュリティ対応をご相談ください
弊社では AI フル活用の運用保守・記事更新・計測改善までを提供しています。今回のような緊急パッチ対応を含む安全な運用体制のご相談は、お気軽にお問い合わせください。

