2026年7月、WordPressの中核部分に、これまでにない規模の重大な脆弱性が見つかったというニュースを目にした方も多いのではないでしょうか。自社サイトの運用・保守を担う立場として、「対象バージョンに該当するか」「どこまで対応すれば十分と言えるか」を早急に切り分けたい方に向けて、この記事では今回のWordPress 脆弱性問題の技術的な背景から、実務レベルでのセルフチェック、応急対応、そして再発への備え方までを、公式アドバイザリ等の一次情報に基づいて整理します。
2026年7月に何が起きたのか？WordPress史上でも異例の脆弱性「wp2shell」の正体
まず結論からお伝えすると、2026年7月17日にセキュリティ専門機関から公表された今回のWordPress脆弱性は、ログインすらしていない第三者が、あなたのサイトを乗っ取れてしまうという、極めて深刻なものでした。専門的には「未認証のリモートコード実行(RCE)」と呼ばれる状態で、攻撃者が正規のIDやパスワードを一切知らなくても、サイトの内部に任意の命令を送り込めてしまう状態を指します。
なぜここまで深刻な事態になったのか、理由は二つの弱点が組み合わさったことにあります。
一つは、WordPressの投稿一覧を取得する仕組み(WP_Query)の中にある「author__not_in」パラメータの処理に不備があり、データベースに不正な命令を紛れ込ませる「SQLインジェクション」が可能だったこと(CVE-2026-60137)。
もう一つは、複数の操作をまとめて処理するREST APIのバッチエンドポイント(/wp-json/batch/v1)において、本来の検証処理と実行処理が別々のタイミングで走ってしまうことで、後続のリクエストが誤った処理に迂回できてしまう不具合があったことです(CVE-2026-63030)。
単体では大きな被害に直結しない二つの弱点が組み合わさることで、外部の攻撃者が正規の管理者アカウントを新規作成し、悪意あるプラグインを送り込んで、サーバー上で任意の命令を実行できてしまう、という流れでした。
今回の脆弱性は、SQLインジェクションとAPIの不備を組み合わせることでサーバーの制御を奪える(shellを取得できる)ことから、業界内で「wp2shell」と呼ばれています。
WordPress開発元自身も公式のセキュリティアドバイザリの中で深刻度区分を最も高い「Critical」と位置づけており、これが大きく報じられる要因の一つになりました。
なお、組み合わせの片方であるSQLインジェクション(CVE-2026-60137)単体の深刻度は「Moderate(中程度)」とされています。単体では中程度の弱点であっても、REST APIの不備と組み合わさることで最も深刻な区分まで引き上げられるという構造は、脆弱性対応において「一つひとつは軽微だから」と個別に判断することの危うさを示す典型例です。
影響を受けたのはWordPress6.9.0から6.9.4まで、そして7.0.0から7.0.1までのバージョンで、運営元は修正版である6.9.5および7.0.2への自動アップデートの強制配信という、通常のマイナーアップデートよりも一段踏み込んだ対応に踏み切りました。ただし、これはあくまで自動更新の仕組み自体を無効化していないサイトが対象です。AUTOMATIC_UPDATER_DISABLEDなどの設定で自動更新を意図的に止めている場合、この強制配信の対象外となるため、「自動で適用されたはずだから安心」と判断せず、後述するセルフチェックで実際のバージョン番号を必ず確認してください。
なお、SQLインジェクション単体の脆弱性についてはWordPress6.8系(6.8.0〜6.8.5)にも存在しており、こちらは6.8.6で修正されています。完全な乗っ取りに至る組み合わせの対象は6.9系以降ですが、6.8系を利用している場合も影響範囲の切り分けのため更新状況を確認しておく方が安全です。専門家の間では、生成AIの発達によって攻撃コードの作成そのものが以前より格段に速くなっている点も指摘されており、今後も同種の脆弱性が短いスパンで発見される可能性は十分にあります。
なぜWordPressは脆弱性が生まれやすく、狙われやすいのか
今回のような事件が起きるたびに「WordPressは危ないのでは」と感じる方もいるかもしれませんが、正確には「利用者が多いからこそ狙われやすい」という側面が強いです。この章では、その構造的な理由を整理します。
世界中でCMS(コンテンツ管理システム)を導入しているウェブサイトのうち、6割以上がWordPressで構築されているとされており、これは裏を返せば、一つの脆弱性を見つけ出せば、非常に多くのサイトに対して同じ手口が通用してしまうことを意味します。攻撃者からすれば、個別のサイトを一つひとつ狙うよりも、WordPress本体やそこで広く使われているプラグインの弱点を見つける方が、はるかに効率よく多くの獲物を狙えるわけです。今回のWordPress脆弱性のニュースが大きく取り上げられたのも、この影響範囲の広さが理由の一つです。
加えて、WordPressはオープンソースとして世界中の開発者にソースコードが公開されているという特性を持ちます。これは誰でも改良に参加できるという大きな利点である一方、攻撃者にとっても内部構造を研究しやすい環境になっているという、いわば表裏一体の関係にあります。実際、今回の脆弱性も、コードを詳細に分析した研究者によって発見されたものであり、同じ調査手法は悪意ある第三者にも当然可能です。
さらに見過ごされがちなのが、WordPressが「専門知識がなくても使える」ことを強みとして広まってきたという経緯です。これは非常に優れた特長である一方、サイト運営者の中には、セキュリティに関する知識が十分でないまま日々の更新作業を行っている方も少なくありません。バージョンアップの通知が来ても「よくわからないから後回しにする」「不具合が怖いので古いまま使い続ける」という判断をしてしまうケースは、決して珍しいことではないのです。今回のように強制的な自動更新が行われたのも、こうした「利用者の判断に委ねると危険な状態が長引く」という過去の経験が踏まえられているためだと考えられます。
また、攻撃の手口そのものが多様化していることも、WordPressが狙われやすい理由の一つです。今回のような未認証のリモートコード実行に加えて、IDとパスワードの組み合わせを機械的に総当たりで試す「ブルートフォース攻撃」、悪意のあるスクリプトをサイト内に埋め込み訪問者のブラウザ上で実行させる「クロスサイトスクリプティング」、そして修正プログラムが存在しない段階で悪用される「ゼロデイ攻撃」など、性質の異なる複数の攻撃手法が並行して存在しています。今回のWordPress脆弱性のようにSQLインジェクションとAPIの不備を組み合わせる手口が登場したように、攻撃者側も常に新しい組み合わせを試しており、単一の対策だけで万全と言い切れる状況は存在しません。だからこそ、特定の脆弱性への対応だけでなく、複数の防御策を重ねる「多層防御」の考え方が重要になってきます。
ここで誤解してはいけないのは、脆弱性が見つかること自体を、WordPressというプラットフォームの欠陥だと決めつけるのは早計だという点です。生成AIによって攻撃者側の技術的な敷居が下がり、脆弱性の発見から攻撃コードの作成までのスピードが以前とは比べ物にならないほど速くなっている今の時代においては、「弱点が見つかるかどうか」よりも「見つかった弱点がどれだけ早く、広く、正確に修正されるか」の方がはるかに重要な論点です。今回のwp2shellでは、脆弱性の報告から短期間のうちに公式の修正版がリリースされ、自動更新の仕組みを通じて多くのサイトへ迅速に配信されるという、組織的な対応が機能しました。これは、世界中の開発者やセキュリティ研究者が脆弱性情報を共有し、修正を配信する体制が既に確立されているWordPressだからこそ実現できることです。一方で、自社独自に一から構築したいわゆるスクラッチ開発のサイトの場合、脆弱性を発見して報告してくれる第三者のコミュニティも、修正パッチを自動配信してくれる仕組みもありません。セキュリティホールが何年も気づかれないまま放置され、ある日突然実害が発生して初めて発覚する、というケースも珍しくないのです。その意味で、脆弱性が見つかり、大きく報じられ、迅速に修正されるという今回のような一連の流れは、WordPressの脆さの証明というより、むしろ健全に機能している証拠だと捉える方が実態に近いと言えます。
あなたのサイトは大丈夫？今すぐできるWordPress脆弱性チェックの手順
ここからは、実際に手を動かして確認する方法を具体的に解説します。新たに診断ツールを導入しなくても、多くの項目は数分で確認できます。
最初に確認すべきは、現在のWordPressのバージョンです。
管理画面にログインし、ダッシュボードの「更新」ページを開くと、現在のバージョン番号が表示されます。もし表示されているバージョンが6.9.5未満、または7.0.2未満であった場合は、今回の脆弱性の影響を受ける可能性がある状態です。この時点で古いバージョンのままだったとしても慌てる必要はありませんが、できるだけ早く手動での更新作業を行うか、専門家への相談を検討してください。バージョンの確認方法自体がよくわからないという方は、当ブログの「WordPressのバージョンを確認する方法」の記事もあわせてご覧いただくと、より詳しい手順が分かります。
次に見落とされがちなのが、自動更新が本当に反映されているかどうかという点です。
WordPress運営元は今回、強制的な自動アップデートを実施したと発表していますが、これはあくまで「通常の環境であれば」という前提付きの話です。レンタルサーバーや独自の環境設定によっては、自動更新の機能自体が無効化されている場合や、サーバー側の制限によって更新プロセスが正常に完了していない場合があります。先ほど確認したバージョン番号が、まさにこの「反映されているかどうか」を判断する最も分かりやすい材料になりますので、必ず実際の数字で確認するようにしてください。
三つ目に確認しておきたいのが、利用しているレンタルサーバー側の対応状況です。
多くの主要なレンタルサーバー事業者は、今回のような重大な脆弱性が公表された際に、サーバー側でも独自の防御策(WAFと呼ばれる仕組みによるアクセス制限など)を講じることがあります。契約しているサーバー会社の公式サイトやお知らせページで、今回の脆弱性に関する案内が出ていないかを確認しておくと、二重の安心材料になります。もしサーバー側の対応状況がよく分からない、問い合わせても専門用語で説明されてしまい理解できない、という場合は、無理に自己判断せず第三者に確認してもらうのも一つの手です。
何らかの事情でただちにバージョンアップできない場合の暫定的な緩和策も知っておくと安心です。
今回の脆弱性は、REST APIのバッチエンドポイント(/wp-json/batch/v1、パーマリンク設定によっては?rest_route=/batch/v1という形式の場合もあります)を経由する経路が悪用の起点になっているため、WAF(Webアプリケーションファイアウォール)側でこのエンドポイントへの匿名アクセスを制限する、あるいはプラグイン等で未認証のREST APIアクセス自体を無効化するといった設定変更により、更新完了までの空白期間のリスクをある程度抑えられます。ただし、これはあくまで恒久対応であるバージョンアップを行うまでの時間稼ぎであり、根本対応の代わりにはならない点には注意してください。
これらのセルフチェックを行った上で、少しでも不安な点が残るようであれば、それは決して気にしすぎということではありません。今回のWordPress脆弱性はWordPress開発元自身が最も深刻な区分と位置づけたものですから、慎重になりすぎるくらいでちょうど良いというのが実情です。
なお、あわせて確認しておきたいのが利用しているプラグインやテーマのアップデート状況です。
今回の脆弱性はWordPress本体に起因するものでしたが、実際に発生する脆弱性の多くは、サードパーティ製のプラグインやテーマに起因しているとも言われています。管理画面の「プラグイン」ページや「テーマ」ページを開き、更新マークが表示されているものがないかを一通り確認しておくと、次のトラブルの芽を摘むことにつながります。特に、長期間更新されていないプラグインや、開発が止まっているように見えるプラグインについては、思い切って利用をやめるという判断も検討する価値があります。使っていない機能のために脆弱性のリスクを抱え続けるのは、割に合わないことが多いからです。
もし対象バージョンだった場合の対処法｜乗っ取り・改ざんのサインと初動対応
セルフチェックの結果、対象バージョンのままだったことが分かった場合や、すでにサイトに何らかの異変が出ている場合の対処について解説します。
まず、乗っ取りや改ざんが起きているサイトによく見られる典型的な異変のサインを知っておくことは重要です。トップページを開いた際に見覚えのない広告やリンクが表示される、サイトの表示速度が急に遅くなる、検索結果に自分では書いていない不自然なページが大量に表示されるようになる、レンタルサーバーから「不審な通信が検知された」という警告メールが届く、といった現象が代表的です。これらの兆候が一つでも見られる場合は、単なる表示不具合と決めつけず、乗っ取りの可能性を疑ってください。
もし何らかの異変に気づいた場合、応急処置として最初に行うべきことは、これ以上の被害拡大を防ぐことです。具体的には、サイトを一時的にメンテナンスモードにする、あるいはレンタルサーバーの管理画面からサイトを一時停止する、といった対応が挙げられます。また、直近の正常なバックアップが存在するかどうかを確認しておくことも欠かせません。バックアップさえあれば、被害が拡大する前の状態に戻すという選択肢を持てるからです。あわせて、管理画面やサーバーの管理者アカウントのパスワードは、念のためすべて変更しておくことをおすすめします。
一方で、自己判断で踏み込んではいけない領域があることも知っておいてください。
データベースの中身を直接編集する、原因が分からないままファイルを闇雲に削除する、といった対応は、知識が十分でない状態で行うと、かえって被害を悪化させたり、復旧をより困難にしたりする恐れがあります。特に、攻撃者が仕込んだ不正なファイルは、一見すると通常のWordPressのファイルと見分けがつかない形に偽装されていることも多く、専門的な知識なしに「怪しいものだけ」を正確に見つけ出すのは簡単ではありません。少しでも異変に気づいた段階で、早めに専門家へ相談するという判断も、決して大げさなことではないのです。
脆弱性を放置するとどうなるのか？見えないリスクの正体
「今のところ何も起きていないから大丈夫」と考えて、対応を先延ばしにしてしまう方も少なくありません。
しかし、脆弱性を放置することのリスクは、目に見える形で現れるとは限らない、という点にこそ本当の怖さがあります。
まず分かりやすいところでは、検索エンジンからの評価への影響が挙げられます。サイトが改ざんされ、悪質な外部サイトへの不正なリンクが埋め込まれるような被害に遭った場合、検索エンジン側がそれを検知し、検索結果に警告表示を出したり、最悪の場合は検索結果から除外してしまったりすることがあります。これまで積み上げてきたSEOの評価が、脆弱性の放置一つで一気に失われてしまう可能性があるということです。
さらに深刻なのが、取引先や顧客からの信用への影響です。企業のコーポレートサイトや採用サイト、ECサイトなどが乗っ取りの被害に遭った場合、それを知った取引先や顧客が抱く不安は、単なる技術的なトラブルという範囲を超えます。「この会社は情報管理をきちんとできていないのではないか」という印象は、直接的な金銭被害以上に、長期的な信頼関係へダメージを与えかねません。
加えて見落としがちなのが、個人情報や決済情報の漏洩リスクです。問い合わせフォームや会員登録機能を備えたサイトの場合、乗っ取りの過程でデータベースの中身が抜き取られてしまう可能性もゼロではありません。
万が一、顧客の個人情報が流出するような事態になれば、謝罪対応や関係各所への報告、場合によっては監督官庁への届け出など、通常の業務とはかけ離れた対応に多くの時間と労力を割かれることになります。今回のWordPress脆弱性のように、攻撃の入り口が「ログイン不要」であった点を踏まえると、こうした情報漏洩のリスクは決して大げさな想定ではないことが分かります。目に見える改ざんだけでなく、目に見えないところで情報が抜き取られている可能性がある、という点こそが、この種の脆弱性の本当の怖さだと言えるでしょう。
なぜこうした脆弱性は今後も繰り返し起こるのか、これからの向き合い方
今回のWordPress脆弱性への対応が一段落したとしても、「これで安心」と考えるのは早計です。
この章では、今後どのような心構えでWordPressと付き合っていくべきかを考えます。
前提として理解しておきたいのが、オープンソースソフトウェアという仕組みそのものが持つ宿命です。世界中の開発者が改善を続けている一方で、新しい機能が追加されるたびに、新たな脆弱性が生まれる可能性も同時に発生します。これはWordPressに限った話ではなく、あらゆるソフトウェアに共通する構造的な課題であり、「一度対策すれば二度と問題は起きない」という状態は、残念ながら存在しません。
だからこそ重要になるのが、修正版が公開されてからが本当の勝負だという意識です。脆弱性情報が公表された直後は、攻撃者側もその情報を入手し、対応が遅れているサイトを狙って一斉に攻撃を仕掛けてくる傾向があります。つまり、修正プログラムが公開されてから実際に自分のサイトへ適用するまでの「空白期間」こそが、最も危険な時間帯だと言えます。今回、運営元が異例の強制アップデートに踏み切ったのも、この空白期間をできるだけ短くするための判断だったと考えられます。
今後の向き合い方として意識したいのが、「見つかってから直す」という受け身の発想から、「多少の変化があっても崩れない仕組みをあらかじめ作っておく」という発想への転換です。具体的には、更新作業を後回しにしない運用体制を整える、万が一の際にすぐ元に戻せるバックアップを定期的に取得しておく、自分たちだけで判断がつかない場面では早めに専門家の力を借りる、といった備えが該当します。生成AIの発展により今後も脆弱性の発見と攻撃コードの作成サイクルは短くなっていくと予測されており、こうした備えの重要性は今後さらに増していくはずです。
WordPressの脆弱性対応が不安なら、専門家に相談するという選択肢
ここまで、セルフチェックの方法や対処法、そして今後の心構えについて解説してきましたが、正直なところ「自分だけで全部やり切るのは難しい」と感じた方も多いのではないでしょうか。それは決して特別なことではありません。
WordPressの運用は、日々の更新作業だけでなく、今回のような緊急事態への対応、バックアップの管理、サーバー環境との整合性の確認など、想像以上に多岐にわたります。特に本業が別にある事業者や、専任の担当者を置けない小規模な組織にとって、これらすべてを継続的にこなしていくのは、時間的にも知識的にも大きな負担になります。セルフ対応には限界があるという前提に立った上で、どこまでを自分たちで行い、どこから専門家に任せるかを線引きしておくことが、現実的な備え方だと言えます。
専門の保守サービスに相談する最大のメリットは、こうした緊急対応や日々の監視を、専門知識を持ったプロに継続的に任せられる点にあります。今回のような重大な脆弱性が公表された際にも、自分でニュースを追いかけて判断する必要がなく、専門家側が状況を把握した上で必要な対応を取ってくれるため、対応の遅れによるリスクを大きく減らすことができます。また、万が一トラブルが発生してしまった場合にも、原因の切り分けから復旧作業まで一貫してサポートを受けられる安心感は、自己対応では得がたいものです。
依頼先を選ぶ際に意識しておきたいポイントとしては、今回のような脆弱性情報への対応スピードや実績があるか、バックアップと復旧の体制が明確になっているか、そして専門用語を使わずに分かりやすく説明してくれるかどうかが挙げられます。特に最後の点は見落とされがちですが、緊急時にこそ、状況を正確に、かつ平易な言葉で伝えてくれる相手であるかどうかは、実際の安心感に直結します。
また、契約前の段階で「月々どこまでの作業が含まれているのか」「緊急時の追加費用は発生するのか」といった費用面の条件を具体的に確認しておくことも大切です。安さだけを基準に選んでしまうと、いざ今回のような緊急事態が起きた際に、対応範囲外として追加費用を請求されたり、対応そのものを断られたりするケースもあり得ます。日頃の月額費用と、いざという時の安心感のバランスを踏まえて、長期的に付き合っていけるパートナーを選ぶという視点を持っておくと、結果的に無駄な出費や余計な不安を避けられるはずです。
まとめ
今回の記事では、2026年7月に公表されたWordPressの重大脆弱性「wp2shell」を入り口に、その概要から、自分のサイトが対象かどうかのセルフチェック手順、既に異変が出ている場合の対処法、そして脆弱性を放置することの見えないリスクまでを解説してきました。バージョンの確認と、自動更新が実際に反映されているかどうかのチェックは、今すぐにでも行える最も重要な一歩です。
今回のような事態は今後も繰り返し起こり得るからこそ、都度不安になって調べるのではなく、継続的に見守ってくれる専門家との関係を築いておくことが、長期的には最も確実な備えになります。少しでも不安を感じた方は、まず現状のバージョンを確認するところから始めてみてください。そして、自分だけで対応しきれないと感じたときは、遠慮せず専門家に相談することをおすすめします。
