WordPressのindex.phpが何度直しても改ざんされる時の調査手順

「WordPressのindex.phpを正しい内容へ戻したのに、数時間後にはまた知らないコードへ書き換わっている」と困っていませんか？
同じファイルを何度も上書きしても戻るなら、修復できていないのではなく、別の場所に残った処理が再び書き込んでいる可能性があります。

index.phpはWordPressへ届いたアクセスを読み込み処理へ渡す入口です。
短いファイルだから簡単に直せそうに見えますが、ここだけを直すと証拠が消え、再投入元を見失うことがあります。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、index.phpを上書きする前の保全から、書き換え元の追跡、安全な復元と再発確認まで順番に解説します。

結論は、index.phpだけを上書きせず、改ざんされた時刻と実行経路を先に固定することです。
ファイル、ログ、Cron、管理者、FTP、同居サイトを同じ時系列で照合し、再投入元を止めてから公式ファイルへ戻します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのindex.phpが何度直しても改ざんされる時は上書きを止める

最初の結論は、同じindex.phpを繰り返し上書きする作業をいったん止めることです。
戻るたびに消してしまうと、書き換え時刻、コードの特徴、所有者や権限など、原因へ近づく情報まで失います。

index.phpはWordPressの入口として使われる

一般的なWordPressルートのindex.phpは、環境を読み込むwp-blog-header.phpへ処理を渡す小さなファイルです。
テーマの表示内容や投稿データを直接持つ場所ではなく、リクエストをWordPress本体へつなぐフロントコントローラーとして働きます。

そのため、先頭に長い難読化コードが追加される、外部URLを読み込む、CookieやUser-Agentで分岐する、知らないPHPをincludeする、といった変更は要注意です。
ただし、ファイルが長いという理由だけで感染と断定してはいけません。管理ツールやホスティング側の正規設定が入る例もあるため、由来と正規版との差分が必要です。

直後に戻る場合と数時間後に戻る場合を分ける

復元直後、同じ秒や数分以内に戻るなら、常駐プロセス、アクセスのたびに動くPHP、監視型のバックドア、サーバー側の自動処理を優先して疑います。
毎時や毎日など一定間隔なら、WordPressのCron、サーバーのCron、外部監視サービス、バックアップ復元処理との対応を確認します。

特定の管理者がログインした後だけ戻るなら、管理画面のコード挿入機能、不審プラグイン、侵害された端末やFTPソフトも候補です。
再発までの時間を記録するだけで、無作為なファイル探しから「どの処理が動いた時か」という調査へ変えられます。

.htaccessも同時に戻る場合は、二つのファイルを別々に直さず、同じ実行元が触っていないかを確認してください。
関連する確認順は、次の記事で詳しく整理しています。

クイックレスキュー

WordPressの.htaccessが何度直しても改ざんされる原因｜再生成前に調べる場所 WordPressの.htaccessを修正・再生成しても改ざんが戻る場合に、証拠を消さず、プラグイン・Cron・不審PHP・管理者・サーバー設定から書き換え元を特定し、安全に復旧する…

WordPressのindex.phpを直す前に証拠を保全する

index.phpを修復する前に、対象ファイルと周辺情報を読み取り用コピーとして保存します。
必要なのは不審コードだけではなく、いつ、どの権限で、どの場所に作られたファイルかを後から説明できる状態です。

原本・更新時刻・権限・ハッシュを一組で残す

まずサーバー管理画面やSFTPでindex.phpをダウンロードし、編集しない原本として保管します。
ファイルのフルパス、更新時刻、所有者、グループ、パーミッション、容量もスクリーンショットまたはテキストで残してください。

可能ならSHA-256などのハッシュ値も記録します。
ハッシュは「同じ名前のファイルが、調査開始時と復元後で同じ内容か」を確認する指紋であり、ハッシュだけで安全性を判定するものではありません。

読み取り確認の例（実際の設置先に合わせる）
stat /path/to/wordpress/index.php
shasum -a 256 /path/to/wordpress/index.php
cp -p /path/to/wordpress/index.php /safe/path/index.php.suspect-copy

共有サーバーでコマンドが使えない場合は、管理画面のファイル情報とダウンロードで代替できます。
保全先は公開ディレクトリの外に置き、ブラウザから開ける場所へ不審PHPをコピーしないでください。

