WordPress本体に「認証不要の乗っ取り」脆弱性 — wp2shell が突きつける、更新し続けられないサイトの限界

対象読者:

WordPressで自社サイトを運用している経営者・担当者、とくに更新頻度が低い・ページ数が少ないサイトをお持ちの方

この記事で分かること:
2026年7月に公表された「wp2shell」脆弱性が何を意味するのか、なぜ「プラグインを入れていないから安全」が通用しないのか、そして更新し続けられないサイトの現実的な逃げ道

はじめに — 今回は「プラグイン」ではなく「WordPress本体」が破られた

これまで当社ブログでは、WordPressの被害の大半はプラグイン起因であること、そしてAI時代には放置サイトが数分で乗っ取られることをお伝えしてきました。

2026年7月、その前提を揺るがすニュースが出ました。WordPress "本体" に、認証不要で遠隔からサーバーを乗っ取れる脆弱性が見つかったのです。

IPA（情報処理推進機構）は2026年7月22日、これを緊急の注意喚起として公表しました。セキュリティ企業 GMO Flatt Security のリサーチチームが「wp2shell」と名付けたこの攻撃は、「プラグインを最小限にしているから大丈夫」という、多くの堅実な運用者が信じてきた常識すら通用しないことを示しています。

この記事では、専門知識がない方にも分かるように、何が起きたのか・なぜ怖いのか・どうすればよいのかを整理します。

1. wp2shell とは何か — 一言でいうと「ログインせずに乗っ取れる」

セキュリティの世界で最も危険とされる脆弱性のタイプが Pre-Auth RCE（認証不要のリモートコード実行） です。分解すると次の意味になります。

• Pre-Auth（認証不要）: IDもパスワードも要らない。誰でも実行できる
• RCE（リモートコード実行）: 攻撃者が、あなたのサーバー上で好きなプログラムを動かせる

つまり wp2shell は「ログイン画面を突破する必要すらなく、いきなりサーバーの中身を乗っ取れる」 脆弱性です。ファイルの盗み見、改ざん、バックドア設置、他サイト攻撃の踏み台化 — サーバーでできることは、ほぼ何でもできてしまいます。

しかも今回やっかいなのは、単体では無害に見える2つの弱点を"組み合わせる"ことで成立するという点です。

この2つを鎖のようにつなぐと、「検証のすり抜け」で「本来届かない攻撃」を送り込めるようになり、結果として認証なしのRCEが完成します。攻撃を成立させる鍵の掛け違いが、複数の部品の合わせ技で起きた、というわけです。

2. 「標準構成でも」危険 — ここが今回いちばん重要

過去の多くのWordPress脆弱性は、「特定のプラグインを入れていると危ない」「特定の設定だと危ない」という条件付きでした。だから「余計なものを入れていないうちは大丈夫」という防御が、ある程度は機能していました。

wp2shell はそれが通用しません。GMO Flatt Security の分析でも、IPAの注意喚起でも、「標準構成でも、管理者の認証情報を要さずにリモートから任意コード実行が可能」 と明記されています。

言い換えれば、プラグインを一切入れていなくても、WordPressをインストールして普通に公開しているだけで危ないということです。「シンプルに使っているから安全」だと考えていた、堅実な運用者ほど盲点を突かれる形になりました。

影響を受けるバージョン

6.9系・7.0系を使っていて、まだ更新していないサイトは、いま危険な状態にあると考えてください。

※そもそも6.9以前のバージョンを使い続けている場合は、他の脆弱性が残っている場合が多いので、要注意です！

3. なぜ「今すぐ」なのか — 攻撃はもう始まっている

「脆弱性が見つかった」だけなら、慌てずに対応すればよい場合もあります。しかし今回は状況が違います。

• 実証コード（攻撃の実演コード）が既に公開済み — 誰でも参照できる状態です
• 2026年7月21日、米CISA（サイバーセキュリティ・インフラ機関）が「悪用された脆弱性」の公式カタログ（KEV）に登録 — これは「理論上の危険」ではなく「現実に攻撃が観測された」という意味です
• パッチ公開は2026年7月17日、ブログ公表は7月18日。日本の三連休（7月18〜20日）中に被害が拡大する懸念が名指しで指摘されました

前回の記事でお伝えしたとおり、いまや攻撃は人間ではなくAI連携の自動ボットが24時間走らせています。公開された実証コードは即座に攻撃ツールへ転用され、脆弱なバージョンのWordPressを無差別に探し回っています。「うちみたいな小さいサイトは狙われない」は、すでに通用しません。

4. 今すぐやるべきこと — 更新は「待ったなし」

対策はシンプルで、修正済みバージョンへ直ちに更新することです。

1. WordPress管理画面の「ダッシュボード > 更新」を開く
2. WordPress本体のバージョンを確認し、上表の修正版へ更新する
3. 自動更新を有効にしていても、本当に当たっているか手動で確認する（自動更新が止まっているサイトは珍しくありません）

すぐに更新できない事情がある場合の緊急避難策として、Flatt Security は以下も挙げています（あくまで一時しのぎで、根本対策は更新です）。

• WAF（Webアプリケーションファイアウォール）で、攻撃の入り口となる /wp-json/batch/v1 および /?rest_route=/batch/v1 へのアクセスを遮断する
• REST APIのバッチ処理への未認証アクセスを拒否する

