タグアーカイブ バックドア

WPManageNinjaプラグイン更新で不正コード混入 全亜種を検出するSQLと駆除手順

WPManageNinja のプラグインを更新したら不正なコードが紛れ込んだ場合、最も確実な検出方法はデータベースのオプション値を直接検索することだ。apii.observer というドメイン名を探す SQL クエリを実行すれば、影響を受ける全13プラグインの亜種を一網打尽にできる。

なぜ通常のプラグイン更新でバックドアが入り込んだのか

2026年7月31日、WordPress 用プラグインを多数提供する WPManageNinja 社の旧アップデートサーバーが侵害された。同社は以前に販売プラットフォームを移行しており、本来は停止しているはずの旧サーバーが生き残り、かつプロキシが一部の更新トラフィックをそちらに転送し続けていた。この時間帯に管理画面で「更新」ボタンを押したユーザーは、正規の更新チャネルを通じて悪意あるパッケージを受け取ってしまったのだ。

パスワード突破でも脆弱性攻撃でもなく、ただの更新作業が侵入口になった。このサプライチェーン攻撃の怖さは、更新ボタンを押したこと自体はまったく正常な運用であり、疑いようがない点にある。

影響を受ける13のプラグインを確認する

WPManageNinja 社が公開したインシデント対応資料には13のプラグインプロファイルが含まれている。一方、当初の告知では一部しか公表されていなかった。注意すべきなのは以下の全リストだ。

• azonpress
• fluent-affiliate-pro
• fluent-boards-pro
• fluent-booking-pro
• fluent-community-pro
• fluent-player-pro
• fluent-support-pro
• fluentcampaign-pro（FluentCRM）
• fluentform-signature
• fluentformpro
• ninja-tables
• wp-payment-form-pro（Paymattic）
• wp-social-ninja-pro

これら13種類のいずれかを利用しているサイトは、更新履歴の有無にかかわらず直ちに調査が必要だ。WPManageNinja 社からドメインリストがメールで送られていたとしても、それを鵜呑みにしてはいけない。実際に、リストに載っていないサイトからも感染が確認されている。

侵入されたサイトに見られる具体的な症状と隠蔽の仕組み

バックドアは、正規プラグインのフォルダ内に PHP ファイルを1つ追加し、既存のファイルの末尾に小さなローダーコードを追記する形で設置される。Fluent Forms Pro の例では、以下のようになっていた。

このデモは Fluent Forms Pro におけるバックドアの有無を視覚化したものだ。

データベースには _wp_update_meta_cache や _site_transient_update_meta といったオプション名が書き込まれる。これらの名称は WordPress コアが使う一時データ（Transient）に酷似しており、ひと目見ただけでは異常と気づきにくい。オプションの値には攻撃者のコマンド＆コントロールサーバーである apii.observer が含まれ、さらにサイト固有のトークンとログインキーが保存されていた。このログインキーはパスワードなしで WordPress 管理画面にログインできる「万能鍵」であり、ファイルを削除するだけでは不正アクセスのリスクは消えない。

全亜種を一発で検出するデータベースクエリ（WP-CLI）

63個のオプション名や26個の cron フックを個別に調べる必要はない。すべての亜種に共通する特徴は、C2 サーバーアドレス apii.observer をオプションの値として持っていることだ。したがって、次の1行のクエリで全13プラグインの感染を一括検出できる。

PREFIX=$(wp db prefix)
wp db query "SELECT option_name FROM ${PREFIX}options \
WHERE option_value LIKE '%apii.observer%'" --skip-column-names

cron ジョブまで同時に調べたい場合は以下のように拡張する。

wp db query "SELECT option_name FROM ${PREFIX}options \
WHERE option_value LIKE '%apii.observer%' \
OR option_value LIKE '%wp_update_check_schedule%'" --skip-column-names

wp cron event list --fields=hook,next_run_relative \
| grep -E "wp_update_check_schedule|wp_license_verify_schedule"

このアプローチの本質は「マルウェアが自らのサーバーと通信しなければならない」という不変の事実を突く点にある。シグネチャリストは古くなるが、通信先のドメインはそう簡単には変わらない。覚えておいて損はない手法だ。

sFTP しか使えない場合のファイルチェック方法

レンタルサーバーによっては SSH が提供されず、WP-CLI も使えないことがある。その場合は sFTP 経由でファイルを確認する。Python の paramiko ライブラリを使った検出スクリプトが有効だが、重要なのは「確実に読めたと言える状態だけをクリーンと判定する」ことだ。

この判定フローは、読み取り失敗を「感染していない」と誤認させないための安全策だ。

より確実な方法として、販売元のアカウントからクリーンなプラグイン ZIP をダウンロードし、サーバー上のファイル群とファイルサイズを比較する手段もある。手元のクリーンコピーに存在しないファイルや、サイズが異なるファイルがあれば、それが不正コードの証拠になる。

安全かつ完全な駆除手順（ファイルとデータベースの順序が重要）

駆除で最も失敗しやすいのが「データベースから先に削除する」手順だ。残ったファイルの cron が再度データベースに不正な行を書き込んでしまう。必ず以下の順序で実施する。

