WordPress本体の脆弱性「WP2Shell」悪用確認でCISA KEV入り(7/21)｜プラグイン対策では守れない——制作会社に今日送る確認メールと放置サイト棚卸しの手順

結論：本体が狙われている以上、「うちのサイトは制作会社に任せてある」は答えになっていない

まず事実からです。WordPress本体(コア)に存在する2つの脆弱性——REST APIのバッチ処理ルートの解釈矛盾を突くCVE-2026-63030(CVSS 9.8)と、WP_Queryのauthor__not_inパラメータに対するSQLインジェクションCVE-2026-60137(CVSS 5.9)——を組み合わせる攻撃チェーンが「WP2Shell」と呼ばれ、ログイン不要(未認証)のままサーバー上で任意のコードを実行されることが確認されています。影響を受けるのはWordPress 6.9.0〜6.9.4および7.0.0〜7.0.1で、6.8.0〜6.8.5はSQLインジェクション成分のみの影響です。修正版6.9.5/7.0.2(および6.8系向けの6.8.6)は2026年7月17日にセキュリティリリースとして公開され、自動バックグラウンド更新に対応しているサイトには順次配信されています。しかし公開直後から実証コード(PoC)がGitHub上に複数出回り、Tenableの解説FAQによれば、セキュリティ企業Hexastrikeが公開直後の週末(7月18〜19日)からハニーポットでの攻撃観測を報告し、Patchstackも実際の攻撃を記録しています。そして7月21日、米CISA(サイバーセキュリティ・インフラセキュリティ庁)はCVE-2026-63030とCVE-2026-60137を含む4件を「悪用が確認された脆弱性カタログ(KEV)」に追加しました(WP2Shellを構成する2つのCVEが同日そろってKEV入りしています)。KEV入りは「理論上危ない」ではなく「現実に使われている」ことの公的な確認です。

経営者にとっての結論は3行で言えます。第一に、今回はプラグインではなくWordPress本体の脆弱性なので、「プラグインを最小限にしている」「怪しいプラグインは入れていない」という従来の自衛策では一切守れません。第二に、修正版は自動更新で配信されていますが、制作会社任せの企業サイトほど自動更新が無効化されている構造的な理由があり、「配信された=うちは適用済み」とは限りません。第三に、確認は難しい作業ではありません。本記事に載せた3点だけ聞く確認メールを今日、サイトの制作会社または保守会社に送れば、自社の状態は48時間以内に判明します。まだ送っていないなら、この記事を読み終える前に送ることをお勧めします。

もう一つ、この機会に向き合うべき問いがあります。「このサイトのパッチ適用に、誰が責任を持っているか」に即答できるかどうかです。即答できない会社は、今回たまたま無事でも、次の本体脆弱性(WordPressのシェアを考えれば高い確度で再来します)で同じ賭けを繰り返すことになります。本記事の後半では、保守契約のどこを見ればこの問いに答えられるようになるか、そして本社サイト以外の「忘れられた採用LP・キャンペーンサイト」をどう洗い出すかまでを扱います。

この記事を読むべき人

• 自社サイト・採用サイト・サービスサイトのいずれかがWordPressで動いている(または動いているかどうか分からない)会社の経営者・役員
• サイトの構築・更新を外部の制作会社に任せており、保守契約の中身を正確に説明できない広報・総務・管理部門の責任者
• 情シスが0〜1名で、「WordPressのバージョン」を社内の誰も即答できない会社の決裁者
• 過去にキャンペーンサイトや採用LPを作ったが、今も動いているか誰も把握していない心当たりのある会社
• 「セキュリティはUTMとウイルス対策ソフトでやっている」と考えており、公開Webサイトを対策の対象に含めていなかった会社

何が起きたか——WP2Shellの事実関係

事実関係を表で整理します。技術的な詳細はTenableの解説FAQが最も整理されています。

