2026.08.12 | SEO対策

WordPressに重大な脆弱性が続発|2026年7〜8月に起きたことと、今日やるべき5つのこと

2026年7月から8月にかけて、WordPressをめぐって重大なセキュリティ問題が立て続けに起きました。

7月17日にはWordPress本体の緊急アップデートが公開され、7月22日にはIPA(情報処理推進機構)が注意喚起を出しています。さらに7月28日には、人気プラグインが攻撃者の裏口(バックドア)を仕込まれた状態で配布されるという事件が発生し、8月6日には再び本体のセキュリティアップデートが公開されました。

この記事では、専門用語をできるだけかみ砕きながら「何が起きたのか」「放置するとどうなるのか」「今日中に何をすればいいのか」を、Web担当者・院長・店舗オーナーの方に向けて整理します。

先に結論から。確認すべきは3つだけです

細かい経緯を読む時間がない方のために、最初に要点だけ書きます。

  • バージョンを確認する管理画面の「ダッシュボード → 更新」を開き、WordPress本体が最新かどうかを見てください。7.0系をお使いなら7.0.3以上が目安です。
  • 自動更新をONにする本体もプラグインも、自動更新が有効になっていない場合は今日中に有効化してください。
  • 使っていないプラグインを削除する「停止」では不十分です。ファイルがサーバーに残っている限り、そこから侵入されます。

逆に言えば、この3つができていないWordPressサイトは、今この瞬間も無差別な攻撃の対象になっています。

以下は、なぜそう言えるのかという説明です。

何が起きたのか。3週間の動きを時系列で

2026年7月17日から8月6日までのWordPress脆弱性関連の出来事をまとめた時系列図
約3週間のあいだに、本体の緊急修正が2回、プラグインへのバックドア混入が1件起きた

まず全体像です。2026年7月17日から8月6日までのおよそ3週間で、上図のことが起きました。ひとつずつ見ていきます。

7月17日:本体の緊急修正「wp2shell」

一連の騒動の中心になったのが、通称「wp2shell」と呼ばれる脆弱性です。

これはひとつの弱点ではなく、2つの弱点を組み合わせることでサイトを完全に乗っ取れてしまう、という性質のものでした。

  • CVE-2026-63030WordPress標準機能である REST API の「まとめ処理(バッチ処理)」で、値の検査と実行がずれてしまう不具合。
  • CVE-2026-60137データベースへの問い合わせに不正な命令を混ぜ込めてしまう、SQLインジェクションの不具合。

単体でも問題ですが、深刻だったのは組み合わせたときです。

①の不具合で検査をすり抜けさせ、②の不具合でデータベースを操作し、最終的に攻撃者用の管理者アカウントを作ってしまう。あとは正規の管理画面から「プラグイン」の形で裏口を設置すれば、乗っ取りが完了します。

wp2shellの攻撃手順を4ステップで示した図
2つの不具合を連鎖させ、管理者アカウントの作成から裏口の設置まで到達する

特筆すべきは、この攻撃がログイン不要で成立すること、そしてプラグインを1つも入れていない標準構成のWordPressでも成立することです。「うちはシンプルな構成だから大丈夫」という理屈が、今回は通用しませんでした。

WordPressのバージョン状況修正版
7.0.0 〜 7.0.12件とも該当(乗っ取り可能)7.0.2
6.9.0 〜 6.9.42件とも該当(乗っ取り可能)6.9.5
6.8.0 〜 6.8.5SQLインジェクションのみ該当6.8.6

そして重要なのが、これが「理論上の危険」で終わらなかったことです。

7月21日には米国のCISA(サイバーセキュリティ・インフラセキュリティ庁)が、この2件を「悪用が確認された脆弱性」のカタログに追加しました。

実際の攻撃に使われていることを公的に認めた、という意味です。翌22日にはIPAが国内向けの注意喚起を公開し、攻撃用のコードがすでに出回っている状況だと明記しています。

WordPress.org側も異例の対応を取りました。

対象バージョンに対して強制的な自動更新を有効化し、サイト運営者が操作しなくても修正版が配られるようにしています。

ただし、自動更新をプラグインやサーバー設定で止めていたサイトには、当然ながら届きません。

「知らないうちに直っていた」サイトと「今も穴が空いたまま」のサイトにはっきり分かれているのが現状です。

7月28日:更新したほうが危険になった「バックドア混入」事件

