NEWS
WordPress更新が続いた2026年秋、小規模サイトの運用ルール
WordPressの公式サイトでは、2026年9月17日、9月22日、10月6日にセキュリティ修正を含むリリースが確認できます（6.9.8、6.6.9、6.9.10）。
まず管理画面で自分のサイトのバージョンを確認し、バックアップを取ってから更新してください。
そのうえで、自動更新の設定、不要なアカウントの整理、更新担当者と頻度を決めておくと、次の更新にも落ち着いて対応できます。
この記事では、公式ページで確認できた内容を整理し、個人事業主や小規模事業者のWeb担当者が自分で点検できる手順をまとめます。
何が起きたか：3回のリリースを時系列で整理
2026年9月17日：WordPress 6.9.8
Version 6.9.8（WordPress公式）には、セキュリティ修正が含まれています。私が確認できた範囲では、少なくとも次の3件です。
- 細工したURLによって、WordPress.orgのテーマをインストール・プレビューできてしまう問題
- 一部テーマのカスタムヘッダー画像に起因する保存型XSS
- 非公開の親投稿のタイトルが漏れる問題
2026年9月22日：WordPress 6.6.9
Version 6.6.9（WordPress公式）の修正は1件です。ページテンプレートを解決する処理でのパストラバーサルで、条件付きでリモートコード実行につながる、認証不要の問題とされています。公式ページは「直ちに更新を推奨」と明記しています。
6.6系という少し古い系統に向けたリリースである点も、あとで触れます。
2026年10月6日：WordPress 6.9.10
Version 6.9.10（WordPress公式）では、次の7件が修正されています。
- コメント管理画面での保存型XSS
WP_Http::make_absolute_url()のDoS- WXRエクスポートでの2次SQLインジェクション
- Author権限のユーザーが投稿を固定表示にできてしまう問題
- 非公開・未公開の投稿のコメントが、認証なしで見える問題
- ImgurエンベッドのXSS
{status}_{type}フックでのアクション名衝突
同じ日に6.6.10も公開され、10月8日に更新されています。ただし、6.6.10の修正内容は、私が確認できた範囲では把握できていません。6.6系を使っている方は、上記の公式ページを直接ご確認ください。
7.0系とサポート状況（二次情報）
ここからは公式の一次情報ではなく、解説サイトの記載に基づく内容です。
endoflife.date（2026年10月7日更新）は、6.9系の通常サポートが2026年5月20日に終了し、6.9系の最新が6.9.10だと記載しています。あわせて「最新版のみが公式サポート対象で、古い版へのバックポートは保証されない」とも書かれています。
また、国内の解説記事（バリューノート、イッソー）によると、WordPress 7.0は2026年5月20日に公開されたとされています。当初は4月9日の予定でしたが、リアルタイム共同編集の品質問題で延期され、その機能は7.0から外されました。AI Client／Connectorsなど、AI連携の基盤が入ったとも紹介されています。
なお、7.0の公式リリースページは今回確認できていません。7.0.1や最新版の番号についても、記事によって記述が食い違っています。バージョン番号や日付は、公開前にwordpress.orgのリリースアーカイブで確認してください。
なぜ重要か
修正内容が「普通のサイト運営」に近い
今回の修正は、コメント管理画面、Author権限、非公開投稿、テーマのヘッダー画像など、日常的に使う機能の周辺にあります。自分のサイトでコメントを受け付けているか、外注先や投稿者のアカウントがあるかによって、関係の度合いは変わるはずです。ただし、どの修正が自分のサイトに影響するかは、設定やテーマ次第で変わります。ここで「うちは大丈夫」と決めつけず、まず更新するほうが現実的です。
古い系統は「直る保証」が弱くなる
6.9.10の公式ページは、最新版のみが積極的にサポートされると注意しています。6.6.9のような古い系統向けの更新が出ることもありますが、いつまで続くかは公式ページからは読み取れません。系統を上げる判断を先送りにすると、あるとき修正が出なくなるリスクがあると考えておくのが安全です（これは私の推測を含みます）。
報告者にAI企業が含まれている
6.9.10の公式ページでは、報告者のうち、DoS・SQLインジェクション・Author権限の3件がAnthropicとされています。これは公式ページ上の事実です。
ただし、この1件の事例だけで「AIが脆弱性を大量に見つけている」と一般化することはできません。実務上言えるのは、脆弱性の報告元が多様になっていて、修正が公開されるペースが読みにくいということくらいです。だからこそ、更新のタイミングを人の気分に任せず、ルールにしておく意味があります。
読者がやること
1. 現在のバージョンを確認する
管理画面の「ダッシュボード」→「更新」で、WordPressのバージョンを確認します。見るポイントは次の2つです。
- 6.9系なら6.9.10以降になっているか
- 6.6系なら6.6.9以降（可能なら6.6.10）になっているか
更新前には必ずバックアップを取ります。ホスティング会社のバックアップ機能でも、プラグインでも構いません。「復元できるか」まで確認できていれば理想です。
2. 自動更新の設定を確認する
マイナー更新（6.9.8→6.9.10のような更新）やセキュリティ更新が自動で入る設定になっているかを見ます。ホスティング側の管理画面で自動更新が止められている場合もあります。
自動更新の挙動は、ホスティングや設定によって変わります。「小規模サイトならこう動く」とは言えないので、自分の環境で確かめてください。自動更新が有効でも、更新が失敗していないかを時々見ておくと安心です。
3. テーマ・プラグイン・PHPの対応状況を確認する
6.9系や6.6系から7.0系へ上げる場合は、メジャーバージョンの更新になります。更新前に次の点を確認します。
- 使っているテーマとプラグインが、7.0系に対応しているか
- PHPのバージョンが要件を満たしているか（要件はイッソーの解説などで触れられていますが、必ず公式で確認してください）
- ステージング環境で試せるか。難しければ、最低でもバックアップを取った状態で試す
あわせて、使っていないテーマとプラグインを削除します。停止しているだけでもファイルは残るため、不要なものは消しておくほうが管理が楽になります。6.9.8には、テーマに関わる修正が含まれていました。
4. 権限を整理する
ユーザー一覧で、次のアカウントを確認します。
- 退職者や、契約の終わった外注先のアカウント
- 実際には使っていないAuthor以上の権限
今回の6.9.10には、Author権限やコメントに絡む修正が含まれていました。権限は必要最小限にしておくと、同種の問題があったときの影響を狭められます（これは一般的な運用上の考え方です）。
5. 更新担当者と頻度を決める
最後に、運用ルールを文章にしておきます。たとえば次のような形です。
- 担当者：誰が確認するか（一人運営なら自分、不在時の代理も）
- 通常の確認：週1回、管理画面の「更新」を見る
- 重大な更新：公式ページで重大とされたものは48時間以内に対応する
- 記録：更新日、更新前のバージョン、バックアップの有無をメモに残す
週1回・48時間以内というのは一例です。自分の業務量や、サイトが止まったときの影響に合わせて調整してください。
7.0系への移行はどう考えるか
7.0系については、公式情報を確認できていないため、ここでは判断の枠組みだけ述べます。
- 今すぐ上げる必要があるのは、すでに修正が出にくい古い系統を使っている場合です。まず自分のサイトの系統とサポート状況を確認します。
- 7.0にはAI連携の基盤が入ったとされますが、使うかどうかは別の問題です。使わないなら、機能を理由に急ぐ必要はないと考えます。
- 上げるときは、テーマ・プラグインの対応確認とバックアップを先に済ませます。
AIツールで文章の下書きを作る、検索のAI回答への対策を考える、といった話題は、サイトが安全に動いている状態を土台にしてから進めるのが順序として自然です。
まとめ
- 2026年9月17日（6.9.8）、9月22日（6.6.9）、10月6日（6.9.10）と、セキュリティ修正を含む更新が続きました。
- 6.6.9は認証不要の問題で、公式ページが直ちに更新するよう推奨しています。6.9.10にはコメントやAuthor権限に関わる修正も含まれます。
- まずバージョン確認とバックアップ。そのうえで自動更新、不要なテーマ・プラグインの削除、権限整理、担当者と頻度の取り決めを進めます。
- 7.0系の公式情報は今回確認できていません。移行前に公式のリリースアーカイブで確認してください。
