速さの理由を知る。安全の仕組みを知る。WordPress運用の「なぜ？」を解く技術コラム。

脆弱性が見つかることは、危険なことなのでしょうか～WordPress の脆弱性 wp2shell から考えたこと

相原 知栄子/ Chieko Aihara
DEEP
セキュリティ
OSSWordPress
This entry is in the series KUSANAGIプロダクトマネジャーのブログ

こんにちは。KUSANAGI 開発チーム、プロダクトマネジャーの相原です。

2026年7月に公表された WordPress 本体の脆弱性「wp2shell」以降、「WordPress は危ないのではないか」という声を耳にする機会が増えました。お客様から同じ趣旨のご質問をいただくこともあります。

わたしたちは WordPress の実行環境をつくる立場です。だからこそ、この問いには正面からお答えしたいと思いました。今回は、あのとき実際に何が起きていたのか、そして「脆弱性が見つかる」ということをどう受け止めればよいのかについてお伝えします。

wp2shell とは何だったのか

wp2shell は、ひとつの脆弱性の名前ではなく、2つの不具合を連鎖させる攻撃手法に付けられた呼び名です。

ひとつは REST API のバッチ処理で、どの要求がどの処理に対応するかの紐づけがずれてしまう不具合（CVE-2026-63030）。もうひとつは、投稿を検索する内部のしくみ WP_Query の特定のパラメータに細工した値を渡せてしまう SQL インジェクション（CVE-2026-60137）です。この2つを組み合わせると、ログインしていない第三者が、プラグインを何も入れていない標準構成のサイトに対しても攻撃を成立させられる状態でした。

修正は 2026年7月17日にリリースされています。6.8 系は 6.8.6、6.9 系は 6.9.5、7.0 系は 7.0.2 です。

本体の、しかも未認証で悪用されうる脆弱性ですから、深刻な事案であったことは間違いありません。そのうえで、お伝えしたいことがあります。

見えていなかったのは、公表までの動き

多くのサイト運営者が目にしたのは「今すぐ WordPress を更新してください」という一文だったと思います。けれど、その一文の裏側では、公表よりずっと前から準備が動いていました。

脆弱性を見つけた研究者は、詳細を先に公開せず、責任ある形で報告しました。WordPress のセキュリティチームは内容を検証し、修正を用意したうえで、公表前にホスティング事業者や CDN、セキュリティベンダーへ必要な情報を共有しています。情報を受け取った各社は、それぞれのレイヤーで防御を用意しました。

実際、Cloudflare の WAF ルールは無料プランを含めて修正版と同じ7月17日に有効化され、Wordfence のファイアウォールルールも同日にリリースされています。発見者である Searchlight Cyber は、管理者が更新する時間を確保するために技術的な詳細を伏せ、自分のサイトが影響を受けるかどうかを確認できるチェッカーだけを先に公開しました。

そして WordPress 側は、深刻度を踏まえて強制的な自動更新を有効にしました。用意された修正と防御が、そこで一斉に届いたことになります。

つまり、多くの人が問題を知った時点では、すでに保護がエコシステム全体に広がりはじめていたということです。

わたしはこの一連の動きを、とても素晴らしい例だと感じています。どれかひとつの会社だけでは、絶対に成立しなかった動きです。研究者、セキュリティチーム、ホスティング事業者、セキュリティベンダー、そして自動更新のしくみ。それぞれが役割を持ち、しかも普段から信頼関係があったからこそ、あの短時間で動けたのだと思います。

わたしたちが毎週お届けしている「Security Advisory for WordPress」も、Wordfence が公開しているデータフィードをもとにしています。わたしたちも、このエコシステムに支えられている一員です。

その後も更新が続いていること

wp2shell のあとも、更新は続いています。8月6日には7.0.3が公開され、クロスサイトスクリプティングや権限昇格、情報漏えい、SSRF など複数の脆弱性がまとめて修正されました。さらに8月12日には7.0.4が公開されています。こちらは Imagick と Ghostscript を使っている環境で、投稿者以上の権限を持つ利用者による任意コード実行につながる可能性があったものです。

短い間隔で更新通知が届くと、落ち着かない気持ちになりますよね。「また更新なのか」と感じている方も多いのではないでしょうか。

背景にあるのは、脆弱性を探す側の技術が進んだことです。wp2shell も、AI を使った解析によって発見されたと公表されています。これまで人の目では見つけにくかった問題が、見つかるようになってきたということです。

そして、ぜひ見ていただきたいのが、修正が届く範囲です。7.0.3のときは6.9系にも6.8系にも同時に修正版が出ました。7.0.4では、修正が4.7ブランチまでバックポートされています。4.7はなんと2016年のバージョンです。

WordPress が公式に active support の対象としているのは最新版だけ、というのが原則です。それでも、そこまで古いブランチにまで修正が届けられている。あまり知られていないけれど、もっと知られてよいところだと思います。

発見が多いことは、危険が増えたことなのか

脆弱性の報告件数が多いことは、そのソフトウェアが危険であることを意味しません。ここも、お伝えしておきたいところです。

分かりやすい例が Linux カーネルです。2024年2月、カーネルプロジェクト自身が CVE を採番できる CNA になりました。その結果、2023年に290件だった CVE が、2024年には3,529件へと10倍以上に増えています。