7月末に起きたのは、性質のまったく異なる事件です。

動画を記事に埋め込むための人気プラグイン「Advanced Responsive Video Embedder(ARVE)」のバージョン10.8.7が、攻撃者の裏口を仕込まれた状態で配布されました。

原因は開発者アカウントの乗っ取りとみられています。

つまり作者のうっかりミスでできた穴ではなく、何者かが意図的に悪意あるコードを混ぜ込んだ、いわゆるサプライチェーン攻撃です。

仕込まれたコードは「更新確認」を装ったファイル名で紛れており、特定の合言葉を含むリクエストを1回送るだけで、攻撃者が管理者としてログインできてしまうものでした。

CVE-2026-18072として登録され、危険度はCVSS 9.8(最大10)。影響を受けうるサイトは約2万件とされています。

セキュリティ企業Wordfenceの検知システムが公開から2時間ほどで発見し、WordPress.orgの公式ディレクトリからは即座に削除されました。被害の広がりは限定的だったとみられます。

ただ、この事件が突きつけた事実は重いものでした。こまめに更新していれば安全、とは限らないということです。

誤解しないでいただきたいのは、だからといって更新を止めるべきではない、という点です。更新しないリスクのほうが、桁違いに大きいです。

ただし「更新した直後に、管理者アカウントが増えていないか・身に覚えのない設定変更がないかを見る」という習慣は、これからは必要になります。

8月6日:ログイン画面から乗っ取られる脆弱性

8月6日、WordPress 7.0.3 が公開されました。

セキュリティ修正のみの緊急リリースで、公式リリースノートでは11件(Patchstackの集計では12件)の問題が修正されています。

このうち最も深刻とされたのが CVE-2026-64638 です。

ログインに失敗したときの処理に不備があり、ユーザー名の欄に仕込んだJavaScriptが、そのままログイン画面上で動いてしまう、というものでした(反射型クロスサイトスクリプティング)。

危険度はCVSS 8.9。影響範囲はWordPress 6.4から7.0.2までと広く、修正は4.7系まで遡って配布されています。

「ログイン画面が少し崩れるだけでは」と思われるかもしれませんが、そうではありません。

この脆弱性は「XSS2Shell」と呼ばれる手口で、最終的にサーバー上でPHPを実行される(=乗っ取られる)ところまで繋がることが示されています。

ただし成立には、管理者本人が攻撃者の用意したリンクを踏むという一手間が必要です。裏を返せば、心当たりのないメールやチャットのリンクを管理者が開かなければ止められる、ということでもあります。

7.0.3ではこのほか、投稿者権限以上のユーザーによる保存型XSSが4件、マルチサイト構成での権限昇格、パスワード保護記事のコメント漏えい、非公開記事のURL推測、SSRFなどが修正されています。

派手さはありませんが、複数人で記事を書いているサイトほど無関係ではない内容です。

「うちみたいな小さいサイトは狙われない」は成り立たない

ここが最大の誤解です。攻撃者は「このクリニックを狙おう」と考えて攻撃しているわけではありません。

脆弱性が公表されると、その穴を持つサイトを自動で探し回るプログラムが、世界中のアドレスを片端からノックして回ります。人間が選んでいないので、サイトの規模も業種も知名度も関係ありません。

実際、WordPressのプラグイン・テーマの脆弱性は毎週数十件のペースで公表され続けています。たとえば2026年7月30日から8月5日までの1週間だけで報告は40件、そのうち20件は「ログインしていない攻撃者でも悪用できる」ものでした。

本体の脆弱性がニュースになるのは年に数回ですが、プラグイン側の穴は毎週開いている、というのが実情です。

そして国内のCMSシェアでは、WordPressが圧倒的な割合を占めています。

攻撃者から見れば、同じ攻撃コードを使い回せる相手が国内に無数にある、ということです。

何もしないでいると、何が起きるのか

WordPressサイトが乗っ取られた場合に起きる被害の連鎖を示した図
被害はサイトが壊れる形ではなく、集客と信用が止まる形で表面化する

「乗っ取られる」と聞いても正直ピンと来ない、という声をよくいただきます。