時系列で見ると、この事案の怖さは「速度」にあります。修正版公開が7月17日、公開PoCの出現はその数時間後、ハニーポットでの攻撃観測開始が公開直後の週末(7月18〜19日)、KEV入りが7月21日。修正版の公開から実悪用の確認まで、実質1〜2日です。Tenableは、パッチの差分解析と攻撃コード開発がAI支援ツールによって容易になったことを、PoCが急速に出回った背景として研究者が指摘していると伝えています。「パッチが出たら月次メンテナンスのタイミングで適用する」という従来ペースの保守運用は、この速度の前では防御として成立しません。

なお、国内での被害件数は本稿執筆時点(7月22日)で公的な集計が公表されておらず、本記事では国内被害の規模について断定しません。ただしWordPressは国内の企業サイトでも広く使われているCMSであり、「国内は狙われない」と考える根拠はありません。攻撃は自動化されたスキャンで無差別に行われるのが通例であり、企業規模や知名度は攻撃対象の選定基準になりません。

緊急の暫定対策としては、Tenable FAQでは、WAF(Webアプリケーションファイアウォール)やサーバー設定で「/wp-json/batch/v1」および「?rest_route=/batch/v1」へのアクセスを遮断する方法などが紹介されています。ただしこれはあくまで応急処置であり、恒久対策は修正版への更新です。

「プラグインではなく本体」が何を意味するか

WordPressの脆弱性ニュースは珍しくありませんが、その大半はプラグインやテーマの脆弱性です。経営層向けにこの違いを整理しておきます。今回が「いつものWordPressの脆弱性ニュース」と質的に違う理由が3つあります。

第一に、対象母数が桁違いです。 プラグインの脆弱性は「そのプラグインを入れているサイト」だけが対象ですが、本体の脆弱性は該当バージョンの全WordPressサイトが対象です。攻撃者から見れば、どのプラグインが入っているかを調べる手間すらなく、バージョンだけ確認すれば攻撃できる。実際、攻撃の入口となるREST APIのバッチエンドポイントは、標準構成のWordPressに最初から存在します。

第二に、従来の自衛策が全て空振りします。 「プラグインは最小限」「有名なものしか使わない」「使っていないプラグインは削除」——これらはプラグイン脆弱性への正しい備えですが、本体の脆弱性には何の効果もありません。同様に、「うちはサイトを改修していないから大丈夫」も誤りです。触っていないサイトほどバージョンが古いまま残り、むしろ危険側に倒れます。

第三に、「本体は自動更新されるはず」という前提が、企業サイトでは崩れていることが多い。 WordPressにはマイナーバージョン(セキュリティ修正)の自動更新機能が標準で備わっており、今回も修正版は自動更新の仕組みで配信されています。個人ブログの多くはこれで自動的に守られます。問題は、企業サイトほどこの自動更新が無効化されていることです。次章で述べるとおり、これは手抜きではなく、制作会社のビジネス構造から必然的に生まれる設定です。だからこそ「自動更新があるから大丈夫でしょう」と推測で済ませず、自社サイトについて個別に確認する必要があります。

なぜ企業サイトほど自動更新が切られているのか——制作会社任せの構造

「自動更新が有効なら配信済みのはず。うちは大丈夫だろう」——この推測が企業サイトで危険な理由を、制作の現場構造から説明します。以下のいずれかに心当たりがあれば、自社サイトの自動更新は無効化されている可能性を疑うべきです。

構造1: テーマやプラグインを改造しているため、更新で表示が壊れるリスクがある。 企業サイトは既製テーマをそのまま使うことは少なく、デザインや機能をカスタマイズしています。本体を更新するとカスタマイズ部分との相性で表示崩れや機能停止が起きることがあり、制作会社は「勝手に更新されて壊れる」事故を避けるために自動更新を切ります。これは制作会社としては合理的な判断です。問題は、切った代わりに「誰かが手動でテスト・更新する」運用がセットで契約されているか——されていなければ、単に更新されないサイトが残るだけです。

構造2: 保守契約が切れている、あるいは最初から結ばれていない。 サイト制作は「作って納品したら終わり」の一括契約が多く、公開後の更新作業は別契約です。数年前に作ったサイトの保守契約が更新されないまま切れている、制作会社が廃業・担当者退職で実質的に連絡が取れない、というケースは珍しくありません。この状態のサイトは、誰の作業対象にもなっていない「無人のサーバー」として公開され続けます。