どのindex.phpかをフルパスで区別する

サーバー内には、ドキュメントルート、サブディレクトリ版WordPress、テーマ、プラグイン、キャッシュ、別CMSなど、複数のindex.phpがあります。
「index.phpが改ざんされた」という記録だけでは、次の担当者が同じファイルを確認できません。

ドメインが実際に参照する公開ルートと、WordPress設定上のアドレスを確認し、対象の絶対パスを記録します。
古いWordPressや検証環境が同じアカウント内に残っている場合は、現在のサイトだけ直しても別環境から再感染する可能性があります。

周辺に見覚えのないPHPがある場合も、名前だけで削除せず、配置場所と由来から危険度を判断します。
隔離か削除か迷う時は、次の記事の判断基準を参照してください。

クイックレスキュー

WordPressの不審なPHPファイルは放置していい？危険度と削除判断の考え方 WordPressのサーバーで見覚えのないPHPファイルを見つけて困っていませんか？放置・即削除を避け、場所、正規版との差分、コード、ログから危険度を判断する手順を解説。証…

WordPressのindex.phpが本当に改ざんされているか正規版と比べる

保全後は、稼働中のWordPressと同じバージョンの公式配布物を基準にして差分を確認します。
インターネット上の断片的なコード例や、別バージョンのindex.phpを正解として上書きしてはいけません。

WordPressのバージョンと設置方式を先に確定する

WordPress本体のバージョンは管理画面、wp-includes/version.php、WP-CLIなど複数の情報で確認します。
コア更新の途中でファイルが混在している場合、単純比較では「不一致」が大量に出るため、更新失敗と侵害を分ける必要があります。

サブディレクトリへWordPress本体を置き、ルートのindex.phpから読み込む構成では、標準と異なる相対パスが正規設定の場合があります。
マルチサイト、静的化、保守用フロントコントローラーなどもあるため、現行構成の管理者へ変更理由を確認してください。

WP-CLIと手動差分を役割分担する

WP-CLIが使える環境では、コアのチェックサム検証が正規配布物との差分確認に役立ちます。
ルートファイルも確認対象に含め、index.php以外のコアファイルが同じ時期に変わっていないかを見ます。

WordPressルートでの読み取り検証例
wp core version
wp core verify-checksums --include-root

チェックサム不一致は重要な警告ですが、侵入経路や実行主体までは教えてくれません。
また、公式配布物に含まれない独自ファイルやwp-content、データベースは別途確認が必要です。

手動比較では、PHP開始タグより前の空白や不可視文字、末尾への追記、外部ファイルの読み込み、条件分岐、難読化文字列を確認します。
不審部分をブラウザで実行したり、オンライン解析サービスへ顧客情報を含む原本をそのまま送ったりしないでください。

感染ファイルを広く探す必要がある場合は、更新時刻だけに頼らず、正規版との差分と参照元を組み合わせます。
基本的な探索順は次の記事で確認できます。

クイックレスキュー

WordPressマルウェア駆除を自分で行う方法｜感染ファイルを見つける基本手順 WordPressマルウェア駆除を自分で進めたい方へ。感染ファイルが見つかりやすい場所、候補の絞り込み方、削除前の判断基準、再発防止の入口対策まで初心者向けに解説します…

WordPressのindex.phpを書き換える実行元を時系列で追う

再発を止める核心は、index.phpの変更時刻と、その前後に動いたリクエストや自動処理を同じ時系列へ並べることです。
不審な文字列を全サーバーから無作為に探すより、数分の時間窓へ絞った方が実行元へ近づきやすくなります。

アクセスログ・PHPログ・ファイル時刻をそろえる

まず、再改ざんを確認した時刻の前後10〜30分を目安に、Webアクセスログ、WAFログ、PHPエラーログ、WordPressデバッグログを確認します。
サーバーと手元の時刻がJSTかUTCかも記録し、時差で別のアクセスを原因と誤認しないようにします。

POSTされたPHP、管理画面のプラグイン・テーマ編集、ファイルアップロード、REST API、XML-RPC、不審なクエリ文字列を探します。
ただし、同時刻のアクセスが見つかっただけでは原因確定ではありません。応答コード、処理時間、対象ユーザー、変更された別ファイルまでつながるかを確認します。

