WordPressの重大な脆弱性、発注者は何を確認する？7.1.2の緊急更新から考える更新ルールと保守契約

2026年9月27日2026年10月1日

2026年9月22日（米国時間）、WordPress（＝世界中の企業サイトで使われているCMS、つまりホームページを更新するための仕組み）の開発元が、深刻度「クリティカル」の脆弱性（＝セキュリティ上の弱点）を修正する「WordPress 7.1.2」を公開しました。公開から数時間で悪用を試みるアクセスが観測されたと、セキュリティ企業が報告しています。

「うちの会社のホームページもWordPressで作ってもらったはず。でも更新は制作会社に任せきりで、今どうなっているのか分からない…」

先に結論をお伝えします。発注者が技術的な中身を理解する必要はありません。やることは「自社サイトが修正済みのバージョンに更新されているかを、制作会社・保守会社に確認する」ことです。そのうえで今回のニュースを、WordPressの更新を誰がどのタイミングで行うかを保守契約で決め直すきっかけにするのがおすすめです。

この記事では、WordPressの脆弱性ニュースの要点と、Webサイトの発注者にとって何が変わるのか、そのまま使えるチェックリストと開発会社への質問例をまとめます（情報は執筆時点：2026年9月のものです）。

WordPress 7.1.2で修正された脆弱性の要点

まずは、公表されている事実を整理します。

📰 出典：WordPress News「WordPress 7.1.2 Release」

WordPress公式の発表（2026年9月22日）のポイントは次のとおりです。

深刻度「クリティカル」の脆弱性1件（CVE-2026-87902）を修正するセキュリティリリース
認証されていない（＝ログインしていない）外部の人が、一定の条件下で悪用できるおそれがある
修正は、セキュリティ修正の提供対象になっている古い系列（4.7系まで）にもさかのぼって提供された
自動更新（バックグラウンド更新）に対応したサイトでは、更新が自動的に始まる
公式は「すぐにサイトを更新すること」を推奨している

なお、その5日前の9月17日にも、11件のセキュリティ修正を含む「WordPress 7.1.1」が公開されています。短い期間に2回のセキュリティ更新が続いたことになります。

📰 出典：WordPress News「WordPress 7.1.1 Maintenance and Security Release」

影響を受けるのは「4.7〜7.1.1」、ただし深刻な被害は条件付き

開発元のセキュリティ情報によると、影響を受けるのはWordPress 4.7から7.1.1までと、約10年分のバージョンが対象です。一方で、外部から任意のプログラムを実行される（＝サイトを乗っ取られる）ほどの深刻な被害につながるのは、利用しているテーマ（＝サイトのデザインの型）の構成と、サーバー側の設定の両方が特定の条件を満たす場合とされています。条件に当てはまるテーマとして、Twenty Twelve、Twenty Fourteenなど一部のテーマ名が挙げられています。

📰 出典：WordPress GitHub Security Advisory「GHSA-7hp8-65ch-5whp」

修正の公開から数時間で悪用の試みが観測された

WordPressのセキュリティ情報を扱うPatchstack社は、修正が公開された当日（9月22日 11:49 UTC）に最初の悪用の試みを観測し、翌日にはサーバーに不正なファイルを書き込もうとする動きに進んだと報告しています。同社は、攻撃者が公開された修正内容を手がかりに攻撃を組み立てたとみています。

📰 出典：Patchstack「CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch」

海外のセキュリティメディアでも、公開直後から悪用が始まったことが報じられています。

📰 出典：SecurityWeek「Critical WordPress Vulnerability Exploited Immediately After Disclosure」

ここで大切なのは、「WordPressのサイトはすべて乗っ取られる」わけではないという点です。ただし、自社サイトが条件に当てはまるかを判断できるのは、サイトやサーバーを管理している担当者です。発注者が自分で調べる必要はなく、「更新済みか」「条件に当てはまるか」を確認してもらえば十分です。

発注者にとって何が変わるか・変わらないか（筆者の見解）

ここからは、ニュースの事実をふまえた筆者の見解です。

変わらないこと：WordPressは「更新し続ける前提」の仕組み

WordPressは本体・テーマ・プラグイン（＝後から追加する機能部品）のそれぞれで、定期的に脆弱性が見つかり、修正版が出ます。今回が特別なのではなく、「作って終わり」ではなく「更新し続けて使う」ものだという性質は、以前から変わっていません。

発注者が考えるべきなのは「脆弱性の出ないCMS」を探すことではなく、修正版が出たときに、誰がどのくらいの早さで更新するかが決まっている状態にしておくことです。

変わること：「修正が出たら、なるべく早く」の重みが増している