実務上、被害はサイトが見た目に壊れる形ではなく、集客が止まる形で表面化します。

  • 検索結果が別物に入れ替わるサイト内に、まったく無関係な内容のページ(多くは海外のギャンブルや偽ブランド品の宣伝)を大量に作られます。日本語で作られることも多く、自院・自店の名前でそれらが検索結果に並びます。やがてGoogleから「ハッキングされたコンテンツ」として手動ペナルティを受け、検索順位そのものが消えます。
  • ブラウザに赤い警告画面が出るGoogleのセーフブラウジングに登録されると、ChromeやSafariで開こうとしたときに全画面の警告が表示されます。この状態では、広告からもSNSからも、誰ひとりサイトにたどり着けません。
  • Google広告が止まる広告審査では、リンク先が改ざんされているサイトはポリシー違反として不承認になり、悪質と判断されればアカウント停止に至ります。広告で集患・集客をしている場合、その日から流入がゼロになります。
  • フォームの入力内容が抜き取られる予約フォームや問い合わせフォームに細工をされると、送信された氏名・電話番号・メールアドレス・相談内容が、そのまま攻撃者にも送られます。医療機関の場合は症状や既往歴といった「要配慮個人情報」が含まれる可能性があり、漏えいが疑われる時点で、原則として個人情報保護委員会への報告と本人への通知が必要になります。件数の多寡は関係ありません。
  • 加害者の側に回ってしまう自社サイトがウイルスの配布元やフィッシングサイトの置き場所として使われた場合、被害に遭うのは自社を信頼して訪問した人たちです。金銭的な損失以上に、説明と信頼回復の負荷が重くのしかかります。
  • サーバーごと止められる共有サーバーの場合、他の利用者に影響が及ぶため、サーバー会社の判断でアカウントごと停止されることがあります。サイトもメールも同時に使えなくなります。

そして厄介なのは、これらのほとんどがすぐには気づけないことです。

攻撃者はサイトの見た目を変えません。管理画面も普通に開けますし、トップページも正常に表示されます。

異変に気づくきっかけは、Search Consoleに届く警告メールか、患者様・お客様からの「サイトを開いたら警告が出たのですが」という一報であることがほとんどです。

その時点で、被害はすでに数週間分積み上がっています。

今日やるべき5つのこと

WordPressサイトの緊急点検チェックリスト。5つのステップと所要時間の目安
上から順に進めれば、全体で30分ほど。所要時間はあくまで目安

Step 1 バージョンを確認する

管理画面にログインし、左メニューの「ダッシュボード → 更新」を開いてください。

「WordPressの最新バージョンを利用しています」と表示されていれば、本体については差し当たり問題ありません。

更新が残っている場合は、この記事を読み終わる前に適用してください。

なお、現在の最新は7.0.3ですが、事情があって6.8系や6.9系を使い続けている場合も、それぞれのブランチに修正版が配布されています。

「最新の7系に上げられないから何もできない」ということはありません。

Step 2 自動更新をONにする

WordPress本体のマイナーアップデート(7.0.2から7.0.3のような更新)は、標準では自動適用される設定になっています。

ただし、サーバー会社の設定やセキュリティ系プラグイン、wp-config.phpへの記述で無効化されているケースが実際にあります。

今回、強制更新が配られたのに直っていなかったサイトは、ほぼこのパターンです。

一方、プラグインの自動更新は標準では無効です。「プラグイン」一覧の右端にある「自動更新を有効化」を、少なくとも常時使っている主要なプラグインについては有効にしてください。

Step 3 プラグインとテーマを棚卸しする

ここが実は一番効きます。使っていないプラグインは「停止」ではなく「削除」してください。停止中でもファイルはサーバー上に残っており、脆弱性を突かれるときに有効・無効は関係ありません。

併せて、次のものは入れ替えを検討してください。

  • 1年以上更新されていないプラグイン作者が事実上メンテナンスをやめている可能性が高く、穴が見つかっても直りません。
  • 公式ディレクトリ以外から入れたプラグイン・テーマ有料テーマの海賊版などは、最初からバックドア入りであることが珍しくありません。
  • 同じ機能が重複しているプラグイン攻撃される面積を、無駄に増やしているだけになります。

なお、前述の「Advanced Responsive Video Embedder」のバージョン10.8.7を使っていた場合は、削除するだけでは終わりません。

次のStep 4の点検を必ず実施してください。

Step 4 すでに侵入されていないか点検する

wp2shellはすでに悪用が確認されています。つまり「更新したから安心」ではなく、更新する前に入られていなかったかを確認する必要があります。

次の項目を上から順に見てください。