WordPress CronとサーバーCronを分けて確認する

WordPressの予約処理は、通常アクセスをきっかけに動くことがあります。
一方、サーバーのCronはWordPressへアクセスがなくても指定時刻に実行されるため、両者を混同すると「アクセスが原因」と誤認します。

不審なフック名、知らないPHPパス、base64のような長い引数、削除しても戻るイベントを確認します。
サーバー側では、コントロールパネルのCron、ユーザーcrontab、ホスティング独自の定期実行、バックアップやデプロイ機能も対象です。

管理者・FTP・外部連携・同居サイトを確認する

ファイル更新が正規の認証経路から行われていることもあります。
身に覚えのない管理者、Application Password、FTP/SFTPアカウント、ホスティングのサブアカウント、Gitやデプロイキー、バックアップサービスを一覧化します。

パスワード変更は重要ですが、感染端末から変更すると新しい情報も盗まれる可能性があります。
安全を確認した端末から、影響範囲を整理して順番に変更し、既存セッションや不要なキーも失効させます。

wp-config.phpに不審な読み込みや認証情報の露出があると、index.phpだけを直しても復旧できません。
確認すべき場所と秘密情報の扱いは次の記事で整理しています。

クイックレスキュー

WordPressのwp-config.phpが改ざんされた時の確認点｜認証キーとDB情報を守る復旧手順 WordPressのwp-config.phpに不審な変更を見つけ、認証キーやDB情報の漏えいが心配ではありませんか？証拠保全、差分確認、資格情報の交換、周辺侵害の調査、再発防止まで安…

WordPressのindex.php改ざんを安全に止めて復元する

復元は、再投入元の封じ込め、正規ファイルへの置換、サイト動作の確認という順で行います。
先に正規ファイルへ戻すと一時的に表示が直っても、原因が動いた瞬間に同じ状態へ戻ります。

影響を広げる経路を一時的に止める

調査で特定できた不審Cron、不要な管理者、外部公開されたアカウント、実行中のバックドアを、安全な手順で無効化または隔離します。
本番サイトを止める必要がある場合は、保守表示、IP制限、ホスティング会社への相談など、利用者への影響が最小になる方法を選びます。

不審PHPを公開ディレクトリ内で拡張子だけ変更すると、設定によっては実行可能なまま残ることがあります。
原本を保全したうえで公開領域外へ移し、参照していた処理がないかを確認してください。

同じバージョンの公式index.phpへ戻す

再投入元を止めた後、稼働中と同じWordPressバージョンの公式配布物からindex.phpを用意します。
サブディレクトリ構成など正当な変更がある場合は、その差分だけを再適用し、古いバックアップの不審コードを戻さないようにします。

ファイル所有者と権限はホスティング環境の標準へ合わせます。
書き込みを止める目的で極端な権限にすると、更新、キャッシュ、デプロイ、保守機能が壊れるため、原因調査を権限変更だけで置き換えないでください。

キャッシュを分けて表示と原本を確認する

CDN、サーバーキャッシュ、WordPressキャッシュ、ブラウザキャッシュが残ると、原本を直しても古い転送や警告が表示される場合があります。
サーバー上のindex.php、直接アクセス時の応答、CDN経由の応答を分けて確認します。

トップページだけでなく、管理画面、投稿、固定ページ、フォーム、ログイン・ログアウト、スマホ表示も確認してください。
復元直後に正常でも完了とせず、次に予定されているCron実行やアクセスの後まで監視します。

改ざんがファイル以外にも及んでいる場合は、データベースやユーザー、検索結果まで含めた全体復旧が必要です。
初心者向けの全体手順は次の記事も参照してください。

クイックレスキュー

WordPress改ざんの具体例と直し方｜初心者向け復旧手順 WordPress改ざんで困っていませんか？トップページ改ざん、検索結果汚染、リダイレクト、不審コードの具体例と直し方を初心者向けに解説。今すぐ安全に確認しましょう。

WordPressのindex.php復元後に再発を監視する

復元後は「いま正常」と判断した基準時刻とハッシュを残し、同じ方法で再確認します。
監視の目的は通知を増やすことではなく、次に変化した時刻を狭め、どの処理と一致するかを追える状態にすることです。

短期監視と運用監視を分ける