…ただ、正直に申し上げると、この緩和策を自力で正しく設定・検証できる運用体制がある会社は、そもそもこの脆弱性を放置していません。 ここに、今回の本当の問題があります。

5. 本当の問題 — 「更新し続ける」こと自体が、多くのサイトには重すぎる

今回の教訓は「更新しましょう」で終わりません。もっと構造的な問題を突きつけています。

以前の記事「WordPressアップデート管理の重要性と、現場がハマる落とし穴」で詳しく書いたとおり、WordPressの更新には現場ならではの難しさがあります。

• 更新するほど壊れる可能性が上がる — デザイン崩れ、機能停止、画面真っ白（WSOD）
• 「動いているものを触りたくない」心理 — 止められないサイトほど放置に傾く
• 判断できる人が社内にいない — 「これは当てて大丈夫な更新か？」を誰も決められない

そして今回のように、プラグインを減らして堅実に運用していても、WordPress本体そのものに認証不要RCEが出る。「余計なものを入れない」という王道の防御すら、絶対ではなくなったのです。

すると、こういう問いが避けられなくなります。月に数回しか更新しない会社案内サイトのために、こまめにバージョンを追いかけ、緊急パッチが出るたびに三連休返上で対応する体制を、本当に維持できますか？

WordPressは、頻繁に更新し・多機能を活かし・保守にコストを払える組織にとっては、今も優れた選択肢です。しかし 「更新頻度が低い」「ページ数が少ない」「凝った機能は要らない」サイトにとって、WordPressの保守負担は、得られる価値に対して明らかに重すぎます。 そして、その重さが放置を生み、放置が今回のような致命的リスクを招きます。

6. もう一つの選択肢 — 「攻撃対象が存在しない」CMSという発想

ここで発想を変えてみます。そもそも 「認証不要でサーバーを乗っ取られる」のは、公開サーバー上に"動くプログラム（ログイン機能・データベース・管理画面）"が置いてあるから です。攻撃者は、その動くプログラムの穴を突きます。

では、公開サーバー側に「攻撃できるプログラム」を置かなければどうなるか。これが、当社が開発・運用している スプレッドシートCMS（スプシCMS）の考え方です。

スプレッドシートCMSの仕組み（ざっくり）

• 記事や情報の入力は、使い慣れたGoogleスプレッドシート上で行う
• ボタン一つで、内容が暗号化されて安全に送信され、サイトに反映される
• 公開サーバー側には、WordPressのような「ログイン画面」も「管理画面」も「データベース」も存在しない

つまり、wp2shellのような「管理画面やREST APIを突く攻撃」は、そもそも狙う対象がありません。ログイン機能がなければログインは突破されず、公開側にデータベースがなければSQLインジェクションも成立しません。攻撃の入り口そのものを無くす、という考え方です。

こんなサイトに向いています

• 会社案内・店舗紹介・サービス紹介など、更新頻度が月に数回程度のサイト
• お知らせ・ブログ・実績紹介など、更新箇所がある程度決まっているサイト
• 凝ったWeb機能（会員制・ECの高度なカスタマイズ等）は必要としない
• 「セキュリティ更新に毎回追われる運用から解放されたい」 と感じている

逆に、日々複雑な機能追加を行う・大規模なECを高度にカスタマイズする、といった用途では、今もWordPressや専用開発のほうが適しています。私たちは「WordPressを全否定する」つもりはありません。 ただ、多くの中小企業のコーポレートサイトは、そこまでの機能を必要としていないのも事実です。

7. nanogram からの提案

今回のwp2shellのニュースを見て、「また更新対応か…」「うちの体制で追いかけ続けられるだろうか」と感じた方へ。

• 現在のWordPress / PHP / プラグインの脆弱性スキャン（今回のwp2shell該当バージョンかどうかも含めて確認します）
• 「更新を続ける」vs「スプレッドシートCMSへ移行する」の判断材料の提示 — 更新頻度・ページ構成・必要機能をお聞きし、どちらが御社にとって現実的かを一緒に整理します
• 移行する場合の、おおよその費用感とスケジュールのご案内

「まず現状を客観的に見てほしい」というご相談だけでも歓迎です。お問い合わせフォームから、サイトURLと簡単な状況（更新頻度・運用体制・気になっている点）を添えてお送りください。

まとめ

• 2026年7月、WordPress本体に「認証不要でサーバーを乗っ取れる」脆弱性 wp2shell が公表された（CVE-2026-60137 と CVE-2026-63030 の組み合わせ）
• 従来と違い、プラグインを入れていない標準構成でも危険。6.9系・7.0系は特に要注意
• 実証コード公開済み・CISAが悪用を確認済みで、攻撃はすでに現実のもの。該当バージョンは今すぐ 6.8.6 / 6.9.5 / 7.0.2 以上へ更新を
• 今回の教訓は「更新しよう」だけではない。堅実に運用しても本体に穴が出る以上、"更新し続ける体制"を持てないサイトにとってWordPressの保守負担は重すぎる
• 更新頻度が低い・ページ数が少ないサイトなら、そもそも公開側に管理画面もDBも置かないスプレッドシートCMSが、攻撃の入り口ごと消す現実的な選択肢になる

脆弱性は今後も、WordPressである限り出続けます。問題は「次のパッチを当てられるか」ではなく、「パッチを当て続ける運用を、御社が本当に維持できるか」 です。そこに不安があるなら、一度ご相談ください。