WordPressの脆弱性対策｜更新中を狙う新たな弱点と会社サイトの点検手順

WordPress 7.1.4で何が修正されたのか？

WordPress 7.1.4は、2026年10月28日に公開されたセキュリティ専用のリリースです^[1][2]。WordPress.orgの詳細資料は修正した脆弱性を22件と数え、Patchstackの集計では17件のアドバイザリにまたがります^[2][4]。3週間前の7.1.3が修正したのは7件でしたから、短期間に件数が大きく増えたことになります^[4]。

1. 10月28日 17:13（UTC）

   WordPress 7.1.4を公開

   WordPress.orgが告知を公開し、「セキュリティリリースのため、直ちにサイトを更新することを推奨する」と呼びかけました。自動バックグラウンド更新に対応したサイトでは更新が自動で始まります^[1]。

2. 同日 20:30（UTC）

   Wordfenceが防御ルールを配備

   公開から約3時間後に、有料版の利用者へ新しいファイアウォールルールを配信しました。無料版への配信は30日後の11月27日です^[3]。

3. 配備の9分後

   最初の攻撃試行を検知

   新ルールへの最初の一致は配備から9分後に到着し、その後21時間で、展開中のインストーラーを狙うリクエストを18,500件超記録しました^[3]。

4. 10月29日

   国内のホスティング事業者が告知

   お名前.comレンタルサーバーは、自動更新の利用者も管理画面でバージョンを確認するよう案内しました。掲載時点で悪用の情報は公表されていないとしています^[10]。

5. 10月31日

   CVE-2026-119977が公開

   WordfenceがCNA（CVE番号を割り当てる機関）として、CVSS 8.1（High）、影響範囲4.7.0〜7.1.3のレコードを公開しました^[5]。

6. 11月3日時点

   国内の注意喚起はまだ

   IPAとJPCERT/CCの2026年の注意喚起一覧には、7.1.4に関する項目はありません。IPAの直近の項目は11月2日、JPCERT/CCは10月29日の、いずれもPHP脆弱性に関する更新です^[18][19]。

22件の内訳を見ると、ほとんどは「投稿者（Contributor）以上のアカウントを持つ人」が細工した内容を投稿することが起点で、その多くは管理者や訪問者がその内容を開いたときに動く格納型クロスサイトスクリプティング（XSS）です^[3][4]。アカウントを必要としないものは2つあり、ひとつは認証なしで非公開のカスタマイザー変更セットを見つけられる情報漏えい、もうひとつがこの記事の主題である更新処理中のリモートコード実行（RCE。遠隔から任意のコードを実行させる攻撃）です^[1][4]。

古いブランチへの修正は「好意（courtesy）として」提供されており、公式にサポートされるのは最新版だけです^[1][2]。W3Techsの統計では、WordPressを使うサイトのうちバージョン7系は67.9%で、残る約3割は6系以前を使っています^[13]。古い系統のサイトは、該当する修正版（6.9.11、6.8.12など）に上がっているかを個別に確かめる必要があります^[2]。

更新中を狙う弱点はどのような仕組みか？

結論から言えば、WordPress本体を更新するとき、新しいファイル一式を予測できる名前の仮置き場に、外から見える状態で展開していたことが原因です^[3][4]。更新パッケージにはWordPressのインストーラーも含まれているため、展開が終わって片付けられるまでの数秒間に、外部の第三者がそのインストーラーに到達すると、サーバー上でPHPコードを実行される経路が生まれます^[3][4]。

Patchstackのコード解析によると、7.1.4までは展開フォルダの名前がパッケージ名から決まるため管理画面経由の更新では完全に予測でき、しかも展開前に走る掃除の処理が、フォルダの一覧表示を防いでいたindex.phpまで消していました^[4]。7.1.4ではフォルダ名に16文字のランダムな文字列を付け、index.phpを作り直して消さないようにし、仮置きした設定データを本番に昇格させない処理を加えています^[3][4]。告知には書かれていない変更として、wp-config.phpを作業ディレクトリから決してコピーしないファイルの一覧に追加した点もPatchstackは挙げています^[4]。