今回は、修正の公開から数時間で悪用の試みが始まりました。修正内容そのものが攻撃の手がかりになるため、「来月の定期メンテナンスでまとめて更新」という運用では間に合わない場面が増えていると考えられます。

一方で、更新には「テーマやプラグインとの相性で表示が崩れる」「独自に作り込んだ機能が動かなくなる」といったリスクもあります。そのため制作会社は、自動更新をあえて止めて、確認してから手動で更新していることがあります。これは手抜きではなく、サイトを壊さないための配慮である場合がほとんどです。「自動更新にしているか、手動で確認して更新しているか」「緊急時は何日以内に対応するか」を発注者が把握しておくことが、これまで以上に大切になります。

開発会社側の事情も知っておく

保守契約の内容によっては、WordPress本体の更新は含まれていても、テーマやプラグインの更新、サーバーの設定変更は範囲外ということがあります。また、保守契約を結ばずに「納品で終わり」になっているサイトも少なくありません。その場合、更新作業に費用がかかるのは自然なことです。今回を機に、範囲を平時のうちに決めておくのが双方にとって安心です。保守費の中身についてはシステムの保守費用は何に払っている？月額保守費の内訳と見直す前に確認したいことも参考にしてください。

今やるべきこと・まだ様子見でいいこと

今やるべきこと

自社サイトがWordPressかを確認する：コーポレートサイト、採用サイト、キャンペーンサイトなど、複数ある場合はすべて洗い出します
修正済みのバージョンかを確認してもらう：7.1.2、または使っている系列の修正版（7.0.6、6.9.9など）になっているかを制作会社・保守会社に確認します
更新後の表示・動作を確認する：問い合わせフォームや会員ログインなど、大事な機能が動くかを社内でも一度触ってみます
確認結果を記録に残す：「いつ・どのバージョンに更新したか」をメールなどで報告してもらいます

まだ様子見でいいこと

CMSの乗り換え検討：一度の脆弱性でWordPressをやめる必要はありません。乗り換えは費用も大きいため、更新体制を整えてから落ち着いて判断すれば十分です
自社での技術的な調査：テーマやサーバー設定が条件に当てはまるかの判断は、管理している担当者に任せましょう
高価なセキュリティ製品の急な導入：まずは「更新が確実に行われる体制」を整えることが先です

発注者がやることチェックリスト

☐ 自社で運営しているWordPressサイトをすべて洗い出した
☐ 各サイトの管理者（制作会社・保守会社・社内担当）が誰かを確認した
☐ WordPressが修正済みのバージョンに更新されていることを確認した
☐ 自動更新の設定（オン／オフ）と、手動更新の場合の対応期限を把握した
☐ 更新後に問い合わせフォームなど主要な機能が動くことを確認した
☐ 保守契約に「本体・テーマ・プラグインの更新」が含まれているかを確認した
☐ 使っていないプラグインや古いサイトが放置されていないかを確認した

開発会社への質問例

打ち合わせやメールで、そのまま使える質問です。

「弊社のWordPressサイトは、9月22日に公開された7.1.2（または同じ系列の修正版）に更新済みでしょうか？」
「弊社サイトのテーマやサーバー設定は、今回の脆弱性が深刻になる条件に当てはまりますか？」
「自動更新はオンになっていますか？手動の場合、緊急のセキュリティ更新は何日以内に対応していただけますか？」
「保守契約の範囲に、WordPress本体・テーマ・プラグインの更新は含まれていますか？範囲外の場合、費用の目安を教えてください」
「万一、不正なファイルが置かれていないかを確認する方法や、バックアップからの復旧手順は決まっていますか？」

発注時にどんなセキュリティ対策を求めるかについては、システム開発の発注でどんなセキュリティ対策を求めればいい？個人情報を扱うサイトの要件の決め方で詳しく解説しています。また、ネットワーク機器の脆弱性を題材にしたF5 BIG-IPの脆弱性、発注者は何を確認する？も、利用製品の棚卸しという点で共通する内容です。

まとめ

2026年9月22日、WordPressの深刻度「クリティカル」の脆弱性を修正する7.1.2が公開され、数時間後には悪用の試みが観測された（執筆時点：2026年9月）
影響は4.7〜7.1.1と幅広いが、乗っ取りのような深刻な被害はテーマとサーバー設定の条件が重なる場合とされている
発注者がやるのは、自社サイトが修正版に更新済みかを制作会社・保守会社に確認し、結果を記録してもらうこと
今回を機に「誰が・どのくらいの早さで更新するか」を保守契約で決め直しておくと、次の脆弱性でも慌てずに済む

WordPressは、更新を続ければ長く安心して使える仕組みです。怖がって手放すのではなく、更新の担当と期限がはっきりした状態を作っておきましょう。

システム発注の相談をする