WordPressのSEOプラグインRank Mathの有料版「Rank Math SEO PRO」で、2026年10月15〜16日に配布された3.0.123の一部にマルウェアが混入していました。脆弱性識別番号はCVE-2026-111862、CVSS 3.1の基本値は9.8です。この記事では、影響を受ける取得期間と日本時間での読み替え、無料版の扱い、WP-CLIとシェルで痕跡を調べるコマンド、3.0.124へ入れ替える前に済ませる除去の順序を整理します。内容は2026年10月24日時点の公開情報にもとづきます。
まとめ:3.0.124への更新だけでは消えない痕跡と事案前のバックアップ復元
対象は、日本時間10月16日5時2分〜16時12分にダウンロードまたは更新で取得したPRO版3.0.123です。無料版のRank Math SEOは対象外とされています。取得した版を有効化したサイトは、侵害されたものとして扱います。
3.0.124に上げても、作られた管理者アカウント、偽のコアファイル、cronは残ります。最優先は、事案前のバックアップからの復元と、すべての認証情報の入れ替えです。戻せない場合はrank-math-proフォルダとwp_optionsの3キーを先に消してから、残りの痕跡を調べます。複数サイトの点検や復旧を社内で回しきれないときは、WordPress保守・メンテナンスで点検と復旧を受け付けています。
Rank Math SEO PRO 3.0.123の一部へのマルウェア混入と対象の取得期間
Rank Mathの公式インシデント告知によると、配布されたPRO版の一部ファイルが改ざんされていました。開発元は該当ファイルを削除し、クリーンな3.0.124を公開しています。
10月15日20時2分〜16日7時12分(UTC)に取得したPRO版が対象
対象は2026年10月15日20時2分から16日7時12分(UTC)の約11時間に、ダウンロードまたは更新で取得したパッケージです。日本時間では10月16日(金)の5時2分〜16時12分にあたり、早朝の自動更新と日中の手動更新のどちらも含みます。
NVDのCVE-2026-111862は10月19日に公開され、採点はWordfenceによる9.8(Critical)です。GitHubのアドバイザリは種別をCWE-506(悪意のあるコードの埋め込み)としています。プログラムの欠陥ではなく、配布物そのものに不正なコードが入っていた事案です。侵入経路と影響を受けた利用者の数は、10月24日時点で公表されていません。
版番号3.0.123だけでは判定できない理由と10月7日公開版との違い
Rank Mathの更新履歴では、3.0.123の公開日は10月7日です。内容はCSVインポートとAI Link Geniusのエクスポートの不具合修正で、セキュリティの記載はありません。続く3.0.124(10月16日)は「セキュリティインシデントの影響を受けた3.0.123のパッケージを掃除した版」と書かれています。
つまり、10月7日〜15日に入れた3.0.123は正常で、同じ版番号のまま15日夜からの配布物だけが差し替わっていました。NVDの説明も「3.0.123であることだけでは侵害の根拠にならない」としています。管理画面で版を見るだけでは足りず、いつ取得したかと、次の章の痕跡で判断します。
無料版Rank Math SEOが対象外となる範囲と無料アカウント削除の影響
WordPress.orgで配られる無料版は有効インストール400万以上、10月24日時点の最新は1.0.280系です。公式告知は無料版を影響なしとしています。
ただし無料版の利用者にも別の影響があります。10月13〜16日に登録された無料アカウントの一部が、システム更新で削除されました。SEO設定やメタデータは消えませんが、Google Search Console連携、Keyword Rank Tracker、Content AIなどはアカウントを作り直すまで使えません。同じメールアドレスで登録し直し、「Rank Math SEO」の「ダッシュボード」から「ヘルプ」を開いて、接続を切ってからつなぎ直します。
rank1cdn.comと通信するバックドアの挙動と公式が挙げる侵害の痕跡
NVDの説明とRank Mathの告知から、マルウェアの動きと痕跡を整理します。ハッシュ値や全体の解析結果は公表されていないため、ここに挙げた痕跡が見つからなくても安全とは言い切れません。
ページ訪問のたびにバックドアを作り直す仕組みと漏れる秘密情報
改ざんされたプラグインを有効化すると、マルウェアはrank1cdn.comと通信し、永続的なアクセス手段をサーバーに残します。厄介なのは、サイトにアクセスがあるたびに隠しバックドアを作り直す点です。痕跡を1つずつ消しても、再生成の仕組みが動いている間はすぐ元に戻ります。
露出しうる情報として、WordPressの認証情報、データベースの認証情報、APIキーなど、Webサーバーから読めるすべての秘密情報が挙がっています。公式告知はバックドアの特徴として、base64_decodeとXORの組み合わせ(キーはxmmqhn)、proc_open、PHP-FPMのソケットを扱うコードを示しています。PHPから外部コマンドを動かせる状態だったということです。
wp_optionsの3キー・wpsupport_管理者・偽コアファイルなど痕跡の一覧
公式告知が挙げる痕跡を、確認する場所ごとに並べました。上から順に、WP-CLIだけで確かめられるものです。
| 確認する場所 | 痕跡 |
|---|---|
| wp_optionsテーブル | _uf6qdn2hmm |
| wp_optionsテーブル | t8krdk990phb |
| wp_optionsテーブル | _np5pvf754c |
| ユーザー一覧 | 名前がwpsupport_で始まる管理者 |
| ユーザー一覧 | メールアドレスが@wp-mail.netの管理者 |
| wp-includes | 偽のclass-wp-cache-util.php |
| .htaccess | .cacheをPHPとして動かす設定 |
| サーバー内 | PHPコードを含む.cacheファイル |
| システムのcrontab | #ms6v46の印が付いた行 |
class-wp-cache-util.phpはWordPressの正規のファイル名ではありません。名前がコアに似せてあるので、一覧の目視では見落とします。公式告知はこのほか、uploadsフォルダ内のPHPファイル、SSHのauthorized_keys、ほかのユーザーのcrontab、見覚えのないプロセスまで調べるよう求めています。WordPressの外まで手が入っている前提です。
WP-CLIとシェルで有効化の有無と侵害の痕跡を確かめるコマンド手順
確認はSSHでWordPressの設置ディレクトリに入って行います。偽のコアファイルやcronは管理画面に出てこないため、サーバー側で見る必要があります。
有効化・インストールのみ・ダウンロードのみで分かれる対応の区分
対応の重さは、期間内に取得したファイルをどこまで使ったかで変わります。公式告知の区分は次のとおりです。
- 期間内に取得して有効化した:侵害されたものとして扱い、復元か手動除去を行う
- インストールしたが有効化していない:該当ファイルを削除して3.0.124を入れ、念のためスキャンする
- ダウンロードしただけで入れていない:この件だけでは侵害の兆候は無い
判断に迷うのは、自動更新で入ったかどうかが分からない場合です。期間内に更新が走った可能性が少しでもあれば、有効化したものとして扱います。次の確認で痕跡が1つも出なくても、軽い区分へは下げません。
wp_optionsの3キーと不審な管理者をWP-CLIで洗い出すコマンド
まず版を確かめ、続けて3つのオプションと管理者アカウントを調べます。テーブル接頭辞がwp_以外のサイトでも、WP-CLIのコマンドはそのまま使えます。
# PRO版の版と有効・無効(3.0.123なら次の確認へ進む)
wp plugin list --name=rank-math-pro --fields=name,status,version
# 不正なオプション3件(値が出力されたら侵害の痕跡)
for k in _uf6qdn2hmm t8krdk990phb _np5pvf754c; do
echo "== $k"; wp option get "$k" 2>/dev/null
done
# 管理者の一覧から wpsupport_ と @wp-mail.net を探す
wp user list --role=administrator \
--fields=ID,user_login,user_email,user_registered --format=csv \
| grep -E 'wpsupport_|@wp-mail\.net'
wp user listはuser_registeredを出せるので、10月16日以降に作られた管理者もあわせて見ておきます。名前の規則に合わなくても、作成日が事案の後なら調べる対象です。wp cron event listでWordPress側の予約処理も確認しますが、#ms6v46の印はOSのcrontabに付くため、次のシェル操作で別に見ます。
偽コアファイル・.cacheのPHP実行・#ms6v46のcronを探すシェル操作
WordPressの外の痕跡はシェルで探します。Webサーバーの実行ユーザーはwww-dataとしているので、環境に合わせて読み替えてください。
# 偽のコアファイル(存在すれば侵害)
ls -l wp-includes/class-wp-cache-util.php
# コアファイルをWordPress.orgの値と照合
wp core verify-checksums
# PHPコードを含む .cache ファイル
find . -name "*.cache" -type f -exec grep -l "<?php" {} +
# .cache をPHPとして動かす .htaccess の設定
grep -rn --include=.htaccess "\.cache" .
# uploads 内のPHPファイル
find wp-content/uploads -name "*.php" -type f
# Webサーバー実行ユーザーのcrontab
sudo crontab -l -u www-data | grep -n "ms6v46"
wp core verify-checksumsは、配布元に無いファイルをwp-includesで見つけると警告を出します。一方、wp plugin verify-checksumsはWordPress.orgの配布物と照合する仕組みです。PRO版のような有償プラグインは照合できない場合があると、公式告知も注記しています。PRO版の中身の改ざんは照合で確かめられないので、フォルダごと入れ直す前提で考えます。
侵害を前提にした復旧:バックアップ復元と手動除去の順序と認証情報の交換
公式告知は、復元を推奨し、戻せない場合の手動除去も示しています。手動除去では順番を守るよう強く求めています。
日本時間10月16日5時2分より前のバックアップから戻す場合の手順
使えるのは、UTCで10月15日20時2分、日本時間で10月16日5時2分より前に取ったバックアップです。ファイルとデータベースの両方を戻し、WordfenceやSucuriなどでスキャンしてから、PRO版を3.0.124で入れ直します。
注意したいのは、3.0.123を10月7日〜15日に正常版で入れていた場合でも、16日の日中に自動更新で差し替わった可能性がある点です。戻す世代は版番号ではなく、取得日時で選びます。共用サーバーの自動バックアップは保持日数が決まっているため、事案前の世代が消える前に手元へ保存してください。
戻せないサイトでrank-math-proフォルダ削除から始める手動除去
手動除去では、再生成の仕組みを先に止めます。止める前に痕跡を消しても、次のアクセスで作り直されるからです。
- rank-math-proフォルダを丸ごと削除する(無効化だけでは足りない)
- wp option deleteでwp_optionsの3キーを消す
- サーバーのファイアウォールやDNSでrank1cdn.com宛ての通信を止める
- 偽コアファイル、.cacheファイル、.htaccessの設定、uploads内のPHP、cronの行、不審な管理者を除く
- ほかのプラグインとテーマ、authorized_keys、実行中のプロセスを調べる
4へ進むのは、1〜3の作業がすべて終わってからです。調査が必要になる場合に備えて、消すファイルは削除せずWebルートの外へ移しておくと後で比べられます。最後にrankmath.comへ直接ログインして3.0.124を取得し、入れ直します。Rank Mathはログインやダウンロードのリンクをメールで送らないとしているので、そうしたメールは開かずに捨ててください。
wp-config.phpのソルト・DB・APIキーまで入れ替える認証情報の範囲
認証情報の入れ替えは、復元した場合も手動で除去した場合も必須です。マルウェアがWebサーバーから読めるものをすべて読めた以上、wp-config.phpにあるものは漏れた前提で扱います。
# wp-config.php の認証キーとソルトを再生成(全ユーザーがログアウトされる)
wp config shuffle-salts
# 全ユーザーのログインセッションを破棄
wp user session destroy --all
wp config shuffle-saltsとwp user session destroyで、盗まれたCookieを無効にします。そのうえで、全管理者のパスワード、データベースのパスワード、外部サービスのAPIキー、SMTPの認証情報、ホスティング・FTP・SSHのパスワードを変えます。DBのパスワードを変えたら、wp-config.phpのDB_PASSWORDも同じ値に直さないとサイトが止まる点に気をつけてください。
判断:有償プラグインの更新運用をどう組むかと保守を外部へ任せる条件
今回の件は、正規の配布元から正規の版番号で届いたファイルが汚れていた事案です。更新を急ぐほど被害を受けやすかったという点で、ふだんの「すぐ更新する」運用と逆の結果になりました。同じ月に起きたUpdraftPlus 脆弱性:接続キー流出の確認とバックドア除去・1.26.13更新も、開発元の侵害が利用者のサイトに広がった例です。
有償プラグインの自動更新を止めて検証環境を挟むべきサイトの条件
結論から言うと、会員情報や決済を扱う本番サイトでは、有償プラグインの自動更新を止め、検証環境で1〜2日置いてから本番へ入れるべきです。有償プラグインはWordPress.orgの配布物と照合できず、wp plugin verify-checksumsが効きません。公開直後の配布物を最初に受け取るのは、自動更新を有効にしたサイトです。
ただし、この判断の対象は、有償プラグインの機能追加と通常の修正だけです。開発元が悪用を確認した脆弱性の修正版は、待たずに当てます。待つ日数を決めておけば、今回のように配布元側で異常が見つかった場合に、本番へ入る前に告知が出ます。社内の告知や脆弱性情報を毎日確かめる人がいないなら、自動更新を止めること自体がかえって危険なので、この運用は採りません。
多数のサイトを少人数で管理する組織が保守を外部へ任せる判断基準
10サイト以上を1〜2人で見ていて、更新の検証環境を用意できない体制なら、自前での運用は見直すべきです。今回の対応は、取得日時の特定、サーバー側の痕跡調査、全認証情報の入れ替えまであり、1サイトでも半日はかかります。
選択肢は、検証環境と監視を自社で整えるか、更新と点検を含めて保守を外部へ任せるかです。内製と外注の分け方はWordPress保守運用とは:作業範囲・費用相場と内製か外注かの判断基準に、攻撃面ごとの常設の設定はWordPressセキュリティ対策:攻撃面ごとの設定とWP-CLIでの確認手順に、戻せる世代を残す設計はWordPressのバックアップ設計:WP-CLIでの取得・世代管理・復元テストの手順にまとめました。
Rank Math PRO 3.0.123の混入事案でよくある質問と回答
CVE-2026-111862への対応で出てきやすい疑問に、10月24日時点の一次情報の範囲で答えます。
無料版のRank Math SEOだけを使っていれば対応は不要ですか?
公式告知では、WordPress.orgで配られる無料版は影響を受けていません。プラグイン一覧にRank Math SEO PRO(フォルダ名rank-math-pro)が無ければ、マルウェアの件は対象外です。ただし10月13〜16日にrankmath.comの無料アカウントを作った場合は、アカウントが消えて連携機能が止まっていることがあります。管理画面のヘルプから接続状態を確かめてください。
3.0.124に自動更新されていれば安全ですか?
3.0.124は汚れたファイルを置き換えるだけで、すでに作られた管理者アカウント、偽のコアファイル、cron、wp_optionsのキーは残ります。期間内に3.0.123を取得して有効化していたなら、更新が済んでいても侵害されたものとして扱い、痕跡の確認と認証情報の入れ替えを行います。期間外に入れた3.0.123から3.0.124へ上がった場合は、この件の対象ではありません。
Patchstackなどの仮想パッチで防げますか?
防げません。Patchstackのデータベースも、開発基盤へのサプライチェーン攻撃なので仮想パッチでは緩和できないと注記しています。リクエストを止めるルールでは、サーバー内で動き出したバックドアを止められません。対応は3.0.124への入れ替えと、痕跡の除去です。
痕跡が1つも見つからなければ侵害されていないと言えますか?
言い切れません。公表された痕跡は開発元が把握したものに限られ、ハッシュ値や全体の解析は出ていません。期間内に取得して有効化した事実があれば、痕跡が無くても事案前のバックアップから戻すか、手動除去と全認証情報の入れ替えまで行います。取得日時が期間外と確かめられた場合だけ、対象外と判断できます。
Rank MathからAll in One SEOなど別のSEOプラグインへ乗り換えるべきですか?
この件だけで乗り換える必要はありません。原因はプラグインの機能ではなく、配布物の改ざんです。同じことは他の有償プラグインでも起こりえます。乗り換えより先に、有償プラグインの自動更新の扱いと、事案前に戻せるバックアップの世代を見直すほうが、次の同種事案への備えになります。
関連記事
- SEOポイズニングとは?仕組み・手口と2026年の攻撃事例・企業が取るべき対策:乗っ取られたWordPressが悪用される代表的な使われ方です。
- サプライチェーン攻撃とは?起点別3類型と最新事例・対策の優先順位:開発元や配布経路の侵害から利用者へ広がる攻撃の全体像です。
- ソフトウェアサプライチェーンセキュリティとは?開発工程に組み込む防御と2026年規制対応の実装判断:取り込む部品の真正性を確かめる仕組みを扱います。
- Webシェルとは?Tomcatへの設置手口と検知・除去の手順をコマンド例で解説:設置されたバックドアを見つけて消す考え方をまとめています。