深刻度の評価もこの性質を反映しています。CVE-2026-119977のCVSS 3.1は8.1（High）で、ネットワーク経由・権限不要・ユーザー操作不要ながら、攻撃複雑度は「高」です^[5]。Patchstackは「窓はごく小さく、更新が走る瞬間に正しいパスを要求しなければならない」として、実用的に悪用できるとは言えないと評価しました^[4]。一方で同社は、アカウントも操作も要らないこと、原因となるコードがWordPress 2.8に由来する古いものであること、そして無人の自動更新を含め、更新のたびに窓が開くことを注意点として挙げています^[4]。

対策で重要なのは、WordPressの中で動くPHPのファイアウォールではこの攻撃を止められない点です。展開された一式は自分のファイルだけで起動し、公式パッケージにはサイト側の保護機能を読み込む仕組みが含まれないため、サイトのファイアウォールはその要求に対して動きません^[4]。Patchstackは、Webサーバー側でwp-content/upgrade/へのアクセスを拒否し、そのディレクトリが一覧表示できないことを確認するよう勧めています。更新と更新の間、この場所にはindex.php以外何も置かれません^[4]。Wordfenceも、自社製品の利用者に対し、WordPressが読み込まれる前に動く「Extended Protection」が有効かを確認するよう求めています^[3]。

攻撃者はどれくらい速く動いたのか？

今回の弱点は悪用が難しいにもかかわらず、攻撃者は公開当日のうちに動き始めました^[3]。これは偶然ではなく、7月のwp2shellでも同じ行動が観測されています。7月のwp2shellでは、修正版7.0.2の公開から約90分、修正コミットから3時間で最初の悪用試行が観測されています^[7]。

wp2shellのときは、97%の攻撃がREST APIの特定の入口を狙い、最初は脆弱性の有無を確かめる探索が大半で、ごく少数の送信元だけが管理者アカウントの作成まで進む完全な連鎖を送っていました^[7]。Patchstackは「ほとんどの者がまだドアを叩いている間に、少数の運用者がすでに中へ入ろうとしていた」と表現しています^[7]。さらに公開直後に各社が配布したWAFルールの多くはURLだけを見ており、入口の指定をリクエスト本文に移すと素通りする欠陥が業界横断で見つかりました^[7]。

Microsoftが2026年11月2日に公開した分析は、この速さの背景を数字で示しています。1999年から2026年9月までに公開された約383,000件の脆弱性のうち、実際の攻撃に使われたのは約2,000件（約0.5%）にとどまりますが、その中身は偏っています^[15]。サーバー側のRCEは公開されたCVE全体の20%なのに、悪用されたCVEでは37%を占め、逆にXSSは15%から4%に下がります^[15]。攻撃者は「システムを乗っ取れる」種類の弱点を選んで、素早く狙うということです^[15]。

2026年のWordPressはなぜ弱点が続いているのか？

2026年に入って、WordPress本体では7月・9月・10月と、ログイン不要かつ被害者の操作なしでコード実行につながる弱点が3度公表されました^[6][8][3]。それぞれ原因は異なりますが、7月と10月の件では「公開された修正から攻撃者が仕組みを読み取り、数時間以内に自動化した攻撃を始める」という流れが共通して観測されています^[7][3]。

狙われ続ける背景には、利用の広さがあります。W3Techsによれば、WordPressはCMS（コンテンツ管理システム）が判明しているサイトの58.2%、全サイトの39.5%で使われています^[13]。日本ではさらに集中しており、.jpドメインでCMSが判明しているサイトの78.8%がWordPressです（2026年11月2日時点）^[14]。ひとつの弱点が見つかれば、同じ手口が国内の会社サイトの大半に当てはまる構造です。