構造3: 「動いているから触るな」の空気。 過去に更新で表示が崩れた経験があると、社内に「サイトは触ると壊れる。今動いているなら触るな」という空気が生まれます。担当者が更新を提案しても「今忙しいから次の機会に」と先送りされる。セキュリティ更新は「やっても誰にも褒められず、やって壊れたら怒られる」作業なので、責任の所在が曖昧な組織では構造的に後回しになります。

この3つに共通するのは、悪意や怠慢ではなく、契約と責任の設計の欠落だという点です。制作会社は「保守契約の範囲外の作業は勝手にできない」立場であり、発注側は「任せてあるから何かあれば向こうがやるだろう」と思っている。この認識ギャップの間に、更新されないサイトが放置されます。今回のWP2Shellは、このギャップを攻撃者が突く事案だと理解してください。

今日、制作会社に送る確認メール——聞くことは3点だけ

自社の状態を確認するのに、技術知識は要りません。以下の3点を聞くメールを、サイトの制作会社(保守会社)に送ってください。文面はそのまま使って構いません。

件名: 【至急ご確認】弊社Webサイトの脆弱性対応状況について(WordPress WP2Shell)

いつもお世話になっております。 WordPress本体の脆弱性(CVE-2026-63030および関連するCVE-2026-60137、通称WP2Shell)の悪用が確認され、うちCVE-2026-63030が7月21日に米CISAの悪用確認済み脆弱性カタログに追加されたと承知しています。つきましては、貴社に制作・保守いただいている弊社サイトについて、以下3点をご確認のうえ、可能であれば48時間以内にご回答をお願いいたします。

1. 現在のバージョンと更新状況: 弊社サイトのWordPress本体のバージョンは何か。修正版(6.9.5 / 7.0.2 / 6.8.6)への更新は適用済みか。未適用の場合、いつ適用いただけるか。
2. 更新責任の所在: 現行のご契約において、WordPress本体・プラグイン・テーマのセキュリティ更新は貴社の作業範囲に含まれているか。含まれていない場合、今回のような緊急時の更新は誰がどのような条件で行う想定か。
3. 改ざん有無の点検: 修正版適用の前後を問わず、見覚えのない管理者アカウントの有無、直近で更新日時が変わっているファイル、心当たりのないPHPファイル(Webシェル)の有無について点検いただき、結果をご共有いただきたい。

なお、貴社との保守契約が現在有効でない場合は、その旨と、スポットでの対応可否・概算費用をお知らせください。

このメールのポイントは、3問目に「改ざん有無の点検」を入れていることです。修正版の公開(7/17)から悪用観測(7/20)までの間も、そして修正版適用前の全期間、サイトは攻撃可能な状態でした。「今日更新した」は「昨日までに侵入されていない」を意味しません。 Webシェルは一度設置されれば、本体を更新しても残り続けます。更新と点検は必ずセットで依頼してください。

返答への評価軸も示しておきます。48時間以内に3点すべてに具体的に答えが返ってくるなら、その制作会社との関係は健全です。「確認します」のまま数日止まる、バージョンの質問に答えられない、「保守契約に含まれていないので対応できません」で終わる——いずれの場合も、その会社が悪いというより、保守の設計が現状の脅威水準に合っていないことが判明したと捉え、次章の判定軸で契約を見直す機会にしてください。

「誰がパッチ適用に責任を持つか」——保守契約の判定軸

今回の確認メールを送ろうとして「そもそもどこに送ればいいのか分からない」となった会社は、実はそれ自体が最も重要な発見です。Webサイトの保守を評価する軸は、料金でもページ更新の速さでもなく、次の一問に集約されます。

「このサイトのセキュリティパッチ適用に、誰が、どの速度で責任を持つか」——契約書のどこを見ればそれが書いてあるか。

この観点で、手元の保守契約(なければ制作時の契約書・見積書)を以下の5項目で採点してみてください。

