WordPress のセキュリティ更新が多いのは危険だから ? 安全を支える仕組みを知る

投稿日：

2026年10月7日

カテゴリー：WordPress

Facebook

LINE

B! ブックマーク

最近、WordPress のセキュリティリリースを受けて、SNS で「WordPress は危ない」といった声を見かけます。更新の知らせが続くと、使い続けて大丈夫なのか、気になりますよね。

僕は、その知らせの背後で動いている人や仕組みも、もう少し知られてほしいと感じています。問題を見つける人がいて、報告を受け取り、修正を作り、利用者へ届ける人がいる。セキュリティリリースは、その働きが表に見える場面でもあるからです。

更新の回数だけで、WordPress の危険性は判断できません。 この記事では、問題の発見から自分のサイトへの更新までをたどり、通知をどう受け止めればよいかを整理します。

リリースや対応方針は、2026年10月7日時点の公式情報をもとにしています。

更新の知らせから分かること

WordPress では、サイトの情報が漏れたり、許可されていない操作ができたりする原因になる、プログラム上の弱点を修正しています。このような弱点を「脆弱性」といい、その修正を含む更新がセキュリティリリースです。

直近の WordPress 7.1 系列では、次の更新が公開されました。

公開日	バージョン	公式発表の内容
2026年9月17日	7.1.1	11件のセキュリティ修正と通常の不具合修正
2026年9月22日	7.1.2	重大度が「critical」とされる脆弱性への修正
2026年10月6日	7.1.3	7件のセキュリティ修正と4件の不具合修正

ここにある件数は修正の件数で、被害を受けたサイトの数ではありません。また、すべての問題が同じ条件で起こるわけでもありません。7.1.2 の発表では、サーバー環境と使用中のテーマが一定の条件を満たす場合に、攻撃者が不正な処理を実行できる問題が説明されています。「critical」は深刻な問題であることを示す重大度の区分です。

条件があるから放置してよい、という意味ではありません。この3回の更新では、公式はいずれも速やかな更新を勧めています。

更新の知らせから読み取れるのは、修正が必要な問題があり、その対応が公開されたということです。回数だけを見ても、自分のサイトへの影響や、実際に悪用されたかどうかまでは分かりません。

安全を支えるのは、開発者だけではない

WordPress の安全には、プログラムを作る開発者に加えて、弱点を調べる研究者や、報告を確認して修正につなぐセキュリティチームが関わっています。

たとえば、7.1.3 の公式発表には、Trail of Bits、Anthropic、Patchstack、個人の研究者、WordPress のセキュリティチーム所属者への謝辞が記載されています。ひとつの組織だけに任せるのではなく、異なる立場から問題が報告されていることが分かります。

報告された問題を修正するのは、WordPress Security Team と呼ばれる専門チームです。公式のセキュリティ方針では、修正とテストに加え、サイトを動かす環境を提供するホスティング事業者や、セキュリティ事業者との連携も説明されています。

こうした、複数の人や組織が支える仕組みを「エコシステム」と呼びます。僕が伝えたいのは、この仕組みの価値です。問題を見つけて終わりにせず、修正を利用者へ届けるところまで、役割をつないでいるんですね。

問題が見つかってから、サイトが更新されるまで

WordPress 本体の一般的な対応と、サイト側の作業を並べると、次のような流れになります。

図は一般的な流れを整理したものです。案件によって順序や期間は異なり、すべて悪用前に修正されるという保証ではありません。

なぜ、最初は非公開で報告するのか

本体の脆弱性を見つけた人には、HackerOne という報告窓口を通じて、セキュリティチームへ非公開で知らせるよう案内されています。

修正が用意される前に、弱点の詳しい情報を広く知らせると、その情報を攻撃に使われるおそれがあります。先に担当チームへ伝え、修正を準備できるようにするための手順です。公式の報告手引きでは、修正が公開されるまで詳細を共有しないよう求めています。

研究者の協力を促すため、新たな脆弱性の報告には報奨金の仕組みもあります。正式公開前のテスト版を調べる期間には報奨金を増額し、公開前の発見を後押ししています。

修正の公開と、自分のサイトの更新は別

チームは報告に基づいて修正を作り、テストを行って公開します。ただ、修正版が公開されても、自分のサイトへ適用されていなければ、その修正は反映されません。

自動更新に対応したサイトでは、更新処理が自動で始まります。それでも、設定されていることと、更新が完了したことは分けて確認したいところです。

旧バージョンにも修正が提供される場合がありますが、正式にサポートされるのは最新バージョンです。 7.1.3 の発表では、旧系列への修正提供は準備ができ次第行うとされています。「古い系列にも修正が出ることがある」からといって、使い続けられる保証にはなりません。

最近は、報告を受け止める体制も強化されている

2026年8月28日、WordPress は「Core Security Initiative」という、本体の安全性を高める取り組みを発表しました。背景には、AI による調査支援などで、寄せられるセキュリティ報告が増えていることがあります。

報告が増えたことは、新しい弱点が同じだけ増えたことを意味しません。調べ方が進歩し、以前からあった問題が見つかることもあります。これは報告件数を読むときに分けて考えたい点です。

発表では、修正を確実に届けるためのリリース工程とテストの改善、未処理の報告に対応する人員の拡充、AI を使った弱点の探索を進めるとしています。

問題を調べる人が増えれば、報告を確認し、修正する側にも仕事が増えます。問題の発見だけでなく、報告を修正へつなぐ体制も整えようとしている。その動きも、更新の知らせと一緒に見てほしいと思います。ただし、これは強化に向けた取り組みで、未処理の問題がすべて解消したという発表ではありません。

本体以外にも確認が必要な理由

WordPress サイトには、本体のほかに、見た目や表示を担う「テーマ」、機能を追加する「プラグイン」があります。サイトを動かすサーバーや、ログインに使うアカウントも管理の対象です。本体の更新だけで、これらすべての問題が直るわけではありません。

公式のプラグイン配布サイトにも、開発者や審査チームへ問題を報告する経路があります。問題が解決するまで、新規ダウンロードを止める対応もあります。ただ、配布停止だけで、すでに使っているサイトが修正されるわけではありません。

2026年9月には、プラグイン更新の配布前の自動セキュリティレビューも発表されました。問題のある更新を利用者へ届ける前に止めるための仕組みです。対象は公式の配布経路であり、検査を通ったものが無欠陥であるという保証ではありません。配布前の確認とサイト側の更新の関係は、プラグインの配布と更新の仕組みを解説した記事でも扱っています。

修正そのものに追加対応が必要になる場合もあります。2026年3月の WordPress 6.9.4 は、それ以前のセキュリティ修正の一部が完全に適用されていなかったため、追加公開されました。

僕は、こうした点も隠さず伝える必要があると思っています。対応の仕組みを評価することと、修正を完全だとみなすことは別です。更新が続く理由を、すべて「先手の対応」で説明することもできません。