もうひとつの背景は、公開サーバーが常に探索されている現実です。警察庁が観測した令和8年上半期の不審なアクセスは、1日・1IPアドレス当たり13,687件で前年同期比50.7%増、大部分が海外の送信元でした^[16]。攻撃者は特定の企業を選んで狙うのではなく、インターネット全体を機械的に走査し、弱点のあるサイトを見つけ次第侵入します。会社の規模や知名度は、狙われにくさとは関係がありません。

日本の会社サイトにはどのような影響があるのか？

日本の企業にとって現実的な影響は2つあります。ひとつは、7.1.4への更新が本当に完了しているかを、自社の全サイトについて確かめる作業が必要なことです^[9][10]。もうひとつは、本体だけでなくプラグインの弱点から侵入され、長期間気づかれないという事例が、同じ時期に国内で公表されていることです^[11]。

株式会社ティエスエスリンクは2026年10月21日、外部委託で運用していたウェブサイトの管理に使っていたWordPressプラグインの脆弱性が悪用され、不正アクセスが発生したと公表しました^[11]。影響を受けた期間は2026年6月12日から10月13日までの約4か月で、判明したのは10月13日です^[11]。対象は企業サイト・製品サポートサイト・評価版ダウンロードサイト・製品ヘルプサイトの4つで、問い合わせフォームの入力内容約160件（氏名、メールアドレス、電話番号、会社名、問い合わせ内容、添付ファイルなど）と、製品サポートサイトの認証情報約250件（ユーザーIDとログイン用パスワード）が漏えいした可能性があるとしています^[11]。

この公表から読み取れる教訓は3つあります。第一に、同社は「不正な管理者アカウント、不正ファイル、不正利用されたプラグイン等を削除」したと説明しており、侵入後に管理者アカウントが作られ、ファイルが置かれていたことが分かります^[11]。第二に、「不正アクセスの影響を受けた期間の一部について記録が残っていない」ため、送信された情報が第三者に取得された可能性を完全には否定できないとしています^[11]。ログが残っていなければ、被害の範囲を狭めることもできません。第三に、再発防止として外部委託先への指揮・監督とセキュリティ管理状況の確認を強化すると述べており、委託先任せの運用が見直しの対象になっています^[11]。同社は10月20日に個人情報保護委員会へ報告しています^[11]。

IPAは2026年10月9日、不正アクセスによる情報漏えいの公表が相次いでいることを受け、経営者に向けて速やかに実施すべき点検を示しました^[12]。外部に公開しているアプリケーションがあるかの確認、直近のログに異常がないかの確認、構成要素に未適用のパッチがないかの確認、そして「作ったはずのないアカウントが存在しないか」の確認です^[12]。WordPressの会社サイトは、まさにこの「外部公開アプリケーション」に当たります。

今週中に確認することは何か？

最初にやることは、自社が持つWordPressサイトをすべて洗い出し、それぞれのバージョンを管理画面で確認することです^[10][12]。自動更新が有効でも、更新が止まっていたり失敗していたりする例があることは、ホスティング事業者自身が注意を促しています^[9][10]。そのうえで、次のチェックリストを上から順に進めてください。

レンタルサーバーを使っている場合、事業者が告知や強制更新を行うことがありますが、それで終わりではありません。エックスサーバーは9月の件で、攻撃成立条件に該当するサイトを事業者側で更新したうえで、「サイトの状態によっては弊社にてアップデートを完了できなかったケースがございます」と案内しています^[9]。お名前.comも今回、自動更新の利用者に対して「念のため、WordPress管理画面でバージョンをご確認ください」と求めました^[10]。完了の確認は、利用者の仕事です。

中長期で見直すことは何か？

今週の点検が終わったら、次に備える体制を作ります。2026年の7月と10月の件は、「公開から数時間で攻撃が始まる」ことを前提にした運用でなければ間に合わないことを示しました^[3][7]。中長期の見直しは、把握・更新・検知・確認の4つに分けると整理しやすくなります。