5項目のうち3つ以上が「危険なパターン」に該当するなら、そのサイトの保守は実質的に無保守です。月額の保守費を払っていても、その中身が「ページの文言修正」だけなら、セキュリティ上は保守契約がないのと同じです。逆に言えば、制作会社を責める前に、発注側がこの5項目を要件として明示してこなかった可能性も高い。今回を機に、既存の制作会社と契約を再設計するのが第一選択です。制作会社側にセキュリティ運用の体制がない場合は、制作(コンテンツ更新)と保安(パッチ・監視・点検)を分離し、後者を専門会社に持たせる構成も現実的です。GXOでもセキュリティ顧問(リテイナー)サービスとして、この「保安側」を継続的に受け持つ形を提供しています。

もう一点、経営側の意思決定として重要なのは、「更新して壊れるリスク」と「更新せず侵入されるリスク」の比較を、担当者の感覚に任せないことです。表示崩れは営業時間内に直せますが、Webシェルを設置されたサイトの復旧と信用回復はそうはいきません。今回のようにKEV入りした脆弱性については「表示が多少崩れても即日更新する。崩れたら事後に直す」という優先順位を、経営が明文化して現場に渡しておくべきです。この一文があるだけで、現場の「触るな圧力」は消えます。

もし改ざんされていたら——事業影響と初動5ステップ

点検の結果、見覚えのないファイルや管理者アカウントが見つかった場合に備え、事業影響と初動を整理しておきます。

まず事業影響です。Webシェルを設置されたサイトで典型的に起きるのは、(1)改ざんSEO(スパムページの大量生成)——自社ドメイン配下に偽ブランド品や不正サイトへ誘導するページを大量生成され、検索エンジンから「ハッキングされたサイト」と判定されて検索結果に警告が表示され、順位が崩壊する、(2)マルウェア配布の踏み台化——自社サイトの訪問者にマルウェアを配布する「加害者」の立場になり、ブラウザやセキュリティ製品にブロック対象として登録される、(3)信用毀損——採用応募者や取引先が最初に見るのは公式サイトであり、そこに警告画面が出る・不審な内容が表示されることの信用ダメージは、復旧後も検索結果やSNSに痕跡として残る、(4)情報窃取——問い合わせフォームや会員機能があるサイトでは、入力された個人情報が抜かれている可能性があり、その場合は個人情報保護法上の報告・本人通知の要否検討が必要になる、という4系統です。「うちのサイトは名刺代わりだから被害はない」という認識は、(2)と(3)を見落としています。改ざんされたサイトは自社が損をするだけでなく、訪問者に被害を与える側になります。

そのうえで、発覚時の初動5ステップです。

1. 止める(隔離): サイトをメンテナンス表示に切り替えるか、一時的に公開停止します。「営業への影響」を理由に公開を続けるのは、加害の継続を意味します。
2. 消す前に残す(証拠保全): 慌ててファイルを削除しないでください。サーバーのアクセスログ、改ざんされたファイル、データベースの状態をまず丸ごと保全します。侵入時期と経路、情報窃取の有無の判定は、ここで残した証拠でしか行えません。
3. 鍵を全部替える(認証情報の一斉更新): WordPress管理者、データベース、FTP/SSH、ホスティング管理画面のパスワードをすべて変更します。攻撃者は侵入後にこれらを窃取している前提で動きます。
4. 上書きではなく作り直す(クリーン再構築): 見つけたWebシェルを削除して終わりにしないでください。バックドアは複数仕込まれるのが通例です。改ざん前の正常なバックアップとWordPress・プラグインの正規配布物から環境を再構築し、修正版まで更新した状態で公開を再開します。
5. 影響を判定し、必要な通知を行う: 保全した証拠をもとに、個人情報への影響有無を判定し、必要に応じて個人情報保護委員会への報告・本人通知を検討します。あわせてGoogle Search Consoleでセキュリティの問題の警告有無を確認し、クリーンアップ後に再審査をリクエストします。

このうち2と4と5は、社内や制作会社だけで正確に行うのが難しい工程です。特に「消す前に残す」は、善意で掃除を始めた担当者が証拠を消してしまう失敗が典型です。改ざんが疑われる時点で、フォレンジック(侵害調査)の経験がある第三者に初動から入ってもらう判断を推奨します。

