WordPress 7.1.4がコアRCEを修正、24時間で6万件の攻撃試行｜今すぐ確認を

WordPress が2026年10月28日に 7.1.4 を公開し、コアのリモートコード実行（RCE）を含む複数の脆弱性を修正しました。その直後から、未適用サイトを狙う攻撃の試行が急増しています。この記事は、確定している事実（公式のリリース）と報道ベースの情報（攻撃観測や件数）を分け、WordPress RCE 対策として「自分のサイトが安全な版かをどう確かめ、どう更新するか」を手順に落とします。技術的なPoC（攻撃コード）は扱いません。

なお、WordPress サイトの侵入経路は、今回のようなコア本体だけでなく、プラグイン・テーマ側にあることも多く、これはサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説と地続きの話です。本記事はコアの更新に絞りますが、最後に周辺の守りにも触れます。

何が起きたのか：10月28日の一斉セキュリティリリース

まず、確実に裏が取れている事実から整理します。WordPress の公式ソース（GitHub ミラーのタグ）で、2026年10月28日に 7.1.4 がリリースされたことを確認できます。同じ日付で、サポート中の各枝にも修正版が一斉に出ています。

このように全サポート枝へ同日にバックポートするのは、WordPress が「セキュリティリリース」を出すときの典型的な動き方です。古いメジャー版を使い続けているサイトでも、メジャーアップグレードをせずに自分の枝の修正版へ上げられるようにするための配慮です。逆にいえば、この一斉リリースのパターン自体が「今回は通常の機能更新ではなく、急いで塞ぐべき問題がある」ことの裏づけになっています。

報道（Cyber Security News、脅威情報の出所は Wordfence）によれば、この 7.1.4 は 22件のセキュリティ脆弱性を修正し、その中にコアのリモートコード実行（RCE）が含まれます。あわせて、保存型クロスサイトスクリプティング（stored XSS）、情報漏えい、権限の問題も解決されたとされています。公式の告知は管理者に即時更新を促しており、今回のアップグレードの不具合を報告した研究者として Umut Bayram 氏がクレジットされています（公式告知ベース）。件数・内訳・クレジットは公式告知に基づく報道で、正式な技術詳細は公式のリリースノートで確認してください。

なぜ危険なのか：RCEとパッチ直後の攻撃

RCE（リモートコード実行）は、攻撃者が遠隔からサーバー上で任意のコードを動かせる、という最も影響の大きい種類の脆弱性です。今回やや特殊なのは、いつでも成立するわけではなく、WordPress コアのアップグレード処理のあいだだけ開く「隙」を突く点です。

報道（Cyber Security News、公式告知ベース）が説明する仕組みはこうです。WordPress はコアを更新するとき、更新ファイルを一時的なステージング用ディレクトリ（wp-content/upgrade/ 配下）に展開します。このときフォルダ名が予測可能で、インストール用のファイルが公開状態にあると、本体とは別に動く WordPress のインストーラが、ごく短いあいだ外部から到達できる状態になります。攻撃者がそのインストーラに到達できれば、攻撃者が用意したデータベースに接続させることができ、そこからサーバー上でコードを実行する経路につながる、というものです。

ここで過大評価も過小評価も避けることが大切です。深刻な側面は、ログイン（認証）が不要なことです。盗んだパスワードや既存アカウントを必要とせず、外から狙えます。一方で、成立はレースコンディションに依存します。攻撃者は、サイトがまさにアップグレードを実行している数秒の瞬間に、その一時インストーラへ正確に到達しなければなりません。だから「不可能ではないが難しい」攻撃で、攻撃者は繰り返しリクエストを送って、更新ファイルが露出している瞬間に当たる機会を増やそうとします。なお、こちらで確認できた報道の範囲では、この RCE に CVE 番号は見当たりません。CVSS などの公式スコアも未確認なので、本記事では具体的なスコアは断定しません。

7.1.4 がこの隙をどう塞いだかも、報道（公式告知ベース）が具体的に挙げています。(1) 一時フォルダ名に 16文字のランダムを付けて予測を困難にする、(2) 保護用の index.php の扱いを元に戻す、(3) wp-config.php が作業ディレクトリからコピーされないようにする——の3点で、いずれも「露出していたステージング処理」そのものを直すもので、特定のサードパーティ製プラグインの問題ではありません。

報道が伝える 24時間で60,471件という数字も、読み方を間違えないことが大切です。これは Wordfence がブロックした攻撃の試行回数であって、侵害が確認されたサイトの数ではありません。報道自身が「これらは攻撃の試行であり、確認されたウェブサイトの侵害ではない」「個別のサイトが何件標的にされたかを示すものではない」と明記しています。つまりこの数字は被害規模ではなく、「パッチ公開直後に、未適用サイトを狙う探索が明確に活発化している」という温度感を示す指標です。パッチが出た瞬間から攻撃者も動く——だから「あとで」ではなく「いま」更新する、という話です。この「修正公開から悪用までが速い」傾向は WordPress に限りません。直近でも Microsoft のMSRC『今すぐパッチを』や、pgAdmin のコマンドインジェクション（CVE-2026-116241）で同じ速さが見られています。

