WordPressのルートにあるwp-load.phpを開いたら、
見覚えのない長いコードや外部ファイルの読み込みがあり、消してよいか迷っていませんか？
このファイルはWordPressの起動初期に使われるため、不審な処理が入ると、
公開画面だけでなく管理画面やCron、REST APIの実行時にも動くおそれがあります。
しかし、怪しい行だけを勢いで削除すると、証拠を失うだけでなく、
正規の読み込みまで壊してサイト全体を停止させる可能性があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、wp-load.phpの不審なコードを安全に確認し、侵入口を残さず復元する順番を解説します。
- wp-load.phpの正常な役割と不審な変更の見分け方
- 上書きや削除の前に保存すべき証拠
- 公式ファイルと前後の読み込みを比較する手順
- 不審なrequire・includeの参照先を追う方法
- 正規ファイルへ戻した後の再感染確認
結論は、wp-load.phpだけをその場で編集せず、
実行を抑えながら原本を保全し、同じWordPress版の公式ファイルと比較することです。
不審な読み込み先、書き換え元、侵害された認証経路を止めてから正規ファイルへ戻します。
「怪しい一行を消して表示が戻った」だけでは、復旧完了にしません。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
wp-load.phpに不審なコードを見つけたら編集前に止める
wp-load.phpに不審なコードを見つけた時の第一歩は、
編集や再インストールより先に、被害拡大を抑えて現在の状態を残すことです。
このファイルは起動経路の上流にあるため、感染していればアクセスのたびに処理される可能性があります。
一方で、正常な行を消すとWordPress自体を読み込めなくなります。
wp-load.phpはWordPressの設置場所と設定をつなぐ
標準的なwp-load.phpは、ABSPATHがまだ定義されていなければ自分の場所から定義し、
同じ設置先のwp-config.phpを探して読み込む役割を持ちます。
環境によっては一つ上のディレクトリにあるwp-config.phpを探す分岐もあります。
つまり、テーマの表示処理や投稿データを大量に持つファイルではありません。
そのため、外部URLへの通信、CookieやUser-Agentによる隠れた分岐、
無関係なPHPの読み込み、長い難読化文字列が追記されていれば、優先して調べる必要があります。
サイトを止める範囲は被害と業務影響で決める
フィッシング、外部転送、マルウェア配布、管理者の不正追加が起きているなら、
利用者を守るため公開停止またはアクセス制限を優先します。
ただし、感染したWordPressのメンテナンス機能だけに依存すると、
その機能を呼ぶ前にwp-load.phpの不審処理が動く場合があります。
サーバー管理画面、WAF、Basic認証、CDNのルールなど、
WordPressより手前で制限できる方法を選び、正規管理者の調査経路だけを残してください。
- サイトへ新しい変更を加える作業を止める
- 不審な転送や配布がある場合はWordPressより手前で公開を制限する
- wp-load.phpと周辺ファイルを編集せずコピーする
- 作業開始時刻と症状を記録する
- バックアップ復元やコア再インストールは証拠保全後に行う
感染ファイルを探す全体の優先順位が分からない場合は、
次の記事で探索範囲を先に整理すると、無関係なファイルの削除を防げます。
wp-load.phpの不審なコードを証拠保全して危険度を判断する
wp-load.phpの危険度は、コードの見た目だけではなく、
正規版との差分、配置場所、更新時刻、読み込み先、実行記録を組み合わせて判断します。
「知らないコードだから感染」「base64があるから即削除」と決めつけず、
第三者が同じ調査を再現できる情報を一組で残してください。
原本・属性・ハッシュを一組で保存する
まず対象ドメインが参照するWordPressの絶対パスを確認し、
wp-load.phpを公開領域外または安全な端末へ読み取り用コピーとして保存します。
更新日時、所有者、グループ、パーミッション、容量も記録します。
同名ファイルが複数あるサーバーでは、ドメインと絶対パスを必ずセットで残してください。
stat /path/to/wordpress/wp-load.php
shasum -a 256 /path/to/wordpress/wp-load.php
cp -p /path/to/wordpress/wp-load.php /safe/path/wp-load.php.suspect-copy共有サーバーでコマンドを使えない場合は、ファイルマネージャーの情報画面とSFTPダウンロードで代用できます。
不審PHPのコピーを、URLから開ける公開フォルダへ置いてはいけません。
高危険度の特徴と単独では断定できない特徴を分ける
高危険度なのは、ファイル先頭や末尾へ追加された未知の読み込み、
外部入力を復号して実行する処理、正規起動と無関係な外部通信などです。
特にeval、可変関数、圧縮・復号の連鎖、ランダム名のPHP、
特定の検索Botや未ログイン利用者だけを狙う条件分岐が組み合わさる場合は注意します。
- 同版の公式wp-load.phpには存在しない追記がある
- 追記が外部URLまたは見覚えのないPHPを読み込む
- 読み込み先に難読化・Webシェル・不正転送の処理がある
- 同時刻に.htaccessや別のコアPHPも変更されている
- アクセスログに不審な直接実行や書き換え直前のPOSTが残る
一方、require_onceやABSPATHという単語があるだけでは感染と断定できません。
これらは正規のWordPress起動でも使われます。差分と参照先が判断の中心です。
発見済みの一つのPHPを隔離・復元・削除のどれに進めるか迷う場合は、
配置場所と由来から判断する基準も確認してください。
wp-load.phpを公式版と比較して読み込み先を確認する
証拠を保全した後は、稼働中と同じWordPress版の公式wp-load.phpを基準に比較します。
インターネット上で見つけた断片や別バージョンを、正解として上書きしてはいけません。
比較の目的は「違う箇所を消すこと」ではなく、
どの変更が正規で、どこから不審な処理が始まるかを確定することです。
版・ロケール・設置先を先に確定する
WordPressの版は管理画面だけでなく、wp-includes/version.phpやWP-CLIでも確認します。
更新途中で新旧ファイルが混在していると、正常な更新失敗と改ざんを取り違えるためです。
サブディレクトリ設置では、公開ルートとWordPress本体の場所が異なることがあります。
複数サイトを同じアカウントで運用している場合も、比較対象の設置先を間違えないでください。
wp core version --path=/path/to/wordpress
wp core verify-checksums --include-root --path=/path/to/wordpressverify-checksumsはコア全体の入口確認に役立ちますが、
出力された差分を自動的な削除リストとして使うものではありません。
ルートにはwp-config.php、サーバー会社の管理ファイル、正規の独自設定など、
公式パッケージと単純一致しないものもあるため、パスごとに役割を確認します。
wp-config.phpからwp-settings.phpへ進む境界を見る
標準の起動では、wp-load.phpがwp-config.phpを見つけ、
wp-config.php側からwp-settings.phpへ処理が進みます。
不審なincludeやrequireが差し込まれていたら、参照先の絶対パスを解決します。
相対パスだけを見て、別ディレクトリの同名ファイルと取り違えないでください。
参照先を開く時はブラウザで実行せず、隔離コピーをテキストとして確認します。
そのファイルがさらに別ファイルを読む場合は、読み込みの連鎖を図にして終点まで追います。
- 対象WordPressの版・ロケール・絶対パスを記録する
- 同じ版の公式配布物を安全な端末へ取得する
- wp-load.phpを行単位とハッシュで比較する
- 追加されたinclude・requireの参照先を絶対パスへ直す
- wp-config.phpとwp-settings.php側にも不審な追記がないか確認する
- 差分ごとに正規変更・更新失敗・不審変更を分類する
公式のコア照合方法は、WP-CLIのチェックサム資料も参照できます。
照合前に感染サイトのバックアップとログを消さないことが重要です。
wp-load.phpから呼ばれる不審ファイルと侵入経路を追跡する
不審な読み込み先が見つかったら、wp-load.phpだけを戻す前に、
そのファイルを置いた経路と同じ処理で変更された範囲を追います。
読み込み先を残したまま入口だけ交換すると、別の起動経路やCronから再び追記されるため、
一時的に表示が直っても根本原因は残ります。
コードの役割と通信先を静的に確認する
隔離コピーで、ファイル作成、任意PHP実行、外部通信、認証回避、
ユーザー追加、リダイレクト、SEOスパム生成などの処理を確認します。
難読化を解除するために感染コードをそのまま実行してはいけません。
安全な隔離環境がない場合は、文字列、関数名、URL、保存先を読み取る範囲に留めます。
外部通信先を確認する際も、管理端末のブラウザから未知のURLへ直接アクセスしないでください。
攻撃者へ調査元を知らせたり、追加ファイルを取得したりする危険があります。
更新時刻の前後をログと操作記録で照合する
wp-load.phpの更新時刻を中心に、アクセスログ、WAF、エラーログ、FTP・SFTP、
管理者ログイン、プラグイン更新、WordPress Cron、サーバーCronを同じ時系列に並べます。
直前のPOST、ファイルアップロード、未知の管理者ログイン、脆弱なプラグインへのアクセスがあれば、
そのセッションや送信元が他のファイルも変更していないか調べます。
一定間隔で戻るならCronや外部自動処理、アクセスの直後に戻るなら、
リクエストごとに動くPHPや常駐バックドアを優先して疑います。
- WordPress管理者とApplication Passwords
- FTP・SFTP・SSH・サーバー管理画面のログイン履歴
- WordPress CronとサーバーCron、予約タスク
- mu-plugins、ドロップイン、通常プラグイン、テーマ
- 同じサーバーアカウント内の別WordPress・古いCMS
- 管理端末、メール、パスワード再設定経路
mu-pluginsは通常のプラグイン画面で目立ちにくく、起動時に読み込まれます。
見覚えのないファイルがある場合は、次の記事の確認順も使ってください。
.htaccessも同じ時刻に戻る場合は、二つのファイルを別々に直さず、
共通の書き換え元を追う必要があります。
wp-load.phpを正規ファイルへ安全に復元する
侵入口と不審な読み込み先を止めた後に、wp-load.phpを同じ版の公式ファイルへ交換します。
安全な復元は「怪しい行の削除」ではなく、出所が確認できる完全な正規ファイルへの置換です。
ただし、交換前に証拠保全、バックアップ、設置方式、書き込み権限を確認し、
失敗時に元へ戻す手段を用意してください。
作業中はWordPressより手前でアクセスを制限する
交換の瞬間にリクエストが入ると、読み込み途中のファイルを実行して500エラーになる場合があります。
CDN、Webサーバー、サーバー管理画面などで短時間アクセスを制限します。
感染状態のバックアップは調査用として封印し、復元用の安全なバックアップと混ぜません。
元へ戻せることと、感染状態へ戻してよいことは別です。
同じ版の公式wp-load.phpを原子的に入れ替える
安全な端末でWordPress公式パッケージを取得し、版とファイルのハッシュを確認します。
感染サイト内でダウンロードした出所不明のZIPや、第三者配布ファイルは使いません。
新しいファイルを一時名で配置し、所有者とパーミッションを確認してから、
短時間で正規名へ切り替えると中途半端な書き込みを避けやすくなります。
cp -p wp-load.php wp-load.php.suspect-preserved
cp /safe/official-wordpress/wp-load.php wp-load.php.clean-new
php -l wp-load.php.clean-new
mv wp-load.php.clean-new wp-load.php上の例は設置先、利用者、サーバー仕様に合わせて変更します。
共有サーバーでは、ファイルマネージャーのバックアップ・名称変更・アップロード機能で同じ順番を再現できます。
PHP構文確認が成功しても、安全性の証明にはなりません。
構文エラーがないことを確認したうえで、公式版とのハッシュ一致と不要な読み込みが消えたことを再確認します。
- wp-load.phpが同版の公式ファイルと一致する
- 所有者・グループ・パーミッションがサーバー推奨値である
- 公開画面と管理画面がPHPエラーなく開く
- ログイン、投稿保存、画像表示、フォーム、REST APIが動く
- エラーログに新しいfatal errorや未知ファイルの読み込みがない
- 不審な外部転送・ユーザー追加・ファイル再生成が止まっている
サイト全体の駆除、認証情報変更、公開再開までの順番は、
次の完全手順と組み合わせると作業漏れを減らせます。
wp-load.php復元後に再感染と取り残しを確認する
wp-load.phpが正規状態へ戻っても、別のバックドアや盗まれた認証情報が残れば再感染します。
復元後はコア全体、wp-content、データベース、設定、同居サイトを横断して確認します。
確認の目的は「今表示できる」ことではなく、
不審な処理が再実行されず、正規機能を壊していない状態を継続的に証明することです。
コア外と認証経路を同時に確認する
テーマ、プラグイン、mu-plugins、uploads、キャッシュ、ドロップインを正規配布物と比較します。
データベースでは未知の管理者、投稿、options、Cron、外部URL、Application Passwordsを確認します。
wp-config.php、.htaccess、.user.ini、サーバーCronも確認し、
wp-load.phpへ不審コードを戻せる経路が残っていないか調べます。
管理者、サーバー、SFTP、DB、メール、CDN、APIの認証情報は、
安全確認済みの端末から変更し、既存セッションと不要な鍵を失効させます。
WordPressのソルトを更新すると既存ログインセッションを無効化できますが、
作業者自身もログアウトするため、正規管理者の再ログイン手段を先に確認してください。
時間を分けてファイルとログを再確認する
復元直後だけでなく、24時間後、72時間後、一週間後にも、
wp-load.phpのハッシュ、更新時刻、周辺ファイル、アクセスログを確認します。
定時に動くCron、バックアップ処理、攻撃者の再訪問によって、
数時間から数日後に不審コードが戻るケースがあるためです。
- wp-load.phpと公式ファイルの一致が継続している
- コア全体のチェックサムと追加ファイル調査が完了した
- wp-content・DB・設定・同居サイトの不審物を確認した
- 侵害された認証情報とセッションを失効した
- PC・スマホ、ログイン有無、検索経由で不審挙動がない
- ログ監視期間中に再書き換えや未知の通信がない
駆除後に確認する設定、検索結果、バックアップ、監視の全体像は、
次の記事のチェックリストも活用してください。
何度も戻る場合は、まだ書き換え元が残っています。
同じ復元操作を繰り返さず、再発した正確な時刻を新しい手掛かりとして調査範囲を絞ってください。
wp-load.phpの不審なコードと復元のよくある質問
wp-load.phpの不審なコードは保全・比較・追跡・復元の順で対処する
wp-load.phpに不審なコードを見つけても、最初に行うのは削除ではありません。
アクセスを安全に制限し、原本、属性、ハッシュ、症状、時刻を保存します。
次に、同じWordPress版の公式ファイルと比較し、
追加された読み込み先を絶対パスで追って、ログと操作記録から書き換え元を特定します。
侵入口を止めた後に正規ファイルへ交換し、コア外、DB、認証、同居サイトを確認します。
直後から一週間まで監視し、再書き換えがないことを確認して復旧完了としてください。
wp-load.phpの改ざんと安全な復元を自分で判断できない時は
wp-load.phpの差分、読み込み先、侵入口、復元範囲を自分で判断できない場合は、
クイックレスキューが証拠保全、感染調査、復元、再発防止まで対応します。
- wp-load.phpのどの行が不審か判断できない
- 怪しいrequire先が複数あり影響範囲が分からない
- 正規ファイルへ戻しても再び書き換えられる
- 上書きでサイトや証拠を壊すのが不安
- 同居サイトや認証情報までまとめて調査してほしい