確認する場所見るポイント
ユーザー一覧見覚えのない管理者アカウントが増えていないか
プラグイン一覧自分で入れた覚えのないプラグインがないか
サーバー上のファイルwp-content/uploads の中に .php ファイルが置かれていないか
ファイルの更新日時直近1か月で、触った覚えのないPHPファイルが書き換わっていないか
Search Console「セキュリティと手動による対策」に警告が出ていないか
Google検索「site:自社ドメイン」で検索し、身に覚えのないページが出てこないか
アクセスログ/wp-json/batch/v1 宛のPOSTリクエストが記録されていないか

最後の項目が、wp2shellを試された痕跡にあたります。

ログの保存期間はサーバー会社によって異なりますが、7月中旬以降のログが残っていれば確認する価値があります。

ひとつでも当てはまった場合、自力での復旧はおすすめしません。

裏口は複数仕掛けられているのが普通で、目に見えるファイルを消しただけでは数日後に元通りになります。

バックアップからの復元と、パスワード・認証キーの全面的な入れ替えを含めた対応が必要です。

Step 5 「誰が見るのか」を決める

技術的な対策以上に効くのが、これです。制作会社に作ってもらったきり、更新の担当者が誰なのか決まっていない。前任者が退職して管理画面のパスワードが分からない。そういう状態のサイトが、実際にはかなりの割合で存在します。

最低限、次の3つを決めておいてください。

  • 管理画面に入れる人が誰か退職者のアカウントが生きたままになっていないかも、併せて確認します。
  • 月1回、誰が更新を確認するか作業自体は5分で終わります。決めていないから誰もやらない、というだけの問題です。
  • 緊急時に誰へ連絡するか制作会社との契約に保守が含まれているかどうかを、契約書で確認しておいてください。「作って終わり」の契約になっていることは珍しくありません。

そもそも、WordPressを使い続けるべきか

ここまで読んで「WordPressは危ないのでは」と感じた方もいるかもしれません。公平に書きますが、WordPressが特別に脆弱なわけではありません。

世界のWebサイトの4割前後で使われているため、攻撃者にとって最も費用対効果の高い標的になっている、というのが実態です。

ただし、構造上の性質はあります。

ページを表示するたびにサーバー上でプログラムが動く仕組みである以上、そのプログラムに穴があれば侵入経路になります。そして機能をプラグインで足していく思想である以上、他人が書いたコードを何十個も同居させることになります。

これは「更新され続けることを前提にした仕組み」であり、更新が止まった瞬間にリスクだけが残ります。

更新を継続的に回せる体制があるなら、WordPressで何の問題もありません。

そうでない場合は、そもそもサーバー上でプログラムを動かさない構成(静的サイト)や、記事の管理画面とサイト本体を分離する構成(ヘッドレスCMS)という選択肢があります。

ページを配信するだけのサーバーには、乗っ取るべきプログラムも、書き換えるべきデータベースも存在しません。

弊社のこのサイトも、記事の管理はクラウド上のCMSで行い、公開されているページ自体は静的ファイルとして配信する構成にしています。

今回のような本体の緊急アップデートに追われることはありません。

もちろん、会員機能やECのようにプログラムが必要な要件もありますから、一律にどちらが良いという話ではありません。

サイトに何を求めるかで、選ぶべき仕組みは変わるというだけの話です。

まとめ

2026年7月から8月にかけて起きたことを、もう一度短く整理します。

  • 7月17日WordPress本体に、ログイン不要でサイトを乗っ取れる「wp2shell」の修正版が公開された。すでに実際の攻撃に使われている。
  • 7月28日人気プラグインが、裏口を仕込まれた状態で配布された。約2万サイトが対象。
  • 8月6日WordPress 7.0.3で、ログイン画面から乗っ取りに繋がる脆弱性ほか11件が修正された。

やることは、バージョンの確認、自動更新の有効化、使っていないプラグインの削除、そして侵入の痕跡がないかの点検です。全部合わせても30分ほどで終わります。

「自分のサイトが該当するのか分からない」、「点検してみたが判断がつかない」という場合は、MyChoiceでも状況の確認を承っています。

現在のバージョンと導入プラグイン、検索結果に不審なページが出ていないかを見るところからで構いません。

集客が止まってから動くより、はるかに安く済みます。

参考にした情報

本記事の内容は2026年8月12日時点の公開情報にもとづいています。脆弱性の状況は日々更新されるため、対応にあたっては必ず最新の公式情報をご確認ください。

← コラム一覧に戻る