WordPressのmu-pluginsに不審なファイルがある時の確認と安全な削除手順

WordPressのサーバーを確認していて、wp-content/mu-pluginsの中に見覚えのないPHPファイルを見つけ、不安になっていませんか？通常のプラグイン一覧には表示されず、無効化ボタンもないため、「隠されたマルウェアではないか」と焦るのは自然なことです。

ただし、mu-pluginsにあるという理由だけで削除するのは危険です。サーバー会社、保守会社、キャッシュ、セキュリティ、会員機能などが正規に使っている場合があり、消すとログインや決済、表示速度、管理機能に影響することがあります。

反対に、攻撃者が通常の管理画面から見えにくく、自動で読み込まれる性質を悪用する場合もあります。大切なのは、ファイル名の印象で決めず、現状保存、由来確認、正規版との比較、隔離、動作確認、再発監視の順で判断することです。

結論から言えば、mu-pluginsの不審なファイルは、いきなり削除せず「誰が、いつ、何のために置いたか」を確認し、戻せる状態で一つずつ隔離するのが正解です。管理画面に出ないことと、悪意があることは同じではありません。

まず仕組みを理解し、その後に実際の確認順へ進みましょう。

WordPressのmu-pluginsに不審なファイルがある時の結論

WordPressのmu-pluginsで見覚えのないファイルを発見した時は、削除より先に証拠保全と由来確認を行ってください。正規機能を壊す事故と、マルウェアの痕跡を消してしまう事故の両方を防げます。

mu-pluginsは自動で読み込まれる特別な領域

mu-pluginsは「Must-Use Plugins」の略で、WordPressが通常のプラグインより早い段階で自動的に読み込む仕組みです。一般的にはwp-content/mu-pluginsに置かれ、管理者が通常のプラグイン画面から停止する前提ではありません。

この性質は、全サイトで必ず動かしたい共通機能、ホスティング環境の制御、保守用の監視、キャッシュ連携などに向いています。運用担当者が導入を知らなくても、制作会社やサーバー会社が正規に配置している可能性があります。

管理画面に出ないだけでは感染の証拠にならない

通常のプラグイン一覧で見つからない、無効化リンクがない、英数字だけのファイル名になっている、といった特徴だけでは悪意を断定できません。自動生成された正規ファイルや、別ファイルを読み込むためだけの小さなローダーもあります。

一方、通常の画面から止めにくいことは攻撃者にとって都合がよく、バックドア、強制リダイレクト、不審ユーザーの再作成、外部通信などの入口に悪用されることがあります。そのため「安全と決めつけない」「危険と決めつけない」の両方が重要です。

最初の判断は削除ではなく三つの分類で行う

最初は、正規と確認できたファイル、不審だが未確定のファイル、悪意を示す根拠があるファイルの三つに分けます。未確定のものをすぐ消さず、調査対象として隔離候補に残すことで、業務影響を抑えながら判断できます。

サイト全体にも異常がある場合は、mu-pluginsだけを見るのではなく、WordPressが乗っ取られた時の初動対応も合わせて確認してください。被害拡大を止める作業と、ファイル調査を分けて進めやすくなります。

WordPressのmu-pluginsを変更する前に残す証拠

WordPressのmu-pluginsを触る前に、ファイル本体だけでなく、周辺情報をセットで保存してください。後から「いつ入ったか」「削除後に戻ったか」「正規機能だったか」を比較する基準になります。

ファイル本体と属性を同じ時点で保存する

FTPやサーバーのファイルマネージャーで、対象ファイルをローカルへダウンロードします。ファイル名、フルパス、更新日時、所有者、パーミッション、サイズも画面保存またはメモで残してください。

可能ならSHA-256などのハッシュ値も記録します。ハッシュはファイル内容から作る指紋のような値で、同じ名前のファイルが後日復活した時に、内容まで同じかを比較できます。更新日時だけはコピーや復元で変わるため、単独の根拠にしません。

バックアップは感染を含む前提で分離して保管する

調査用バックアップは、正常な復元用バックアップと混ぜないでください。不審ファイルを含む可能性があるため、日付と「調査用・未確認」を明記し、公開領域の外へ保存します。ブラウザーから直接開ける場所へ置くのは避けます。