1. 感染したプラグインフォルダを削除し、クリーンな ZIP から再インストールする

wp plugin delete fluentformpro
wp plugin install /path/to/fluentformpro-clean.zip --activate
wp plugin get fluentformpro --field=version

バージョン番号を必ず確認し、6.2.8 や 6.2.9 といったアップデータ経由の古い番号が表示されたら、ZIP からの再インストールが正しく行われていない可能性がある。

2. データベースから不正なオプションと cron を削除する

PREFIX=$(wp db prefix)
# まず内容を確認
wp db query "SELECT option_name FROM ${PREFIX}options \
WHERE option_value LIKE '%apii.observer%'"
# 削除実行
wp db query "DELETE FROM ${PREFIX}options \
WHERE option_value LIKE '%apii.observer%'"
# cron イベントも削除
wp cron event delete wp_update_check_schedule
wp cron event delete wp_license_verify_schedule

3. ソルトを変更し、すべてのセッションを無効化する

wp config shuffle-salts で wp-config.php に定義されたソルト（8つのキー）を新しい値に置き換える。これにより、攻撃者が入手したログインキーを含むすべての既存セッションが強制ログアウトされる。

wp config shuffle-salts

その後、管理者パスワードを手動で変更する。ソルトの更新はパスワードそのものを上書きしないからだ。

4. 駆除後は状態を読み取って必ず検証する

削除コマンドの成功メッセージを信用してはいけない。cron 削除が正常に受け付けられても、実際には実行されずにスケジュールが残っているケースがある。再度クエリを実行し、返却行数がゼロであることを目視確認する。

wp db query "SELECT option_name FROM ${PREFIX}options \
WHERE option_value LIKE '%apii.observer%'" --skip-column-names
# 出力が完全に空であることを確認
wp cron event list --fields=hook,next_run_relative \
| grep -E "wp_update_check_schedule|wp_license_verify_schedule"
# 同じく出力が空であることを確認

最後に wp option get blogname やサイトのトップページ表示で WordPress が正常に起動していることを確かめる。

WP-CLI が使えない環境でのソルト変更と安全策

レンタルサーバーの制限や独自コネクターの仕様で wp config shuffle-salts が使えない場合は、FTP 経由で wp-config.php を直接編集する。このとき、次の点を徹底する。

• 現在の wp-config.php を必ずローカルにバックアップする。
• WordPress.org のソルト生成 API から新しい値を取得し、8つの define 文すべてを置換する。
• 8つすべてを見つけられなかった場合は作業を中断する。部分的な置換はサイトを破壊する。
• 置換後のファイルサイズが数百バイト以上変化していないか確認する。
• アップロード後にサーバーからファイルを読み戻し、意図した内容かをバイト単位で比較する。
• データベースパスワードを含むため、ファイル内容をログやターミナルに絶対に出力しない。

複数サイトをスクリプトで一括処理する場合は、1サイトごとに別プロセスで実行し、数秒の待機を挟む。連続したリクエストはサーバーのアンチボット機能にブロックされる原因になる。HTTP 202 や 429 が返ったら即座に全処理を停止する。

よくある質問

プラグインを更新していないのに感染する可能性はあるか

今回の経路は更新操作に限られる。ただし、過去に更新したタイミングが問題の時間帯と重なっていれば、更新していないつもりでも感染している場合がある。cron による自動更新が有効なら、手動更新していなくても該当する。

wp-config.php のソルトを変更するとどうなるか

そのサイトにログインしているすべてのユーザーが強制的にログアウトされる。パスワードは変わらないため、同じパスワードで再ログインは可能だ。「Remember Me」で保存されたセッションも無効になる。

感染したかどうか管理画面から判断できるか

見た目にはまったく変化がない。管理画面の表示や動作に異常が出ないよう設計されているため、プラグイン一覧や更新画面から気づくことはほぼ不可能だ。

データベースのバックアップから復元しても大丈夫か

バックアップの中に不正オプションが含まれていれば、復元で再感染する。リストア前に必ずバックアップの SQL を確認し、apii.observer を含む行がないか検索しておく必要がある。

WAF やセキュリティプラグインで防げたか

この攻撃は正規の更新チャネルを経由しているため、一般的な WAF やマルウェアスキャナーでは検知できない。実際に複数のセキュリティプラグインが稼働している状態でも、バックドアファイルを無害と判断した事例が報告されている。今回の経験から、セキュリティプラグインの「異常なし」を鵜呑みにしないことが重要だ。

この記事のポイント

• WPManageNinja の当該13プラグインを利用しているサイトは、更新の有無にかかわらず即座に調査する。
• 全亜種の検出は apii.observer を含むオプション値を SQL で LIKE 検索するのが最速かつ確実。
• 駆除は「プラグインフォルダの再インストール」→「データベース削除」→「ソルト変更とパスワード変更」の順序厳守。
• 削除後は成功メッセージを信じず、再度クエリを実行してゼロ件を目視確認する。
• ソルト変更だけではパスワードは変わらない。管理者パスワードも忘れずに変更する。

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている