WordPressのwp-content直下にあるadvanced-cache.phpやobject-cache.phpを見つけ、「プラグイン一覧に表示されないのでマルウェアではないか」と不安になることがあります。
しかし、この2つはWordPressが正式に認識する「ドロップイン」と呼ばれる特殊なファイルで、正規のキャッシュ機能でも使われます。
一方、通常のプラグインより早く読み込まれる性質を悪用し、不正な転送や外部通信を仕込まれる例もあります。
ファイル名が正しいことだけで安全とはいえず、逆に、見覚えがないという理由だけで削除すると、画面が真っ白になる、管理画面へ入れない、Redisへの接続でエラーが出るなどの障害につながります。
確認の要点は、ファイル名ではなく「どの機能が、いつ、何の目的で生成したか」を説明できる状態にすることです。
この記事では、証拠を残して由来を照合し、advanced-cache.phpとobject-cache.phpを別々に判定し、安全に停止・隔離した後まで確認する手順を解説します。
先にバックアップと記録を残し、一度に変更するのは1要素だけにしましょう。原因を追える状態を保つことが、復旧を早めます。
- キャッシュ系ドロップインが通常プラグインと異なる理由
- 正規ファイル・設定残骸・不審ファイルを分ける確認項目
- advanced-cache.phpとobject-cache.phpの安全な停止順
- 変更後に表示・保存・ログイン・再生成を確認する方法
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
advanced-cache.php・object-cache.phpは削除前に役割を確認する
結論からいうと、どちらのファイルも存在するだけでは感染の証拠になりません。
WordPressコアはwp-content直下の特定ファイルを通常のプラグインとは別に読み込み、データベース、キャッシュ、メンテナンス表示などの動作を置き換えられるようにしています。
管理画面の「プラグイン」には通常の一覧と別にドロップインとして表示される場合があり、サイトヘルスの情報からも確認できます。通常プラグインのように管理画面の無効化ボタンがない構成も多いため、ファイルだけを見て判断せず、親となるプラグインやサーバー機能とセットで確認する必要があります。
advanced-cache.phpは主にページキャッシュの入口として使われ、object-cache.phpはRedisやMemcachedなどへWordPressのオブジェクトキャッシュ処理をつなぐ役割を持ちます。似た名前でも読み込み条件と依存先が異なるため、同じ手順で一括削除してはいけません。
まず、WordPressが認識する正規の用途、現在の設定、ファイル内容、生成元、更新時刻を一本の線で結びます。説明が一致すれば正規構成の可能性が高まり、説明できない差分やキャッシュ外の動作が見つかれば、残骸または不正ファイルとして調査を深めます。
- advanced-cache.php：高度なページキャッシュ処理
- object-cache.php：外部オブジェクトキャッシュ
- db.php：独自のデータベースクラス
- maintenance.php：メンテナンス中の独自表示
- fatal-error-handler.php：致命的エラー処理の置き換え
advanced-cache.phpはWP_CACHEが有効な時に早期実行される
object-cache.phpは外部キャッシュとの橋渡しを担当する
WordPressのキャッシュ系ドロップインを変更前に記録する
変更前は、復元できるバックアップと、後から比較できる記録を必ず残します。
対象ファイルを手元へダウンロードするだけでなく、可能ならサイト全体のファイルとデータベースも同じ時点で保全してください。キャッシュの停止後に別の障害が見つかった時、変更前へ戻せる基準点になります。
最低限記録するのは、絶対パス、ファイルサイズ、所有者・権限、最終更新日時、SHA-256などのハッシュ値です。
ファイル内容は行番号付きで保存し、サーバーやプラグインの設定画面も撮影します。
更新日時はコピー操作で変わることがあるため、コピー前の値を別のメモへ残します。
本番サイトで直接編集する前に、ステージング環境またはローカルの複製環境で再現できると安全です。特にEC、会員、予約、フォームを使うサイトは、見た目だけでなくログイン状態や一時データにもキャッシュが関係します。
また、保全後のファイルをブラウザーから実行したり、不明なPHPを調査用PCで開いたりしないでください。
テキストとして読むだけでも、秘密情報や接続先が含まれる場合があります。
共有が必要なら、認証情報、Cookie、APIキー、顧客情報を伏せたうえで、安全な経路を使用します。
記録表には「確認した事実」と「推測」を分けて書きます。
たとえば「更新日時が障害発生の3分前」は事実ですが、「このファイルが原因」はまだ推測です。
停止前後の結果を積み重ねて判断すれば、無関係な正規機能を誤って削除するリスクを抑えられます。
担当者、確認時刻、実施コマンド、判定根拠も記録すると、途中で担当が交代しても同じ条件で再確認できます。
ls -l --full-time wp-content/advanced-cache.php wp-content/object-cache.php
sha256sum wp-content/advanced-cache.php wp-content/object-cache.php
grep -n "WP_CACHE" wp-config.php親プラグイン・サーバー機能・外部キャッシュの由来を結ぶ
- 現在有効・停止中のキャッシュプラグインと設定画面
- レンタルサーバーやCDNの高速化機能
- Redis・Memcachedなど外部キャッシュの契約と稼働状態
- 制作会社・保守会社の作業報告とデプロイ履歴
- wp-config.phpのWP_CACHEとキャッシュ接続設定
発見のきっかけと症状を時刻付きで分ける
WordPressのadvanced-cache.phpが正規か不審かを見分ける
早期実行される性質を踏まえてコードの入口を見る
advanced-cache.phpはWordPress起動の早い段階で動くため、通常プラグインの権限確認や管理画面設定より前に処理されます。
外部入力をそのまま実行する処理、見覚えのない外部URLからコードを取得する処理、条件付き転送、任意ファイル読み込みがないか確認します。
evalやbase64_decodeという単語だけで不正と断定してはいけません。
何を入力にし、どの条件で、何を出力・実行し、管理者以外から呼べるかという動作で評価します。難読化が多く正規版との差分を説明できない場合は、実行せず専門調査へ切り替えるのが安全です。
- 親プラグイン・サーバー機能・導入者を特定できない
- 公式版や正規再生成版にない難読化・外部通信がある
- 端末・参照元・User-Agentで不審な転送を分岐している
- 管理者作成や別のPHP配置などキャッシュと無関係な処理がある
- 隔離後に同じハッシュで再作成され、作成元を説明できない
WordPressのobject-cache.phpが正規か不審かを見分ける
WordPressのobject-cache.phpは、ファイル単体よりも、接続先のキャッシュサービス、提供プラグイン、必要な関数、管理画面の状態をつないで判断します。
Redis等が止まっているからファイルも不正、という短絡は避けてください。
Redis・Memcached・ホスティング機能の有無を確認する
サーバーの管理画面で、永続オブジェクトキャッシュが有効か、どのサービスへ接続する設計かを確認します。
専用プラグインの設定画面、Site Health、サーバー会社の機能一覧が同じ状態を示すなら、正規構成の可能性が高まります。
反対に、契約上は外部キャッシュを使っておらず、関連プラグインもなく、接続先も不明で、エラーログに継続的な接続失敗があるなら残骸を疑います。
接続情報そのものは秘密情報として扱い、スクリーンショットや記事へ公開しないでください。
キャッシュと無関係な権限・通信・永続化処理を探す
不審かどうかは、キャッシュAPIの外で何をしているかが重要です。
未認証リクエストから任意コマンドやPHPを実行する、外部から命令を受け取る、不審ユーザーを作る、テーマや投稿を書き換える処理は、キャッシュの役割では説明できません。
ただし、ソケット通信、シリアライズ、圧縮、接続再試行は外部キャッシュで普通に使われます。
技術用語の見た目で決めず、接続先が正規か、入力を検証しているか、WordPressの要求に応じた処理か、提供元コードと一致するかで判断してください。
- 正規：提供元・接続サービス・版・管理画面表示を説明できる
- 残骸：提供元は分かるが現在は未使用で、古い設定だけが残る
- 未確定：由来が不明だが、悪意を示す動作も確認できない
- 不審：正規版との差分とキャッシュ外の危険動作を確認した
WordPressのキャッシュ系ドロップインを安全に停止・隔離する
WordPressのドロップインを止める時は、ファイルを先に消すのではなく、依存する機能を正規手順で停止し、保全コピーを残してから一つずつ読み込み対象から外します。
2ファイルを同時に変えると、どちらが障害原因だったか分からなくなります。
advanced-cache.phpは親機能とWP_CACHEを順番に整理する
まずメンテナンス時間を決め、ページキャッシュの保存先と設定を記録します。次に、親プラグインまたはサーバーのページキャッシュ機能を正規の画面から停止し、必要なキャッシュをパージします。
その後、advanced-cache.phpを公開領域外へ保全するか、元名が分かる名前へ変更し、サイトを確認します。wp-config.phpのWP_CACHEは、利用する機能と手順を確認してから変更し、ファイル編集前後のコピーを残してください。
- 設定・ファイル・キャッシュ保存先・障害時刻を記録する
- 親プラグインまたはサーバー機能を正規手順で停止する
- 保全コピーを作り、advanced-cache.phpだけを読み込み対象から外す
- WP_CACHEの扱いを利用中機能に合わせて確認する
- 公開画面・管理画面・投稿更新・未ログイン表示を試す
object-cache.phpは外部サービスとの接続を先に外す
object-cache.phpでは、Redis等を停止する前に、WordPress側の接続プラグインやサーバー機能を無効化する正規手順を確認します。
共有サービスを先に止めると、同じサーバーの別サイトまで影響する可能性があります。
WordPress側の利用を外し、キャッシュデータの扱いを確認してから、保全済みのobject-cache.phpだけを読み込み対象から外します。
WordPressコアの通常キャッシュへ戻った後、ログイン、投稿保存、検索、フォーム、ECや会員機能を試してください。
- 利用プラグイン・接続サービス・共有範囲を特定する
- WordPress側の外部キャッシュ連携を正規手順で停止する
- 保全コピーを作り、object-cache.phpだけを読み込み対象から外す
- エラーログとSite Healthで外部キャッシュ状態を確認する
- 表示だけでなく書き込み・ログイン・業務機能を試す
WordPressのドロップイン変更後に表示・保存・再生成を確認する
WordPressのキャッシュ系ドロップインは、トップページが一度開いただけでは正常と判断できません。
未ログイン表示、管理画面、データ更新、キャッシュ状態、ファイル再生成を時間を分けて確認してください。
公開画面とWordPressの書き込み操作を組み合わせて試す
トップ、個別記事、画像、検索、404、ログイン画面を、ログイン済みと未ログインの両方で確認します。
さらに下書きの作成・更新、メディア表示、フォーム送信、ECの在庫やカート、会員サイトの権限など、キャッシュ誤りが影響しやすい操作を試します。
確認中に別のキャッシュを一斉パージすると原因が分かりにくくなります。変更時刻、操作、結果、HTTP応答、エラーを表にし、一工程ごとに正常化した範囲を記録してください。
- 公開ページと管理画面に新しいPHPエラーがない
- 下書き保存と更新内容が直後・再読込後とも一致する
- ログイン・検索・フォーム・主要業務機能が正常に動く
- Site Healthのキャッシュ状態が意図した構成を示す
- 隔離ファイルが不明な処理から再生成されない
再生成された時は時刻・ハッシュ・作成元を追う
停止したはずのファイルが戻った場合、まず元の保全コピーとハッシュを比較します。
同じ内容なら正規プラグインやホスティング機能の自動修復、新しい内容なら更新処理、デプロイ、別の不審コードなどを候補にします。
再生成時刻の前後で、管理画面操作、WP-Cron、サーバー側Cron、デプロイログ、ファイルアクセス、プラグイン更新を照合します。
原因を特定せず何度も削除すると、証拠を減らしながら正規機能と不正処理の両方を繰り返し動かすことになります。
不審な動作があればキャッシュ以外の感染範囲へ広げる
キャッシュと無関係な外部通信、管理者追加、条件付き転送、PHP配置、投稿改ざんを確認した場合は、ドロップイン単体の問題として終わらせません。
WordPress本体、テーマ、通常プラグイン、mu-plugins、uploads、データベース、ユーザー、Cron、ログを同じ時間軸で調査します。
駆除後は、侵入口になった脆弱性や漏えいした認証情報を閉じ、正常なドロップインの版とハッシュを基準として記録し直します。
短期は再生成と不審通信、中期は更新後の再発やキャッシュ不整合を監視してください。
WordPressのadvanced-cache.php・object-cache.phpに関するよくある質問
キャッシュ系ドロップインは、正規用途と不要な残骸が同じファイル名で存在するため、よくある疑問も「状況による」が出発点です。
判断を急ぐ前に、次の基準を確認してください。
WordPressのキャッシュ系ドロップインは役割と停止順を確認する
WordPressのadvanced-cache.phpとobject-cache.phpは、正規の高速化でも不正な早期実行でも使われ得る場所です。
ファイル名だけで削除せず、WordPressが読み込む条件、親プラグイン、サーバー機能、外部キャッシュ、正規版との差分を確認してください。
- ドロップインは通常プラグインと配置・読み込み条件が違う
- advanced-cache.phpはWP_CACHEと親キャッシュ機能を確認する
- object-cache.phpは外部サービスとWordPress側の連携を確認する
- 保全後、依存機能を先に止めて1ファイルずつ隔離する
- 変更後は表示だけでなく保存・ログイン・再生成まで検証する
由来を説明できず、正規版にない処理や不審な再生成がある場合は、試しに実行・削除を繰り返さないでください。
保全したファイル、時刻、設定、ログ、症状をそろえて相談すれば、調査範囲と復旧手順を安全に決めやすくなります。
WordPressのキャッシュ系ドロップインを自分で判断できない時は
advanced-cache.phpやobject-cache.phpの由来が分からない、停止するとサイトが壊れる、不審なコードや再生成がある場合は、
クイックレスキューが証拠保全、感染調査、安全な隔離、復旧、再発防止まで対応します。
- キャッシュ系ドロップインを削除してよいか分からない
- 親プラグインを消したのにファイルだけ残っている
- object-cache.php停止後に管理画面や保存が不安定になった
- 隔離しても同じファイルが自動で再生成される
- キャッシュの残骸かマルウェアかを専門家に調べてほしい
- 復旧・駆除できない場合は全額返金保証
- 90日間の再感染保証・動作保証
- 初期費用・調査費用0円