データベース、uploads、テーマ、通常プラグイン、設定ファイルも同じ時点で保存すると、mu-pluginが別の場所から命令を受けていた場合に追跡しやすくなります。ファイル一つだけを保存しても、登録元や再作成元まで分からないことがあります。

関係者と契約情報から由来を確認する

制作会社、保守会社、サーバー会社、CDN、セキュリティサービスへ、ファイル名と設置目的を確認します。「入れましたか」だけでなく、導入日、提供元、必要な関連ファイル、削除した場合の影響、正規版を再取得できる場所まで聞いてください。

回答が曖昧でも、すぐ悪意と決めつける必要はありません。請求書、作業報告、Gitの履歴、デプロイログ、ホスティングの仕様書を照合します。正規の由来が説明でき、配布元の内容と一致すれば、見覚えがないだけの正常ファイルである可能性が高まります。

WordPress全体の改変時刻を広く確認したい場合は、WordPress改ざんの確認ポイントも役立ちます。単一ファイルではなく、同じ時間帯の変更を束として見てください。

WordPressのmu-pluginsで不審なファイルを見分ける確認軸

WordPressのmu-pluginsが不正かどうかは、一つの特徴ではなく、由来、配置、コード、通信、ログ、サイト症状の一致で判断します。複数の根拠が同じ方向を指すほど、危険度は高くなります。

正規の配布元・構成・読み込み先と比較する

まず、正規の提供元が分かるなら、新しい正規版を別の安全な場所へ取得して比較します。ファイル名だけでなく、ディレクトリ構成、コメント、関数名、読み込むファイル、外部通信先、想定バージョンを見ます。

mu-plugins直下のPHPだけが、別ディレクトリにある本体を読み込む構造は珍しくありません。そのため、ローダーだけを見て安全と判断せず、参照先がサイト内のどこにあり、誰が管理しているかまで追います。参照先が存在しない、uploads内のPHPを読む、毎回異なる名前のファイルを読む場合は注意が必要です。

コードは危険な関数名より目的と入力元を見る

難読化された長い文字列、外部から受け取った値の実行、認証を回避する処理、管理者追加、別ファイルの生成、不審な転送先などは警戒材料です。ただし、圧縮や互換性のために読みにくい正規コードもあるので、断片だけで結論を出しません。

見るべきなのは「どこから入力を受け、何を行い、結果をどこへ送るか」です。公開リクエストの値を検証せず使う、未知の外部ドメインと通信する、PHPファイルを書き込む、ユーザーや権限を書き換える処理が連結していれば、優先度を上げて調査します。

アクセスログとエラーログで実行の前後を結ぶ

ファイルの更新時刻だけでなく、その前後のアクセスログ、PHPエラーログ、管理画面ログイン、FTP・SSH・サーバーパネルの操作履歴を確認します。同じIPや同じ時刻帯で、不審なPOST、未知の管理者ログイン、別ファイル更新が続いていないかを見ます。

ログがない場合は「不正ではない」とは言えません。保存期間切れや記録設定の不足もあるからです。確認できた事実、確認できなかった項目、推測を分けてメモし、断定の根拠を明確にします。

感染ファイルを探す基本的な見方は、WordPressの感染ファイルを見つける手順で補足しています。mu-plugins以外のコア、テーマ、uploadsも比較対象にしてください。

WordPressのmu-pluginsから不審なファイルを安全に隔離する手順

WordPressのmu-pluginsを止める時は、削除ではなく、戻せる隔離から始めてください。影響範囲が読みにくい自動読み込み領域だからこそ、一変更ごとに確認する方法が安全です。

作業前に利用者への影響と復元経路を確保する

EC、予約、会員、問い合わせなど停止できない機能がある場合は、低アクセス時間や検証環境を使います。管理画面に入れなくなった時に戻せるよう、WordPress外から操作できるFTP、SSH、サーバーのファイルマネージャーを確認してください。

作業担当者、開始時刻、確認対象、戻す条件を決めます。複数人が同時に更新すると、どの変更で症状が変わったか分からなくなります。自動デプロイや保守ツールがファイルを戻す環境では、一時停止の可否も先に確認します。