では、Linux は1年で10倍危険になったのでしょうか。そうではないですよね。数え方と公表の方針が変わったのです。Red Hat の分析でも、kernel.org 由来の CVE を除くと従来どおりの傾向であること、新しく採番されたカーネル CVE の多くは深刻度が中や低であること、現行の RHEL カーネルに実際に影響するのは45%程度であることが整理されています。

WordPress も似た構造です。Patchstack が2026年2月に公開したレポートによると、2025年にエコシステム全体で報告された新規脆弱性は11,334件で、前年から42%増えました。ただし、その91%はプラグイン、9%はテーマで、WordPress 本体で報告されたのは6件、いずれも優先度の低いものでした。

正直なところ、深刻度の高い脆弱性も増えています。2025年に見つかった高深刻度の脆弱性は、過去2年分の合計を上回りました。ただ、その増加の大きな要因として挙げられているのが、マーケットプレイスで販売される有償のプラグインやテーマです。有償製品はコードを研究者が入手しにくく、これまで調査の目が届きにくい領域でした。ここでもやはり、危険が新しく生まれたというより、見えていなかったものが見えるようになった、という話なのだと思います。

数が多く見えるのは、利用者が多く、報告と公表のしくみが機能しているからです。むしろ、誰も報告せず、誰も公表しないソフトウェアのほうが、わたしは怖いと思います。

KUSANAGI にも、毎週のように更新の通知が来ます

実は KUSANAGI も、各クラウドのマーケットプレイスから「イメージを更新してください」という指摘を毎週のように受けています。提供しているマシンイメージは、ある時点のスナップショットです。時間が経てば、含まれているモジュールに新しい脆弱性情報が付くのは当然のことで、だからこそ更新し続けています。ご利用いただく際も、インスタンスを起動したあとに最新化してからお使いいただく流れになっています。

そして、KUSANAGI のモジュールに影響する脆弱性が見つかったときには、KUSANAGI 向けの対応を行ったうえで、KUSANAGI Security Advisory として配信しています。情報を受け取るだけでなく、自分たちで配信する側にも回っています。

では、KUSANAGI は危ないのでしょうか。Linux が危ないのでしょうか。PHP が危ないのでしょうか。

そういうことではないですよね。ソフトウェアは常に更新され、問題が見つかれば直され、それが利用者に届く。その循環が回っていることこそが健全さの証拠なのだと思います。止まっているものだけが、本当に危ないのです。

わたしたちの結論は、まず即時アップデート

wp2shell では、公表からわずか数時間で実証コードが出回りました。Wordfence の観測によると、公表当日の7月17日はまだ探りを入れる程度の試行でしたが、翌18日からは大量の攻撃が始まり、同社のファイアウォールがブロックした試行は1,100万件を超えています。

一方で、更新は確かに効いていました。Wiz の観測によると、CVE が公表された時点で脆弱なインスタンスをひとつ以上抱えていた組織は60%、脆弱なサーバをインターネットに公開していた組織は25%ありましたが、24時間以内にそれぞれ50%、10%まで下がっています。強制的な自動更新と、各社が用意した防御が、実際に危険を縮めたのです。

そしてこれは、特別な事例ではありません。Patchstack の2025年の観測では、実際に激しく狙われた脆弱性が最初に悪用されるまでの時間は、中央値で5時間でした。影響の大きい脆弱性のおよそ半数が、公表から24時間以内に悪用されはじめています。

脆弱性の内容を調べる。使っているモジュールを一覧化する。影響範囲を確認して、テストしてから適用する。どれも正論ですし、本来あるべき手順です。わたしたちもそう教わってきました。

でも、その速度ではもう間に合わない時代になりました。

だから、まずアップデートしてください。ここからだと思っています。少なくとも KUSANAGI は、製品としてお届けする時点で、組み合わせも含めて全体をテストしています。安心して適用していただくために、わたしたちがその工程を引き受けています。

そのうえで、調査も一覧化も検証も、余裕のあるときに積み上げていけばよいのではないでしょうか。順番を入れ替えるだけで、守れるものが変わります。

おわりに

脆弱性が見つかったというニュースを見ると、わたしも身構えます。けれど今回調べてみてあらためて実感したのは、危険が増えたのではなく、見つけて直すしくみが働いていたということでした。

多くの人に使われているから、多くの目に見られ、多くの手で直される。わたしたちも、その一部を担っています。

更新の知らせは、これからも届き続けます。その一つひとつを、安心して適用していただけるようにすること。それがわたしたちの仕事だと思っています。

参考・出典

WordPressサイトをKUSANAGIに移行する方法

by 王文暁

Webサイト運用の課題解決事例100選 プレゼント

Webサイト運用の課題を弊社プロダクトで解決したお客様にインタビュー取材を行い、100の事例を108ページに及ぶ事例集としてまとめました。

・100事例のWebサイト運用の課題と解決手法、解決後の直接、間接的効果がわかる

・情報通信、 IT、金融、メディア、官公庁、学校などの業種ごとに事例を確認できる

・特集では１社の事例を3ページに渡り背景からシステム構成まで詳解

Webサイト運用 課題解決事例100選 プレゼント