忘れられたサイトを洗い出す——サイト棚卸しの手順

ここまでは「本社サイト」を前提に書きましたが、実際のリスクの多くは会社が存在を忘れているサイトにあります。数年前の採用キャンペーンで作ったLP、周年記念サイト、イベント特設サイト、買収した会社の旧サイト——これらは作った担当者が異動・退職すると管理者不在になり、WordPressのバージョンは作った日のまま止まります。攻撃者の自動スキャンは、会社が忘れていてもドメインが生きている限り見つけ出します。

棚卸しは以下の手順で、半日から一日で一巡できます。

1. 支払いから辿る: 経理に、サーバー代・ドメイン代・CMS関連の支払い(クレジットカード明細・請求書)を過去3年分リストアップしてもらいます。忘れられたサイトでも、支払いだけは自動継続していることが多く、最も漏れの少ない起点です。
2. DNSから辿る: 自社ドメインのDNSレコード(サブドメイン一覧)を確認します。recruit.、campaign.、lp.、old.といったサブドメインに古いサイトが残っている典型パターンを拾えます。
3. 記憶と記録から辿る: マーケ・人事・広報に「過去に外部発注で作ったサイト・LP」を聞き、広告アカウント(リンク先URL)、Google Search Consoleの登録プロパティ、SSL証明書の発行履歴を突き合わせます。
4. 一覧化して3分類する: 見つかった各サイトを「①今後も使う→保守責任者と契約を割り当てる」「②もう使わない→閉鎖してドメイン・サーバーを整理する」「③情報として残したいだけ→WordPressをやめて静的HTML化する(動的なCMSでなければ今回のような攻撃面は消えます)」に分類します。
5. 台帳にして年1回見直す: サイト名・URL・CMSとバージョン・ホスティング・保守責任者(社内)・保守会社(社外)・契約状態を1枚の台帳にし、年1回の見直しを定例化します。次の本体脆弱性が来たとき、確認メールを送るべき宛先がこの台帳で即座に分かる状態が目標です。

この棚卸しは、セキュリティ対策であると同時に、Web資産の経営管理そのものです。棚卸しの結果「使っていないサイトに年間数十万円払い続けていた」「採用サイトの保守が誰の責任でもなかった」といった発見が出てくるのが通例で、その整理はDXの土台となる社内システム・Web資産の再構築の出発点にもなります。また、棚卸しで見つかったサイト群に対して外部から攻撃者視点で脆弱性を洗い出すのがセキュリティ診断の役割です。台帳を作った直後は、診断の費用対効果が最も高いタイミングです。

よくある質問(FAQ)

Q1. 自社サイトがWordPressかどうか、社内で確認する方法はありますか。

A. 簡易的には、ブラウザでサイトのソース表示を行い「wp-content」という文字列が含まれるか、また「サイトURL/wp-login.php」にアクセスしてログイン画面が出るかで概ね判別できます。ただし判別できても、バージョンや更新状態の確認・対応は管理権限が必要です。判別に自信がなければ、確認メールの1問目を「弊社サイトのCMSは何か」から始めてください。

Q2. 自動更新が有効になっていれば、何もしなくてよいですか。

A. 修正版が適用済みであることを「確認」するまでは安心できません。自動更新は、ファイルの改変やサーバー設定によって機能していないことがあり、また適用前の期間に侵入されていれば、更新してもWebシェルは残ります。「バージョンが6.9.5/7.0.2/6.8.6以降になっていること」と「改ざん痕跡がないこと」の2点をセットで確認してください。

Q3. WAFやレンタルサーバーのセキュリティ機能を使っていれば防げますか。

A. Tenable FAQでは、攻撃入口となる「/wp-json/batch/v1」および「?rest_route=/batch/v1」へのアクセス遮断が暫定緩和策として紹介されています。WAFで攻撃の多くを止められる可能性はありますが、これは修正版適用までの時間稼ぎであり、恒久対策の代替にはなりません。また、レンタルサーバー付属のセキュリティ機能が今回の攻撃パターンに対応しているかはサービスごとに異なるため、「入っているはず」ではなく個別に確認が必要です。

Q4. 6.8系のサイトはRCEにならないなら、急がなくてよいですか。

A. 推奨しません。6.8.0〜6.8.5もSQLインジェクション(CVE-2026-60137)の影響を受け、6.8.6で修正されています。しかもこのCVE-2026-60137自体が2026年7月21日にCISAのKEVカタログへ単独で追加され、対応期限が7月24日という異例の短さで指定されています。SQLインジェクション単体でもデータベース内の情報窃取などのリスクがあり、また他の脆弱性と組み合わされる可能性は常にあります。そもそも6.8系に留まっているサイトは更新運用が止まっている兆候であり、この機会に最新の修正版まで引き上げるべきです。

Q5. 制作会社と連絡が取れません。どうすればよいですか。

A. まずホスティング(サーバー)の契約が自社名義か確認してください。自社名義なら、サーバー会社のサポートと別の保守会社への引き継ぎで対応できます。サーバー契約まで制作会社名義になっている場合は、ドメインとデータの権利確保を最優先に動く必要があり、時間との勝負になります。この状態は今回に限らず恒常的なリスクなので、復旧後に必ず名義と権限の整理を行ってください。

Q6. 改ざんの痕跡があるかどうか、素人でも見られるポイントはありますか。

A. WordPress管理画面の「ユーザー」一覧に見覚えのない管理者がいないか、Google Search Consoleに「セキュリティの問題」の警告が来ていないか、検索エンジンで「site:自社ドメイン」を検索して身に覚えのないページ(外国語の商品ページ等)が出てこないか、の3点は非技術者でも確認できます。ただし「見つからない=侵入されていない」ではありません。疑わしい兆候が一つでもあれば、前述の初動5ステップに従い、専門家による調査を検討してください。

GXOに相談すべきタイミング

今回の件は、確認メールを送り、修正版の適用と点検の回答を得られれば、それで一区切りです。外部の専門家を入れる価値があるのは、次のような状態に当てはまる場合です。

• 確認メールを送ったが回答が曖昧、または保守契約が実質的に存在しないことが判明し、制作会社の言い分を検証できる第三者が社内にいない
• 棚卸しの結果、管理者不在のサイトが複数見つかり、どれから手を付けるべきか優先順位を判断できない
• 改ざんの兆候(不審なファイル・アカウント・検索結果の異常)があり、証拠保全と影響判定を正確に行いたい
• 今回は無事だったが、「次のKEV級が来たら誰が何をするか」を仕組みにしたい

一度きりの点検であれば、公開サイト群を攻撃者視点で洗い出すセキュリティ診断が入口になります。診断は「今どこが開いているか」のスナップショットを示すものなので、棚卸し台帳を作った直後に受けると費用対効果が最大になります。一方、「パッチ適用の責任者が社内にいない」という構造自体を解消したいなら、スポット診断ではなくセキュリティ顧問(リテイナー)のような継続的な体制で、脆弱性情報の監視から適用判断・制作会社への指示までを外部に持たせる形が適合します。また、棚卸しで見つかった老朽サイト・レガシーなWeb資産の整理と作り直しを事業側の視点で進めたい場合は、DX・システム再構築の支援として設計段階からご一緒できます。

自社がどのパターンに当たるか判断がつかない段階でも構いません。お問い合わせから現状(サイト数・保守契約の有無・確認メールへの回答状況)をお知らせいただければ、診断・顧問・再構築のどれが必要な状態か、初回相談で切り分けます。

参考文献

• CISA「CISA Adds Four Known Exploited Vulnerabilities to Catalog」(2026年7月21日)
• Tenable「wp2shell (CVE-2026-63030 & CVE-2026-60137): Frequently Asked Questions About Remote Code Execution」
• WordPress.org「WordPress 7.0.2 Release」(2026年7月17日)
• WordPress.org「Version 6.9.5」
• CISA「Known Exploited Vulnerabilities Catalog」