WordPressのwp-content/cacheを開いたら、見覚えのないPHPファイルがあり、
「キャッシュのはずなのに危険では」と不安になっていませんか？
PHPはサーバー上で処理を実行できる形式です。
しかし、cache内にあるという理由だけで、すべてをマルウェアと断定することはできません。
空のindex.phpで一覧表示を防ぐ構成や、
キャッシュプラグイン・サーバー機能が正規に作る補助ファイルもあります。
反対に、攻撃者が目立ちにくい保存場所としてcacheを悪用し、
バックドアや再感染用ローダーを置く事例もあるため、由来を確かめる必要があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、cache内のPHPを決めつけず、安全な順番で確認する方法を解説します。
- wp-content/cacheにPHPがある時の危険度
- 正規のindex.phpやキャッシュ補助ファイルとの違い
- 実行せずテキストとして安全に確認する手順
- 証拠保全から封じ込め・再生成監視までの順番
結論は、最初にファイルと生成元の証拠を残し、プラグイン・サーバー設定・更新時刻と照合してから、
実行せずに内容を確認し、疑わしさが裏付けられたものだけを封じ込めることです。
cache全体を先に消すと、正常な生成物と侵入痕跡の両方を失います。
この記事では、初心者でも調査の順番を崩さないよう、判断材料を一つずつ整理します。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPressのwp-content/cacheにPHPがある時は由来で危険度を判断する
結論からいうと、危険度は拡張子や保存場所だけでなく、誰が何のために生成したかで判断します。
wp-content/cacheはWordPressコアが常に同じ構成で管理する場所ではありません。
利用中のキャッシュプラグインやレンタルサーバーの高速化機能により、フォルダ構成と保存形式が変わります。
HTML、圧縮データ、CSS、JavaScript、メタデータが中心の環境もあれば、
ディレクトリ保護用のindex.phpや、キャッシュを読み込むPHP補助ファイルが置かれる環境もあります。
PHPがあるだけでは感染の証拠にならない
正規ファイルでもPHP拡張子を使う場合があるため、発見だけで削除へ進むのは危険です。
キャッシュ機能を壊すと、表示崩れ、500エラー、管理画面の保存失敗などを招くことがあります。
一方、cacheは大量の生成物が並び、管理者が一つずつ確認しにくい場所です。
攻撃者が不正ファイルを紛れ込ませる場所として選ぶ可能性も否定できません。
危険度は複数の根拠を重ねて三段階で考える
正規パッケージや稼働中の機能と一致し、内容・配置・時刻を説明できるなら危険度は低めです。
ただし、不要になった古い生成物なら、保全後に正規の削除手順を確認します。
生成元は推定できるものの、停止済みプラグインの残骸、版の不一致、想定外の権限がある場合は要調査です。
由来が説明できず、不審な通信・書き込み・外部入力による動作が重なるなら危険度は高まります。
- 低め：正規の生成元、用途、配置、内容、時刻を説明できる
- 要調査：親機能は分かるが、版・配置・権限・時刻に不一致がある
- 高い：生成元不明で、実行・外部通信・書き込み・難読化などが重なる
不審なPHP全般の評価軸を先に確認したい場合は、次の記事も役立ちます。
WordPressのcache内で正規に見られるPHPの特徴を確認する
正規ファイルの可能性を判断するには、index.phpの保護目的とキャッシュ機能の補助処理を分けて確認します。
index.phpは一覧表示を避ける空の入口の場合がある
プラグインが作るサブフォルダには、URLからディレクトリを開かれた時に、
中のファイル一覧を見せないため、ほぼ何もしないindex.phpが置かれることがあります。
短いコメントと終了だけ、または空の応答を返すだけで、同じプラグインの複数フォルダに同一内容があるなら、
保護用プレースホルダーとして説明できる可能性があります。
ただし、ファイル名がindex.phpでも安全とは限りません。
長い難読化コード、外部入力の処理、別ファイルの作成、知らない通信先があれば、名前ではなく動作を調べます。
キャッシュプラグインやサーバー機能のローダーを照合する
キャッシュ機能によっては、設定値、キャッシュ索引、条件分岐、読み込み処理をPHPで持つことがあります。
有効なプラグイン名、サーバーの高速化機能、管理画面の設定と、ファイル内の名称・参照先を照合してください。
たとえば親プラグインのディレクトリを読み込む、同じサイト内の設定だけを参照する、
キャッシュ削除や再構築の時刻に合わせて更新される、といった関係が確認材料になります。
レンタルサーバー側の機能では、WordPress管理画面に通常プラグインとして見えない場合があります。
サーバー管理画面の高速化設定や公式マニュアルも確認し、名称が見つからないだけで不正と決めないでください。
wp-content直下のドロップインとは場所を混同しない
advanced-cache.phpやobject-cache.phpは、通常はwp-content直下に置かれるドロップインです。wp-content/cache内の生成物とは、読み込まれ方と確認する親機能が異なります。
同じ「キャッシュ」という名前でも、直下のドロップイン、cacheフォルダ内のページキャッシュ、
サーバー側のキャッシュを一括で削除しないことが重要です。
WordPressのcache内PHPは証拠を残して生成元を特定する
最初に行うべきことは削除ではなく、ファイルの状態を保存し、生成した機能を特定することです。
cacheを先に空にすると、ファイル名、配置、更新の並び、再生成前の内容が消えます。
侵入時刻や生成元を追う手掛かりまで失うため、調査の再現性が下がります。
パス・属性・ハッシュ・周辺ファイルを記録する
対象のフルパス、ファイル名、容量、更新日時、所有者、権限、SHA-256ハッシュを記録します。
同じ階層のフォルダ名と前後のファイルも一覧で残すと、単独で置かれたのか生成物の一部かを比較できます。
原本を編集せず、SFTPやサーバーのファイルマネージャーから調査用コピーを取得してください。
コピーの保存場所、取得時刻、取得担当者も記録し、チャットや公開ストレージへ安易に置かないようにします。
有効・停止済みプラグインとサーバー設定を棚卸しする
キャッシュ、高速化、最適化、CDN連携に関係するプラグインを一覧化し、
有効状態、バージョン、最終更新、設定上の保存先を確認します。
停止済み・削除済みプラグインの残骸も対象です。
サーバー側のページキャッシュ、OPcache、リバースプロキシ機能とは区別し、どの層が対象ファイルを作るか整理します。
見覚えのないプラグインが生成元として現れた場合は、管理画面の表示だけで信頼せず、
配布元、構成ファイル、更新元、依存機能を確認してください。
アクセスログとキャッシュ操作履歴を保全する
Webサーバー、WAF、CDN、サーバー管理画面にログがある場合は、
対象パスへの直接アクセス、同時刻の管理画面操作、ファイル作成前後のリクエストを保存します。
正規のキャッシュ生成なら、記事閲覧、公開、パージ、設定保存など、説明できる操作と結び付くことがあります。
反対に、通常アクセスしないPHPへ外部から繰り返しPOSTされていれば、危険度を上げる根拠になります。
ログがない期間は「第三者アクセスなし」と断定できません。
保持期間外、CDN経由、別ホストへの記録などを区別し、確認できた事実と不明な範囲を分けて残してください。
- 対象ファイルと周辺一覧を保存する
- 属性・ハッシュ・取得時刻を記録する
- キャッシュ関連のプラグインとサーバー機能を洗い出す
- 設定上の保存先と実際のパスを対応付ける
- 削除やパージを行う前の状態を残す
WordPressのキャッシュ規則と更新時刻を比較してPHPの由来を絞る
生成元の候補が見つかったら、設定・再生成条件・時刻の三つをつないで説明できるか確認します。
ファイル内にプラグイン名が書かれているだけでは、正規性の証明になりません。
攻撃者が正規名称をコメントへ入れ、もっともらしく見せることもできるためです。
公式配布物・同じ版・同じ設定の環境と比べる
プラグイン本体に同名テンプレートがあるか、公式配布物に生成処理が含まれるかを確認します。
比較する時は最新版ではなく、現在利用している版と同じ版を基準にしてください。
生成物はサイトURL、パス、設定値を含み、環境ごとにハッシュが変わることがあります。
完全一致しない時は、固定部分と環境依存部分を分け、正規処理で説明できない差分を探します。
更新・パージ・アクセスの時刻を一本の時系列にする
対象PHPの更新日時と、プラグイン更新、設定変更、キャッシュ削除、記事公開、サーバー移転、
不審アクセスの時刻を並べます。正常な再生成イベントと一致するかを見てください。
ただし、更新日時だけで断定してはいけません。
バックアップ復元、ファイルコピー、時刻設定の違いにより、mtimeは変わったり引き継がれたりします。
キャッシュルールとWebからの到達性を確認する
cache配下への直接アクセスが拒否されるか、PHPとして処理されるか、静的ファイルとして配信されるかを、
サーバー設定とアクセスログから確認します。
調査対象のURLをブラウザーで開いてPHPを試す方法は避けてください。
不正コードなら実行してしまうため、Webサーバー設定、既存ログ、ステージング環境での安全な確認を優先します。
WordPressのcache内PHPを実行せずテキストとして安全に調べる
内容確認は、サーバーやブラウザーで実行せず、保全したコピーをテキストとして読むのが原則です。
URLへアクセスする、PHPコマンドへ渡す、WordPressからincludeする、といった確認は行いません。
調査用端末のコードエディターや、実行権限のない解析環境で文字列として開きます。
file 'copy-of-suspect.php'
shasum -a 256 'copy-of-suspect.php'上の例はファイルを実行せず、形式表示とハッシュ計算だけを行います。
Windowsではプロパティやセキュリティ製品、信頼できるハッシュ計算機能を使っても構いません。
正常な補助処理は役割と参照先が限定される
正規のプレースホルダーは処理が短く、キャッシュローダーは親プラグインやローカル設定など、
説明可能な参照先へ限定されていることが一般的です。
コメント、関数名、参照パス、定数、生成元の署名を確認し、公式配布物の生成処理と照合します。
コードが長いことや圧縮されていることだけで、直ちに悪意ある処理とは決めません。
不審な動作は外部入力・通信・書き込みの組み合わせを見る
リクエスト値を使って任意の処理を選ぶ、外部ドメインやIPへ接続する、
別のPHPを作成する、ユーザーや設定を書き換える、といった動作は強い確認対象です。
長い文字列の復号、複数段の難読化、エラー非表示、画像やキャッシュデータへの偽装が重なる場合も、
生成元の説明と一致するかを詳しく調べます。
ただし、個々の関数名だけで感染を断定しないでください。
プラグイン更新機能や圧縮処理にも似た関数が使われるため、入力元と最終的な処理まで追う必要があります。
秘密情報を外部サービスへ貼り付けない
PHPの内容には、サーバーパス、キャッシュキー、内部URL、API情報が含まれる場合があります。
公開型の解析サイト、掲示板、生成AIへファイル全体を貼ると、新たな情報漏えいにつながりかねません。
相談する時は、ドメイン、ユーザー名、IP、認証情報を伏せ、必要な範囲だけ共有します。
元ファイルを渡す必要がある場合は、送付先、暗号化、閲覧権限、保管期限を先に確認してください。
- 親プラグイン・サーバー機能・ローカル設定への参照
- URLパラメーター、Cookie、POSTデータなど外部入力の扱い
- 外部ドメイン・IP・不明なファイルへの通信
- PHP、ユーザー、データベース、Cronへの書き込み
- 難読化後に実行される最終処理と再生成条件
同じサイト内にほかの感染候補がないか調べる時は、広い探索手順も併用してください。
WordPressの不審なcache内PHPは限定して封じ込め再生成元を探す
疑わしさが裏付けられた時は、確認済みの対象だけを封じ込め、再投入する原因を探してからキャッシュを再構築します。
確認できた対象だけを本番の実行経路から外す
保全後、対象ファイルへのWebアクセスや読み込みを止め、公開領域外の隔離場所で保持します。
具体的な方法はサーバー構成で異なるため、サーバー会社の手順や保守担当者の管理下で行ってください。
cacheフォルダ全体を先に削除したり、関連しそうなPHPを一括で消したりしません。
正常なキャッシュ処理を壊すだけでなく、攻撃者が使った時刻・内容・再生成の手掛かりまで消えるためです。
キャッシュ以外の再投入元と侵入口を確認する
cacheは最終的な出力先にすぎず、原因が別の場所に残ることがあります。
脆弱なプラグイン、改ざんされたテーマ、mu-plugins、ドロップイン、データベース内の不正コードを確認します。
さらに、WordPress管理者、Application Passwords、SFTP・サーバーアカウント、Cron、
サーバーの定期処理、CI/CDやバックアップ復元など、ファイルを再配置できる経路も調査対象です。
対象を隔離した直後に同じ名前や似た内容が戻る場合は、再投入元が残っています。
戻った時刻とアクセスログ、管理操作、予約処理を照合し、再感染の起点を絞ってください。
正規の方法でキャッシュを再構築して監視する
侵入口と再投入元を封じた後、プラグイン管理画面やサーバーの公式機能からキャッシュを再構築します。
生成されたフォルダ、ファイル形式、所有者、権限、時刻、ハッシュを新しい基準として記録します。
未ログイン表示、ログイン後の画面、投稿更新、フォーム、ECや会員機能など、
キャッシュ誤配信の影響が大きい操作も確認してください。
直後だけで終わらせず、次回の自動パージ、定期処理、アクセス増加後にも再確認します。
同じPHPが戻る、内容が変わる、想定外の通信が再開する場合は、復旧完了とは判断できません。
正常時のファイル一覧とハッシュを基準として残しておくと、次回は差分を早く発見できます。
ただし、正規更新で内容が変わるため、差分が出たら更新履歴と再び照合し、自動で感染扱いにしないことが大切です。
- 証拠を保全して生成元を特定する
- プラグイン・サーバー設定・キャッシュ規則・時刻を比較する
- コピーを実行せずテキストとして確認する
- 確認済みの不審物だけを封じ込める
- 侵入口と再投入元を修正する
- 正規キャッシュを再構築し時間を分けて監視する
復旧後のアカウント、更新、バックアップ、監視を見直す時は、次の記事へ進んでください。
WordPressのwp-content/cacheにあるPHPでよくある質問
よくある疑問への答えも、存在だけで断定せず、保全と生成元確認を優先する点は同じです。
WordPressのcache内PHPは保全・由来確認・限定対処の順で調べる
wp-content/cacheのPHPは、正規生成物と不審な実行ファイルを分け、順番を守って対処することが重要です。
index.phpのプレースホルダーやキャッシュローダーが正規に存在する場合があるため、
「PHPだからマルウェア」「cacheだから消してよい」という判断は避けてください。
まずファイルと周辺情報を保全し、生成元を特定します。
次に、プラグイン・サーバー機能・キャッシュ規則・時刻を照合し、コピーを実行せず内容を確認します。
不審な動作が複数の根拠で確認できたら、その対象だけを封じ込め、
キャッシュ外の侵入口と再投入元を修正してから、正規機能で再構築してください。
最後に、再生成後のファイル、表示、更新操作、ログを時間を分けて監視します。
証拠を消さずに原因まで閉じることが、安全な復旧と再発防止につながります。
WordPressのcache内PHPを自分で判断できない時は
生成元や実行内容を判断できない場合は、削除前に専門家へ調査を切り替えるのが安全です。
cache内のPHPが正規か分からない、隔離するとサイトが壊れそう、削除後に同じファイルが戻る場合は、
クイックレスキューが証拠保全、感染調査、封じ込め、安全な復旧、再発防止まで対応します。
- index.phpや見覚えのないPHPを削除してよいか分からない
- キャッシュプラグインと不審ファイルの関係を調べたい
- ファイルを消しても同じ場所へ再生成される
- サイトを止めずに証拠保全と復旧を進めたい
- cache以外の侵入口やバックドアも調査したい
