--- title: "WordPress のセキュリティ更新が多いのは危険だから ? 安全を支える仕組みを知る" canonical_url: "https://olein-design.com/blog/wordpress-security-release-ecosystem" language: "ja" date_published: "2026-10-07T11:12:35+09:00" date_modified: "2026-10-07T11:12:37+09:00" content_type: "post" author: "久野晃司" taxonomies: category: - "WordPress" --- # WordPress のセキュリティ更新が多いのは危険だから ? 安全を支える仕組みを知る 最近、**WordPress のセキュリティリリースを受けて、SNS で「WordPress は危ない」といった声を見かけます。**更新の知らせが続くと、使い続けて大丈夫なのか、気になりますよね。 僕は、その知らせの背後で動いている人や仕組みも、もう少し知られてほしいと感じています。問題を見つける人がいて、報告を受け取り、修正を作り、利用者へ届ける人がいる。セキュリティリリースは、その働きが表に見える場面でもあるからです。 **更新の回数だけで、WordPress の危険性は判断できません。** この記事では、問題の発見から自分のサイトへの更新までをたどり、通知をどう受け止めればよいかを整理します。 リリースや対応方針は、2026年10月7日時点の公式情報をもとにしています。 ## 更新の知らせから分かること WordPress では、サイトの情報が漏れたり、許可されていない操作ができたりする原因になる、プログラム上の弱点を修正しています。このような弱点を「脆弱性」といい、その修正を含む更新がセキュリティリリースです。 直近の WordPress 7.1 系列では、次の更新が公開されました。 | 公開日 | バージョン | 公式発表の内容 | | --- | --- | --- | | 2026年9月17日 | [7.1.1](https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/) | 11件のセキュリティ修正と通常の不具合修正 | | 2026年9月22日 | [7.1.2](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/) | 重大度が「critical」とされる脆弱性への修正 | | 2026年10月6日 | [7.1.3](https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/) | 7件のセキュリティ修正と4件の不具合修正 | ここにある件数は修正の件数で、被害を受けたサイトの数ではありません。また、すべての問題が同じ条件で起こるわけでもありません。7.1.2 の発表では、サーバー環境と使用中のテーマが一定の条件を満たす場合に、攻撃者が不正な処理を実行できる問題が説明されています。「critical」は深刻な問題であることを示す重大度の区分です。 条件があるから放置してよい、という意味ではありません。この3回の更新では、公式はいずれも速やかな更新を勧めています。 更新の知らせから読み取れるのは、修正が必要な問題があり、その対応が公開されたということです。回数だけを見ても、自分のサイトへの影響や、実際に悪用されたかどうかまでは分かりません。 ## 安全を支えるのは、開発者だけではない WordPress の安全には、プログラムを作る開発者に加えて、弱点を調べる研究者や、報告を確認して修正につなぐセキュリティチームが関わっています。 たとえば、[7.1.3 の公式発表](https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/)には、Trail of Bits、Anthropic、Patchstack、個人の研究者、WordPress のセキュリティチーム所属者への謝辞が記載されています。ひとつの組織だけに任せるのではなく、異なる立場から問題が報告されていることが分かります。 報告された問題を修正するのは、WordPress Security Team と呼ばれる専門チームです。[公式のセキュリティ方針](https://wordpress.org/about/security/)では、修正とテストに加え、サイトを動かす環境を提供するホスティング事業者や、セキュリティ事業者との連携も説明されています。 こうした、複数の人や組織が支える仕組みを「エコシステム」と呼びます。**僕が伝えたいのは、この仕組みの価値**です。**問題を見つけて終わりにせず、修正を利用者へ届けるところまで、役割をつないでいる**んですね。 ## 問題が見つかってから、サイトが更新されるまで WordPress 本体の一般的な対応と、サイト側の作業を並べると、次のような流れになります。 ![](https://olein-design.com/wp-content/uploads/2026/10/image-1024x576.png) 図は一般的な流れを整理したものです。案件によって順序や期間は異なり、すべて悪用前に修正されるという保証ではありません。 ### なぜ、最初は非公開で報告するのか 本体の脆弱性を見つけた人には、HackerOne という報告窓口を通じて、セキュリティチームへ非公開で知らせるよう案内されています。 修正が用意される前に、弱点の詳しい情報を広く知らせると、その情報を攻撃に使われるおそれがあります。先に担当チームへ伝え、修正を準備できるようにするための手順です。[公式の報告手引き](https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/)では、修正が公開されるまで詳細を共有しないよう求めています。 研究者の協力を促すため、新たな脆弱性の報告には報奨金の仕組みもあります。正式公開前のテスト版を調べる期間には報奨金を増額し、公開前の発見を後押ししています。 ### 修正の公開と、自分のサイトの更新は別 チームは報告に基づいて修正を作り、テストを行って公開します。ただ、修正版が公開されても、自分のサイトへ適用されていなければ、その修正は反映されません。 自動更新に対応したサイトでは、更新処理が自動で始まります。それでも、設定されていることと、更新が完了したことは分けて確認したいところです。 旧バージョンにも修正が提供される場合がありますが、**正式にサポートされるのは最新バージョンです。** 7.1.3 の発表では、旧系列への修正提供は準備ができ次第行うとされています。「古い系列にも修正が出ることがある」からといって、使い続けられる保証にはなりません。 ## 最近は、報告を受け止める体制も強化されている 2026年8月28日、WordPress は「Core Security Initiative」という、本体の安全性を高める取り組みを[発表しました](https://make.wordpress.org/security/2026/08/28/the-core-security-initiative/)。背景には、AI による調査支援などで、寄せられるセキュリティ報告が増えていることがあります。 **報告が増えたことは、新しい弱点が同じだけ増えたことを意味しません。**調べ方が進歩し、以前からあった問題が見つかることもあります。これは報告件数を読むときに分けて考えたい点です。 発表では、修正を確実に届けるためのリリース工程とテストの改善、未処理の報告に対応する人員の拡充、AI を使った弱点の探索を進めるとしています。 **問題を調べる人が増えれば、報告を確認し、修正する側にも仕事が増えます。問題の発見だけでなく、報告を修正へつなぐ体制も整えようとしている。その動きも、更新の知らせと一緒に見てほしい**と思います。ただし、これは強化に向けた取り組みで、未処理の問題がすべて解消したという発表ではありません。 ## 本体以外にも確認が必要な理由 WordPress サイトには、本体のほかに、見た目や表示を担う「テーマ」、機能を追加する「プラグイン」があります。サイトを動かすサーバーや、ログインに使うアカウントも管理の対象です。本体の更新だけで、これらすべての問題が直るわけではありません。 公式のプラグイン配布サイトにも、開発者や審査チームへ問題を報告する[経路があります](https://developer.wordpress.org/plugins/wordpress-org/reporting-plugin-security-issues/)。問題が解決するまで、新規ダウンロードを止める対応もあります。ただ、配布停止だけで、すでに使っているサイトが修正されるわけではありません。 2026年9月には、プラグイン更新の[配布前の自動セキュリティレビュー](https://make.wordpress.org/plugins/2026/09/09/automated-security-review-for-plugin-releases/)も発表されました。問題のある更新を利用者へ届ける前に止めるための仕組みです。対象は公式の配布経路であり、検査を通ったものが無欠陥であるという保証ではありません。配布前の確認とサイト側の更新の関係は、[プラグインの配布と更新の仕組みを解説した記事](https://olein-design.com/blog/arve-backdoor-wordpress-auto-update-cycle)でも扱っています。 修正そのものに追加対応が必要になる場合もあります。2026年3月の [WordPress 6.9.4](https://wordpress.org/news/2026/03/wordpress-6-9-4-release/) は、それ以前のセキュリティ修正の一部が完全に適用されていなかったため、追加公開されました。 僕は、こうした点も隠さず伝える必要があると思っています。対応の仕組みを評価することと、修正を完全だとみなすことは別です。更新が続く理由を、すべて「先手の対応」で説明することもできません。 ## 更新通知を見たら、確認したいこと 仕組みを理解したうえで、サイト所有者として確認したいのは、修正が自分のサイトへ届いているかです。 - **公式発表と適用結果**: 何の更新か、利用中のバージョンが対象か、更新後のバージョンは何かを確認する。本体に加えて、テーマとプラグインの更新状況も見る。 - **作業担当と復旧の準備**: 誰が更新するのか、更新前のデータを保存したバックアップがあるか、問題が起きた場合に戻せるかを確認する。 - **更新後の動作**: サイトの表示、管理画面へのログイン、問い合わせフォームなど、普段使う機能を確認する。 管理画面へ入れる方は、表示されているバージョンや更新通知を確認できます。作業を保守担当者へ任せている場合は、適用した更新と、その後の確認結果を聞いてみてください。更新前のバックアップは、[公式の更新手引き](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/)でも案内されています。 セキュリティ更新を適用できないときは、理由が分からないまま延期せず、担当者へ速やかに相談しましょう。管理権限や担当者が不明、復旧方法が分からない、更新が失敗した、身に覚えのない変更がある場合も、専門家と状態を確認したいところです。 相談するときは、サイト URL、分かる範囲のバージョン、更新通知やエラーの内容、異変に気づいた日時を整理しておくと話を進めやすくなります。パスワードなどの認証情報は、公開の場へ書かないでください。 制作・保守を担当する側も、更新した件数だけでなく、対象を確認し、修正を適用し、表示や機能を確認した結果まで、所有者へ伝えたいですね。継続的な確認については、[WordPress の保守で毎月確認する項目](https://olein-design.com/blog/wordpress-monthly-maintenance-checks)も参考にしてください。 更新の知らせを見たときに、その背後で動いている人たちと、自分のサイトで必要な作業を思い浮かべられる。この記事が、そのためのきっかけになれば嬉しいです。 自分のサイトの更新状況や管理体制が分からず、どこから確認すればよいか迷う場合は、[オレインデザインのお問い合わせフォーム](https://olein-design.com/contact)からご相談ください。現在の状態を伺い、必要な確認と対応範囲を整理します。