保全コピーを残して一ファイルずつ読み込み対象から外す

対象を調査用の非公開ディレクトリへコピーし、元の場所では一ファイルだけを読み込み対象から外します。単に拡張子を変える方法は環境によって扱いが異なるため、公開領域外の隔離場所へ移動し、元パスと新パスを記録する方が確実です。

ローダーと本体が分かれている場合は、依存関係を確認してから対象を選びます。ローダーだけを外して本体を残すことは調査上有効ですが、本体が別経路から呼ばれていないかも確認します。一度にディレクトリ全体を消すと、正規機能と不正機能のどちらが影響したか判別できません。

隔離後は正常表示だけでなく業務機能まで試す

トップページが表示されたから成功とは限りません。ログイン、投稿編集、画像アップロード、フォーム送信、メール、予約、決済、キャッシュ、バックアップ、外部API連携など、mu-pluginが関係しそうな機能を確認します。

同時に、リダイレクト、広告、見知らぬ管理者、エラー、サーバー負荷など不審症状が止まったかも見ます。正規機能が壊れ、不審症状が変わらない場合、そのファイルは原因ではない可能性があります。元へ戻し、次の候補を一つだけ調べます。

隔離直後に問題がなくても、キャッシュや予約処理の影響が遅れて出ることがあります。少なくとも次の定期処理が動く時間帯まで確認してください。

WordPressのmu-pluginsを削除しても戻る時の調査範囲

WordPressのmu-pluginsが隔離後に再作成された場合、戻ったファイルだけを何度も消してはいけません。別のプログラム、アカウント、予約処理、デプロイ機能が再生成しているため、作成元を特定する段階へ進みます。

再作成の時刻とハッシュから作成元を絞る

再作成を確認した時刻、ファイルのハッシュ、所有者、権限を初回記録と比較します。内容が同じなら自動復元や同じバックドアの実行、内容が変わるなら外部からの取得や毎回生成する処理が疑われます。

作成時刻の直前に、どのURLへアクセスがあり、どのPHPプロセスが動き、どのアカウントがログインしたかをログで照合します。作成者がWebサーバーのユーザーならWeb経由、デプロイ用ユーザーなら運用ツール、別ユーザーならFTP・SSH・サーバーパネル側の調査が必要です。

WordPress内の別の永続化経路を確認する

通常プラグイン、テーマのfunctions.php、drop-ins、WP-Cron、データベースのoptions、見知らぬ管理者、uploads内のPHP、コア改変を確認します。mu-pluginが入口ではなく、別の感染箇所から作られた結果にすぎない場合があります。

セキュリティスキャンを使う場合、検出結果をそのまま一括削除せず、正規版との差分とサイト固有コードを確認します。Wordfenceの基本操作はWordfenceの使い方で解説しています。なお、クイックレスキュー365にはマルウェアスキャン機能はないため、スキャン用途には使いません。

WordPress外の自動復元と侵入経路も確認する

サーバー側Cron、GitやCI/CD、自動バックアップ復元、ホスティング独自機能、監視エージェント、管理ツールが正規に戻していることもあります。これらはWordPress管理画面から見えないため、サーバー会社や開発担当者へ確認が必要です。

不正アクセスが疑われる場合は、WordPressだけでなく、FTP、SSH、サーバーパネル、データベース、メール、DNS、CDN、Gitの認証情報とログを見ます。パスワード変更は、感染した端末や侵害されたメールから行うと再取得される可能性があるため、安全な端末と連絡先を使います。

既知の脆弱性が侵入口になっていないかは、WordPressの脆弱性とセキュリティ対策も確認してください。ファイルを消す作業と、侵入口を閉じる作業は別物です。

WordPressのmu-plugins復旧後に行う再発防止と監視

WordPressのmu-pluginsを安全な状態へ戻した後は、機能確認、認証情報の更新、侵入口対策、変更監視をセットで行ってください。数日正常だっただけでは、再発防止が完了したとは言えません。

正規状態を基準として記録し直す

