「WordPressのフォルダに見覚えのない.user.iniがあり、auto_prepend_fileという設定まで書かれている」と不安になっていませんか？
マルウェア感染を調べている途中で見つけると、すぐ削除したくなるものです。
しかし、.user.iniは正規のPHP設定にも使われるため、名前だけでは改ざんと断定できません。
反対に、不審なauto_prepend_fileを放置すると、
WordPressより先にバックドアや転送処理を読み込まれるおそれがあります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、正規設定を壊さず、.user.iniと指定先PHPを安全に調べる順番を解説します。
.user.iniとauto_prepend_fileの役割- 削除前に残すべき証拠と確認項目
- 複数階層から不審な設定を探す方法
- 指定先PHPが正規か改ざんかを判断する基準
- 復旧後に再発を確認する手順
結論から言うと、確認対象は.user.iniだけではありません。
指定先PHP、設定が効く階層、更新日時、提供元、ログを一組で照合する必要があります。
この記事では、初心者が証拠を消したりサイトを止めたりしないよう、
読み取り確認から復旧後の検証までを順番に説明します。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPressの.user.iniとauto_prepend_fileが危険な理由
.user.iniは、PHPをCGIまたはFastCGIとして動かす環境で使われる、
ディレクトリ単位の正規設定ファイルです。存在するだけなら感染の証拠ではありません。
PHP公式マニュアルでは、リクエストされたPHPファイルのディレクトリから、
ドキュメントルートへ向かって設定ファイルを探す仕組みが説明されています。
つまり、WordPress直下だけでなく、一つ上の公開領域や子ディレクトリにも、
同じサイトへ影響する.user.iniが置かれている場合があります。
auto_prepend_fileは、通常のPHPファイルを実行する前に、
指定されたファイルをrequire相当で自動的に読み込む設定です。
正規用途では、共通初期化、監視、WAF、ホスティング会社の保護機能などに使われます。
そのため、絶対パスが書かれているだけで不正とは言い切れません。
一方、攻撃者が指定先を自分のPHPへ向けると、WordPressのindex.phpより前に、
不正な転送、SEOスパム、外部通信、命令受信などを動かせます。
- WordPress本体やテーマの外側で動く
- プラグインを全停止しても読み込まれる可能性がある
- WordPressを上書き更新しても設定ファイルが残る
- 検索経由・スマホ・未ログイン時だけ挙動を変えられる
- 上位ディレクトリの設定が子サイトへ影響する
トップページが普通に表示され、管理画面へも入れるから安全とは限りません。
条件付き処理なら、運営者のIPやログイン状態を見て不正動作を隠すこともできます。
感染ファイルを探す基本は、次の記事でも詳しく解説しています。
ただし今回は、ファイル探索だけでなくPHP設定との結び付きを確認してください。
WordPressの.user.iniを消す前に保存する情報
最初に行うべきことは削除ではなく、現在の状態を証拠として残すことです。
設定を先に変えると、侵入時期や再生成元を追う手がかりまで失う可能性があります。
ファイルマネージャーやSFTPで.user.iniをダウンロードし、
公開フォルダの外側または手元の安全な保管先へコピーします。
コピー時には内容だけでなく、元の絶対パス、所有者、権限、作成・更新日時、
ファイルサイズを記録してください。スクリーンショットだけでは不足します。
auto_prepend_fileの右側に書かれた指定先も、同じ方法で保全します。
相対パスなら、どのディレクトリを基準に解決されるかを確認します。
.user.ini原本と完全な設置パス- 指定先PHPの原本、パス、サイズ、更新日時
- 所有者・グループ・パーミッション
- SHA-256などのハッシュ値
- サーバーアクセスログとエラーログの該当期間
- 発見時の症状、URL、端末、時刻、ログイン状態
SSHを使える場合は、次の読み取り専用コマンドで属性とハッシュを確認できます。
パスは実際のファイルへ置き換え、結果を非公開で保存してください。
stat /path/to/public_html/.user.ini
shasum -a 256 /path/to/public_html/.user.ini
shasum -a 256 /path/to/prepended-file.php不審なPHPをブラウザで開いたり、手元のPHP環境で実行したりしてはいけません。
内容確認はテキストとして行い、難読化の解除も実行せず静的に進めます。
メール送信、決済、会員機能があるサイトでは、公開停止の影響も考えます。
緊急度が高い時は、メンテナンス表示やアクセス制限を安全な経路で実施してください。
ただし、感染時点が不明なバックアップをそのまま上書きするのは危険です。
証拠と最新の正規データを分けて確保してから、復旧方法を決めます。
WordPressの.user.iniとauto_prepend_fileを探す方法
調査はWordPress直下だけで終わらせず、公開領域の上位と子ディレクトリも確認します。
PHPは階層ごとの設定を探すため、別の場所にある一つのファイルが影響している場合があります。
レンタルサーバーでは、ファイルマネージャーの「隠しファイルを表示」を有効にします。
先頭がドットのファイルは、初期表示では見えないことがあるためです。
まず、契約中のサーバー管理画面でPHP設定の変更履歴や追加設定を確認します。
ホスティング会社が自動作成した正規ファイルなら、マニュアルに役割が記載されていることがあります。
次に、WordPress直下、ドキュメントルート、一つ上の契約領域、
サブドメインや同居サイトのルートを順番に見ます。
SSHが利用できる場合は、削除や変更を含まない次のコマンドで一覧化できます。/path/to/accountは、確認を許可された契約領域だけに置き換えてください。
find /path/to/account -type f -name '.user.ini' -print
grep -RIn --include='.user.ini' -E 'auto_prepend_file|auto_append_file' /path/to/account検索結果が複数ある場合は、どれか一つだけを見て判断しません。
上位から下位へ並べ、各ファイルの設定と対象サイトの関係を図にします。
auto_append_fileも見つかった場合は、PHP実行後に別ファイルを読む設定です。
役割は異なりますが、同じく提供元と指定先を確認してください。
- CLI版PHPとWebサイト側PHPは別の設定を読む場合がある
- WordPress直下に設定がなくても上位階層から適用される場合がある
- 同じサーバーでもドメインごとにPHPバージョンやSAPIが違う場合がある
- 変更直後はキャッシュにより旧設定が残る場合がある
php -iやphp --iniの結果は、サーバー上の手がかりにはなります。
ただしCLI版の結果で、ブラウザから実行されるPHP設定まで断定してはいけません。
Web側の有効値は、サーバー管理画面やホスティング会社の診断機能を優先します。
公開場所へphpinfo()を置く方法は、内部パスや設定を漏らすため安易に使わないでください。
PHP公式では、user_ini.cache_ttlの既定値は300秒とされています。
変更後に数分挙動が残っても、直ちに再改ざんと決めつけないことが大切です。
一方、キャッシュ時間を過ぎても同じ設定が戻る、ファイル自体の更新時刻が変わる場合は、
再生成するプログラムやCron、別サイトからの書き込みを疑います。
auto_prepend_fileの指定先が正規か判断するポイント
正規か不正かは、ファイル名の印象ではなく、由来と動作を積み上げて判断します。security.phpのような名前でも不正な場合があり、意味不明な名前でも正規製品の一部かもしれません。
最初に確認するのは、サーバー会社、保守会社、セキュリティ製品が設置した記録です。
契約変更やWAF導入の日時と、ファイルの更新日時が一致するかを見ます。
次に、指定先が公開領域の外にあり、所有者と権限が適切かを確認します。
公開領域内にあるだけで不正ではありませんが、第三者が書き換えやすい権限なら危険度が上がります。
指定先PHPに、長い16進数やBase64、文字列結合、可変関数、外部URL、
POST値を評価する処理がある場合は、実行せず専門的な静的解析が必要です。
ただし、難読化関数が一つあるだけでマルウェアと断定はできません。
正規製品もコード保護を行うため、配布元の原本や既知のハッシュと比較します。
- 設置した製品・会社・担当者を説明できるか
- 公式配布物や正常な別環境と内容が一致するか
- 設置場所、所有者、権限が運用ルールに合うか
- 外部通信先と送信内容に正当な理由があるか
- 不審症状の開始時刻と更新日時が近いか
- 削除後に別の処理から再生成されないか
絶対パスが、別契約者の領域、用途不明の一時フォルダ、画像フォルダ、
見覚えのない隠しディレクトリを指す場合は、特に慎重に調べます。
反対に、ホスティング会社の管理領域を指していても、それだけで安全とは限りません。
そのパスが現在の契約で正規に使われるものか、サポートへ確認します。
指定先PHPの判断に迷う時は、不審なPHPを評価する観点も参考になります。
削除前に、由来、正規版との差分、コード、ログを合わせてください。
.htaccessも同時に何度も戻る場合は、一つのファイルだけの問題ではありません。
書き換え元を時系列で探す方法は、次の記事で確認できます。
WordPressの.user.ini改ざんを安全に復旧する手順
復旧は、設定だけを消す作業ではありません。
証拠保全、封じ込め、不正処理の停止、侵入口修正、動作確認までを一続きで行います。
- 発見時のファイル、属性、ハッシュ、ログを保全する
- 正規設定か不正設定かを提供元と原本で照合する
- 影響範囲を確認し、安全な方法で不正処理を停止する
- 指定先PHPと関連するバックドアを隔離・駆除する
- WordPress本体、テーマ、プラグイン、ユーザー、Cronを確認する
- 認証情報を安全な端末から変更し、セッションを失効する
- PC・スマホ・検索経由・フォーム・管理画面を検証する
正規設定と判明した場合は、削除せず役割を記録します。
内容が古い、設定先が消えている場合も、管理元へ確認してから修正してください。
不正設定と判断した場合も、いきなり.user.ini全体を消すのは避けます。
ほかの正規設定まで失うと、エラー表示やアップロード上限など別の障害が起こり得ます。
安全な停止方法はサーバー構成で変わります。PHP公式ではnoneが、
自動読み込みを無効にする特別な値ですが、現場では管理画面やサポート手順を優先します。
編集前と編集後のファイルを分けて保存し、変更者と時刻を記録します。
作業途中の状態が分からなくなると、再発時の比較ができません。
指定先PHPは公開領域外へ隔離し、WebやCronから実行できない状態にします。
削除は証拠保全と関連調査が終わり、復元元がないと確認してから判断します。
その後、WordPressコアを公式配布物と照合し、テーマとプラグインも正規版と比較します。
更新ボタンを押すだけでは、追加された不正ファイルが残る場合があります。
mu-pluginsは通常のプラグイン一覧と扱いが異なり、自動で読み込まれます。
見覚えのないローダーがある時は、停止影響を調べてから隔離してください。
管理者ユーザー、Application Passwords、FTP・SFTP、サーバー管理画面、DB、
メール、DNS、CDNなど、侵害範囲に応じて認証情報を変更します。
感染中の端末からパスワードを変えると、変更後の情報も盗まれるおそれがあります。
安全を確認した端末と通信経路を使い、使い回しも解消してください。
同じサーバーに複数のWordPressや古いCMSがある場合は、全体を確認します。
一つだけ直しても、書き込み可能な別サイトから再感染することがあるためです。
復旧後は、トップページだけで完了にしません。
管理画面、投稿保存、画像アップロード、問い合わせフォーム、会員機能も試します。
PCとスマホ、ログイン済みと未ログイン、通常アクセスと検索結果経由を比較します。
条件付き転送や広告挿入は、運営者の確認環境だけでは見えない場合があります。
アクセスログ、PHPエラーログ、ファイル変更監視を続け、.user.iniと指定先が再作成されないことを確認して復旧完了とします。
WordPressの.user.ini改ざんが再発する原因
設定を直しても戻る時は、.user.iniが原因ではなく結果である可能性があります。
書き換えられる権限と再生成する処理が残っていないかを調べます。
よくある再生成元は、不正なテーマ・プラグイン、mu-plugins、Cron、
管理者アカウント、同居サイト、盗まれたSFTP情報、サーバー側タスクです。
更新日時を一定間隔で記録し、アクセスログやCron実行時刻と並べると、
どの操作の直後に戻ったかを絞り込みやすくなります。
ファイル自体は変わらず、挙動だけが数分残った場合は、PHPの設定キャッシュも確認します。
既定の300秒を過ぎる前に、再感染と誤判定しないよう注意してください。
- WordPressのCronとサーバー側Cron
- 自動読み込みされるmu-pluginsとドロップイン
- テーマのfunctions.phpと不審な子テーマ
- 管理者、Application Passwords、API連携
- 同一アカウント内の別WordPress・旧CMS
- SFTP、サーバー管理画面、メールのログイン履歴
バックアップ復元だけで一時的に直っても、侵入口や盗まれた認証情報が残れば再発します。
AIの助言どおりにファイルを戻した後で再感染した事例の考え方も参考にしてください。
再発した時は、同じ編集を何度も繰り返すより、状態を保存して調査範囲を広げます。
変更を重ねるほど、最初の侵入経路と不正処理の関係が見えにくくなります。
WordPressの.user.ini改ざんを防ぐ運用
再発防止の基本は、正規状態を記録し、変更を早く検知できる運用です。
完全に攻撃をゼロにするのではなく、侵入しにくくし、被害を小さくします。
WordPress本体、テーマ、プラグイン、PHPを保守対象として一覧化し、
不要なものはバックアップと影響確認の後に整理します。
.user.ini、.htaccess、wp-config.phpなど、
重要設定ファイルのハッシュと属性を正常時に保存しておくと比較が速くなります。
ファイル権限はサーバー会社の推奨値を使い、必要以上に書き込み可能にしません。
一律で強い権限へ変えると、更新不能や情報漏えいを招くため避けてください。
管理者には多要素認証を使い、退職者や委託終了者のアカウントを残しません。
SFTPやサーバー管理画面にも、WordPressと別の強いパスワードを設定します。
バックアップはサーバー内だけに置かず、世代を分けて外部にも保管します。
復元できるかを定期的に確認し、感染後の上書きだけを残さないようにします。
駆除後に確認すべき設定、ユーザー、検索結果、ログの全体像は、
次の記事でチェックリストとして整理しています。
WordPress公式も、更新、信頼できる配布元、バックアップ、ログ、監視を重視しています。
一つの対策だけに頼らず、複数の防御と復旧準備を組み合わせてください。
WordPressの.user.ini改ざんでよくある質問
WordPressの.user.ini改ざん確認まとめ
.user.iniは正規のPHP設定ファイルであり、存在だけでは感染と断定できません。
しかし、不審なauto_prepend_fileはWordPressより先に任意のPHPを読ませる入口になり得ます。
安全な対応は、削除より先に原本、パス、属性、ハッシュ、ログを保存することです。
指定先PHPと適用階層を確認し、正規提供元や正常環境と比較してください。
- WordPress直下だけでなく上位・子階層も調べる
- CLIとWeb側のPHP設定を混同しない
- 正規設定を含むファイル全体を無断で消さない
- 指定先PHP、Cron、管理者、同居サイトまで確認する
- キャッシュ時間経過後も再生成されるか監視する
- PC・スマホ・検索経由・フォーム・管理画面を検証する
どこまでが正規設定か分からない状態で変更を重ねると、証拠と復旧経路を失います。
不審な指定先や再生成が確認できた時は、現状を保ったまま専門家へ相談してください。
WordPressの.user.ini改ざんが自分で判断できない時は
.user.iniの設定、指定先PHP、WordPress、同居サイトをまとめて調べ、
正規設定を守りながら不正な読み込みと再生成元を特定します。
auto_prepend_fileの指定先が安全か分からない.user.iniを直しても元へ戻る- 検索経由やスマホだけ別サイトへ転送される
- 正規設定を消してサイトを壊すのが怖い
- 同じサーバーの複数サイトをまとめて調べたい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