• 把握：経済産業省のASM（Attack Surface Management）導入ガイダンスが示すように、外部からアクセスできる自社のIT資産を発見し、脆弱性などのリスクを継続的に検出・評価する仕組みを持つ。担当部署が分かれたサイトや、キャンペーン終了後に放置されたサイトが見つかることが多い^[17]
• 更新：本体・プラグイン・テーマの更新を誰がいつ行い、誰が完了を確認するかを文書にする。委託契約には更新と報告の義務、ログの保存期間、事故時の連絡経路を入れる^[11]
• 検知：WordPressの中で動く保護だけに頼らず、Webサーバーや前段のWAFで守る層を持つ。7月の件では公開直後のWAFルールの多くが回避できたため、ルールの更新頻度も確認する^[4][7]
• 確認：定期的に、また大きな改修のたびに、公開サイトとプラグインの脆弱性診断を受け、見つかった弱点を直したことを再テストで確かめる。投稿者以上のアカウントから何ができるかも診断の範囲に入れる（Patchstackも投稿者以上の保有者の棚卸しを勧めています）^[4]

脆弱性診断の観点では、今回の弱点は「本体のバージョンが古いか」だけを見る診断では見つからない種類のものです。仮置き場が外部から見えるか、不要なディレクトリが一覧表示できるか、投稿者権限から管理者権限へ上がる経路がないか、といった設定と権限の組み合わせを攻撃者の視点で確かめる必要があります^[4]。ホワイトハッカーによる攻撃演習と弱点診断の流れでは、こうした公開Webアプリケーションの診断を、報告書と再テストまで含めて説明しています。

ソーシャルエンジニアリングとの接点も見落とせません。ティエスエスリンクは「本件に乗じた当社を装う不審なメール等が送られる可能性」に注意を呼びかけています^[11]。サイトから漏れた問い合わせ内容や担当者名は、取引先を装う電話やメールの材料になります。ハッキングとAI詐欺の手口で解説している手口は、こうした漏えいの後に続くものです。関連する対策は、不正ログイン対策の記事とお問い合わせフォームの点検の記事でも扱っています。

まとめ

WordPress 7.1.4は、更新処理中の数秒間に認証なしでコードを実行される弱点を含む22件を修正しました^[1][2]。悪用は難しいと評価されていますが、攻撃者は防御ルールの配備から9分で動き始め、同じサイト群を14.5時間覗き続けました^[3][4]。7月のwp2shell、9月のCVE-2026-87902と並べると、本体の重大な弱点が短い間隔で公表され、7月と10月には修正の公開から数時間で攻撃が始まったことが分かります^[6][7][8]。

• 今週：全WordPressサイトのバージョンを管理画面で確認し、7.1.4か系統ごとの修正版に上げる。手動更新の前にwp-content/upgrade配下への外部アクセスを塞ぐ^[2][4][10]
• 今週：プラグイン・テーマの更新と削除、管理者・投稿者以上のアカウントの棚卸し、ログの保存状況の確認^[4][11][12]
• 今月：委託先・レンタルサーバーとの役割分担を文書にし、更新と完了確認の責任者を決める^[9][11]
• 継続：公開資産の棚卸し（ASM）と、設定・権限まで見る脆弱性診断を定期的に行い、直したことを再テストで確かめる^[17]

.jpのサイトの大半がWordPressで動いている以上、WordPressの弱点は日本の会社サイトの弱点です^[14]。更新ボタンを押すこと自体は数分で終わりますが、「全サイトを把握している」「誰が更新と確認を担うか決まっている」「異常に気づける記録が残っている」という3つが揃っていなければ、次の弱点のときに同じ不安を繰り返します。前回の記事AIサイバー攻撃の事例で見たとおり、侵入口になるのは目新しい手口ではなく、把握されていない既知の弱点です。よくある質問はFAQにもまとめています。