復元直後は、過去に戻った間隔より短い周期でindex.phpのハッシュ、更新時刻、所有者を確認します。
たとえば毎時戻っていたなら、最初の数時間は15〜30分単位で確認し、Cron実行前後をまたいで変化を見ます。

再発が止まった後は、ファイル変更監視、WAF、ログ保管、更新管理、バックアップ検証を通常運用へ組み込みます。
通知が出た時に誰が何分以内に確認するかも決めておくと、次の事故で上書きだけを繰り返さずに済みます。

侵入口を閉じたことを確認する

WordPress本体、テーマ、プラグイン、PHPを互換性確認のうえ更新し、使っていないものは保全・影響確認後に整理します。
管理者、ホスティング、FTP、DB、メール、外部連携の認証情報も、漏えい範囲に応じて見直します。

同じサーバーアカウントに複数サイトがある場合は、全サイトで同じ確認を行います。
一つだけ正常化しても、古いCMSや放置サイトに残るバックドアから書き戻されれば再発するためです。

復元後の認証・バックアップ・監視・検索汚染まで含む確認項目は、次の記事にまとめています。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント WordPressマルウェア駆除後にやることが分からず不安な方へ。再感染を防ぐ設定見直し、管理者・パスワード・uploads制限・バックアップ・監視ポイントまで初心者向けに解説…

WordPressのindex.php調査でやってはいけないこと

急いで表示を戻したい時ほど、証拠を消す操作や影響範囲の大きい操作を避けるべきです。
一時的に直ることと、再発原因を除去できたことは同じではありません。

ウイルス対策やセキュリティスキャンで警告が消えても、すべてのファイル、データベース、Cron、外部アカウントが正常とは限りません。
ツールの結果は重要な材料ですが、未検出を「感染なし」の証明にはしないでください。

復旧中にサイトを全面削除して入れ直す方法も、最新の投稿、注文、問い合わせ、会員情報、正当なカスタマイズを失う危険があります。
原本と正常データを分けて保全し、復元範囲を決めてから実行します。

WordPressのindex.php改ざんでよくある質問

index.phpを公式版へ戻せば直りますか？

表示は一時的に戻る可能性がありますが、書き換え元が残っていれば再発します。原本を保全し、再改ざん時刻とログ・Cron・認証経路を照合して再投入元を止めてから復元してください。

index.phpの更新時刻が新しければ感染ですか？

更新、移行、デプロイ、バックアップ復元でも時刻は変わるため、時刻だけでは断定できません。同じバージョンの公式配布物との差分、変更履歴、実行ログを合わせて判断します。

パーミッションを読み取り専用にすれば再発を止められますか？

一時的な観察に役立つ場合はありますが、更新や保守を壊し、別ファイルへ攻撃が移る可能性もあります。権限変更だけを駆除の代わりにせず、環境標準と実行主体を確認してください。

何度直しても戻る場合はすぐ専門家へ依頼すべきですか？

再書き換えが続く、複数サイトへ広がる、管理者やFTPが不明、顧客情報を扱う、ログを保全できない場合は早めの相談が安全です。上書きを繰り返す前に現在の状態を残してください。

WordPressのindex.php改ざんは再投入元を止めてから復元する

index.phpが何度直しても改ざんされる時は、ファイルの内容だけでなく「誰が、いつ、どの経路で書き戻したか」を調べる必要があります。
上書き前に原本・時刻・権限・ハッシュを保全し、同じバージョンの公式配布物と比較してください。

次に、変更時刻の前後でアクセスログ、PHPログ、WordPress Cron、サーバーCron、管理者、FTP、外部連携、同居サイトを照合します。
再投入元を封じ込めた後に正規ファイルへ戻し、過去の再発間隔を超えるまで監視するのが安全な順番です。

index.php以外にも不審な変更がある場合は、一つずつ個別修正するより、被害範囲を確定して復旧計画を作る方が安全です。
復旧を急ぐほど、証拠を残してから作業を始めてください。

WordPressのindex.php改ざんが自分で止められない時は

index.phpの再改ざん、バックドア、Cron、同居サイトからの再感染でお困りなら、
クイックレスキューが調査から復旧まで対応します。

調査費用・初期費用は0円です。
原因を特定し、再発を防ぐところまでご相談いただけます。