調査と復旧が終わったら、正規と確認したmu-pluginsの一覧、目的、提供元、バージョン、ハッシュ、更新手順を台帳に残します。次回、担当者が変わっても「見覚えがない」という理由だけで削除する事故を防げます。

正規ファイルの更新方法も重要です。手動編集したファイルが自動更新で上書きされる、反対に古い保守ツールが脆弱な版を戻す、といった運用事故があります。誰が、どの手順で、どの環境から更新するかを決めてください。

認証情報は影響範囲を決めて安全な順番で更新する

管理者、FTP、SSH、サーバーパネル、データベース、Git、APIキー、メールの認証情報を見直します。全員で同じパスワードを使わず、不要なアカウントを停止し、多要素認証を有効にします。

変更順は、連絡用メールとサーバーパネルなど上位の入口から始め、WordPress管理者やアプリ用キーへ進めると安全です。先にWordPressだけ変えても、上位アカウントが侵害されたままなら再設定される可能性があります。

短期と中期に分けて再発を監視する

復旧直後は数時間単位で、mu-pluginsのファイル一覧、更新時刻、ハッシュ、外部通信、管理者、エラー、リダイレクトを確認します。その後は日次、週次へ間隔を広げ、通常の更新作業と不審変更を区別できる記録を続けます。

ファイル監視の通知が多すぎると見落としにつながるため、正規更新の時間帯と担当者を記録し、mu-pluginsの変更を優先通知にします。通知だけで自動削除せず、差分を確認してから対応してください。

復旧後に見るべき項目は、WordPressマルウェア駆除後の再感染防止にもまとめています。mu-pluginsだけがきれいでも、アカウントや別ディレクトリに原因が残れば再発します。

WordPressのmu-pluginsに関するよくある質問

mu-pluginsの調査で迷いやすい点を整理します。個別環境では保守契約やホスティング仕様が優先されるため、判断材料として利用してください。

mu-pluginsフォルダ自体がなければ異常ですか？

異常ではありません。WordPressの標準運用でmu-pluginsが必須とは限らず、利用していないサイトではフォルダが存在しないことがあります。必要な正規機能が導入された時に作成される場合もあります。

管理画面に表示されないmu-pluginはすべて危険ですか？

すべて危険ではありません。自動読み込みされ、通常のプラグインのように停止させない設計です。管理画面の表示だけで判断せず、提供元、コード、関連ファイル、ログ、サイト症状を照合してください。

不審なファイル名を変更するだけで停止できますか？

環境によっては読み込み対象から外れますが、推奨は公開領域外への保全付き隔離です。拡張子やサーバー設定によっては意図しない扱いになるため、元へ戻せる経路と動作確認項目を用意してから行います。

削除してサイトが正常なら調査は終了ですか？

終了ではありません。ファイルが別の感染箇所から作られた結果なら再発します。侵入口、管理者、通常プラグイン、テーマ、Cron、サーバー側設定、認証情報を確認し、一定期間の変更監視まで行ってください。

WordPressのmu-pluginsに不審なファイルがある時の対応まとめ

WordPressのmu-pluginsに見覚えのないファイルがあっても、管理画面から停止できないという理由だけでマルウェアとは断定できません。正規の保守・ホスティング・キャッシュ・セキュリティ機能が利用していることがあります。

安全な対応は、現状保存、関係者への由来確認、正規版との比較、コードとログの確認、戻せる隔離、一変更ごとの動作確認という順番です。悪意の根拠があっても、ファイルだけを消して終わらせず、再作成元と侵入口を調査してください。

復旧後は、正規mu-pluginsの台帳化、認証情報の更新、脆弱性対策、ファイル監視を行います。何を確認でき、何が未確認かを分けて記録することが、正規機能を守りながら再発を防ぐ最短ルートです。

判断に迷う場合は、証拠を消す前にファイルとログを保全し、WordPress復旧の専門家へ相談してください。

WordPressのmu-pluginsが不正か判断できない時は

見覚えのないmu-plugin、繰り返し戻るPHPファイル、サイト改ざんでお困りなら、
クイックレスキューが調査と復旧を支援します。

初期費用・調査費用0円。復旧できない場合は全額返金、作業後90日間の再感染・動作保証があります。