もう一点、この数字の出どころについて補足します。60,471件を観測・ブロックしたのは Wordfence の WAF（ウェブアプリケーションファイアウォール）です。WAF による遮断は、攻撃パターンを入口で弾く「仮想パッチ」にあたり、更新までの時間稼ぎとしては有効です。ただし、これは本体の修正ではありません。WAF のルールをすり抜ける亜種が出れば防げませんし、WAF を入れていないサイトには最初から効きません。「Wordfence が6万件ブロックした＝守られている」ではなく、「攻撃が来ている証拠が出た＝本体を更新すべき」と読むのが正しい受け取り方です。WAF は更新を先送りする理由ではなく、更新までの保険だと位置づけてください。実際、報道によれば Wordfence のファイアウォールルールは、有料（Premium / Care / Response）には 10月28日（公開の約3時間後）に配布された一方、無料ユーザーへの配布は標準の30日遅延で 11月27日の予定です。つまり無料の WAF 頼みだと、約1か月は入口のルールすら無い状態になり得ます。ルールを待たずにパッチを当てるべき、というのはこの点でもはっきりしています。

自分のサイトを確認する

やることは単純です。まずいまの版が修正版以上かどうかを確かめます。管理画面なら「ダッシュボード → 更新」で現在のバージョンと利用可能な更新が見えます。サーバーにコマンドで入れる場合は、WP-CLI が速いです。

# いま動いているコアのバージョンを見る
wp core version

# 更新可能なコアがあるか確認する（最新版の番号も表示される）
wp core check-update

表示されたバージョンが、自分の枝の修正版（7.1 系なら 7.1.4、6.8 系なら 6.8.12 など、上の表の値）以上であれば、コアはすでに塞がっています。下回っていれば、未適用です。複数サイトを運用している場合は、本番だけでなく検証環境・ステージング・サブドメインの放置インストールも同じ手順で一つずつ確認してください。取りこぼしがちなのはいつもそこです。

WordPress RCE 対策：今すぐやること

確認して未適用だった、あるいは自動更新を切っていた場合の手順です。コアを最新の修正版へ上げ、ついでにプラグイン・テーマもそろえます。

# コアを自分の枝の最新（修正版）へ更新する
wp core update

# データベースの更新が必要なら実行する
wp core update-db

# プラグインとテーマも最新へ
wp plugin update --all
wp theme update --all

管理画面から行う場合は、「更新」画面で WordPress 本体の更新を適用し、続けてプラグイン・テーマを更新します。あわせて、この機会に次も見直しておくと堅くなります。

もう一つ、今回の仕組みに効く追加の防御があります。更新時の一時ディレクトリ wp-content/upgrade/ への公開アクセスをサーバー側で遮断しておくことです（例：Web サーバーの設定でそのパスを外部から見えなくする）。露出するのはこのステージング領域なので、ここに外から到達できなければ、攻撃の起点そのものを塞げます。ただし注意として、プラグイン型の WAF 単体ではこの露出したインストーラを守り切れない可能性があります。問題のインストーラは本体サイトとは別に読み込まれるため、WordPress 内で動くプラグインの防御が及ばないことがあるからです。だからこそ、入口制限は補助であって、コアのセキュリティ更新を当てることがこの脆弱性の本丸の対処になります。

影響範囲：どのサイトが対象か

報道によれば、RCE の影響は 4.7 から 7.1.3 までとされています。WordPress 4.7 は REST API を既定で載せた版（2016年）で、以後の長い範囲が対象ということになります。修正は各枝の最新版として配られ、4.7.39 までバックポートされています。一方、4.6 以前はすでにセキュリティ更新の対象外（EOL）で、今回の修正も出ません。該当する古いサイトは、パッチを待つのではなく、サポートされるメジャー版へ移行するしかありません。言い換えると、ここ数年のあいだ一度も大きく更新していないサイトは、まず対象だと思って確認するのが安全です。

一方で、冷静に見ておくべき点もあります。WordPress は既定でセキュリティ更新を自動適用するため、自動更新を切っていない大多数のサイトは、10月28日のリリース後すでに修正版へ上がっている可能性が高いです。したがって、本当にリスクが高いのは次のようなサイトに絞られます——自動更新を意図的に止めているサイト、更新がエラーで止まったまま放置されているサイト、サポートの切れた古いメジャー版（表に無いさらに古い枝）で動いているサイト、そして「作ったきり」で誰も見ていない検証用・キャンペーン用のインストールです。該当しそうなら、今日のうちに版を確認してください。

参照ソース

• WordPress 7.1.4 タグ（GitHub ミラー）（一次。リリース日 2026-10-28 と、全サポート枝への同日バックポートを確認）
• WordPress 公式ニュース — セキュリティ（一次。7.1.4 セキュリティリリースの正式な告知・技術詳細はここで確認）
• Cyber Security News — Over 60,000 Attacks Targeting WordPress RCE Vulnerability（報道。Wordfence の観測値 60,471件、RCE の性質、22件の修正内訳の出所）