「WordPressのwp-blog-header.phpに見覚えのないコードがあり、削除してよいのか判断できない」と困っていませんか？
トップページは開くのに検索から来た時だけ別サイトへ飛ぶ、スマホだけ広告へ転送される場合、このファイルの実行境界が悪用されている可能性があります。
wp-blog-header.phpは小さなコアファイルですが、WordPressの読み込み後にメインクエリを開始し、表示するテンプレートへ処理を渡す重要な場所です。
ここだけを急いで上書きすると、条件付きリダイレクトや別ファイルからの再投入を追う証拠まで消してしまいます。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、wp-blog-header.phpの正常な役割、不審な分岐の調べ方、安全な復元と表示確認まで順番に解説します。
- wp-blog-header.phpが担当する正常な処理境界
- ガード前・ガード内の不審コードを見分ける基準
- CookieやUser-Agentで変わる転送の再現方法
- 呼び出し元と読み込み先を両方向から追う手順
- 安全な復元とURL・テンプレートの再試験方法
結論は、wp-blog-header.php単体を見て削除を決めず、
同じWordPress版の公式ファイルとの差分、呼び出し元、読み込み先、HTTP応答を一つの時系列で確認することです。
証拠を保全して再投入元を止めた後に公式ファイルへ戻せば、誤削除と再感染の両方を避けやすくなります。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
wp-blog-header.php改ざんの疑いでは正常な処理境界を先に確認する
最初に行うべきことは、wp-blog-header.phpが本来どこから呼ばれ、どこへ処理を渡すかを理解することです。
正常な境界がわからないまま文字列だけを探すと、正規コードを消したり、別の不審箇所を見逃したりします。
WP_USE_THEMESはルートindex.phpで定義される
一般的なWordPressルートのindex.phpは、WP_USE_THEMESをtrueとして定義し、同じ階層のwp-blog-header.phpを読み込みます。WP_USE_THEMESを通常のwp-blog-header.phpが定義するわけではありません。
// ルート index.php の基本的な役割
define( 'WP_USE_THEMES', true );
require __DIR__ . '/wp-blog-header.php';wp_did_headerからテンプレート読込までが確認範囲になる
現在の公式wp-blog-header.phpは、wp_did_headerが未設定なら処理を始め、値をtrueにして二重実行を防ぎます。
続いて__DIR__ . '/wp-load.php'を読み込み、wp()を呼び、
最後にABSPATH . WPINC . '/template-loader.php'を読み込みます。
// 公式構造を確認するための要点
if ( ! isset( $wp_did_header ) ) {
$wp_did_header = true;
require_once __DIR__ . '/wp-load.php';
wp();
require_once ABSPATH . WPINC . '/template-loader.php';
}wp-load.php側では設定とコア初期化へ進み、wp()でリクエスト解析とメインクエリが実行されます。template-loader.phpは、その結果に応じて404、検索、投稿、固定ページなどのテンプレート選択へ進むため、前後の差し込みは全ページへ影響しやすい場所です。
- ルートindex.phpがテーマ利用を指定してwp-blog-header.phpを呼ぶ
- wp_did_headerのガードが同じ処理の重複実行を防ぐ
- wp-load.phpがWordPress環境を読み込む
- wp()がリクエスト解析とメインクエリを開始する
- template-loader.phpが表示テンプレートへ処理を渡す
wp-blog-header.phpを削除せず証拠保全して同じ版と比較する
wp-blog-header.phpに差分があっても、確認前に削除・上書きせず、原本と属性を一組で保全してください。
内容だけでなく更新時刻、所有者、パーミッション、ハッシュ、周辺ログが、侵入経路と再発時刻を結び付ける材料になります。
対象ファイルと周辺情報を公開領域外へ保存する
SFTPやサーバー管理画面で対象ファイルをダウンロードし、編集しない原本として保存します。
ファイルの絶対パス、容量、更新時刻、所有者、グループ、権限を記録し、可能ならSHA-256ハッシュも取得してください。
読み取り確認の例（実際の設置先へ置き換える）
stat /path/to/wordpress/wp-blog-header.php
shasum -a 256 /path/to/wordpress/wp-blog-header.php
cp -p /path/to/wordpress/wp-blog-header.php /safe/path/wp-blog-header.php.suspect保全先はブラウザからアクセスできない場所を選び、不審PHPを公開ディレクトリへ複製しないでください。
アクセスログ、PHPエラーログ、WAFログ、ファイル変更通知、デプロイ履歴も、更新時刻の前後を含めて保存します。
稼働中と同じWordPressバージョンの公式ファイルを使う
比較対象は「最新WordPressのファイル」ではなく、調査対象サイトと同じバージョンの公式配布物です。
版が違えば正規の修正も差分に現れるため、誤検知が増え、必要な更新と不正変更を混同します。
- 同じ版の公式ファイルと一致する行
- 保守会社やデプロイ工程で導入された説明可能な変更
- 由来が不明なrequire・include・eval・文字列復号
- HTTP応答やアクセス条件を直接変更する処理
不審な参照先が見つかっても、文字列や拡張子だけで削除を決めないことが重要です。
危険度、呼び出し関係、更新時刻を整理する考え方は、次の記事も参考になります。
wp-blog-header.php内の不審な読み込みと直接出力を見分ける
差分確認では、ガードの前、ガードの中、wp()の前後、テンプレート読込の直前という位置ごとに意味を分けます。
同じ一行でも実行位置により、全アクセスへ効くのか、初回処理だけか、表示直前だけかが変わるためです。
wp_did_headerの前後に追加された処理を確認する
ガードより前にあるPHPは、ファイルが読み込まれるたびに実行される可能性があります。
外部URLから内容を取得する処理、長いエンコード文字列、可変関数、知らない一時ファイルの読込、エラー抑制付きの実行があれば、由来を確認します。
ガードの条件自体が反転・削除されている、wp_did_headerへ不自然な値を代入して正規処理を飛ばす、正規処理の前に終了する変更も要注意です。
一方、独自アプリとの統合で意図的な調整がある場合は、設計書、Git履歴、担当者の説明と一致するかを確かめます。
wp-load.phpとtemplate-loader.phpのパス変更を確認する
公式構造では、前者は__DIR__基準、後者はABSPATHとWPINCを組み合わせて読み込みます。
親ディレクトリ、隠しディレクトリ、uploads、cache、tmp、ランダム名のPHPへ変更されているなら、正規の起動経路から外れていないか調査が必要です。
読み込み先だけでなく、その先がさらに別ファイルを呼んでいないかも追います。wp-config.phpの改ざんは起動全体へ影響するため、認証キーやDB情報と合わせた確認方法を次の記事で整理しています。
直接出力・ヘッダー送信・条件分岐を探す
wp-blog-header.php内のecho、print、直接のHTML出力、header()、Cookie設定、
強制終了は、公式ファイルとの差分として特に注目します。
テンプレート選択前に出力すると、空白や広告の混入、ヘッダー送信済みエラー、意図しない転送を引き起こせるためです。
HTTP_USER_AGENT、HTTP_REFERER、Cookie、IP、言語、クエリ文字列、パス、ログイン状態を条件にするコードも確認します。
攻撃者は管理者のPCでは正常表示し、スマホ、検索結果からの訪問、初回アクセスだけを別サイトへ送ることがあります。
- 公式にない外部URL・別階層PHP・一時ファイルの読み込み
- wp()より前のHTML・JavaScript・広告コード出力
- Locationヘッダー、Refresh、JavaScriptによる転送
- Cookie・User-Agent・Referer・検索語で変わる分岐
- 正規のtemplate-loader.phpを通らず終了する処理
wp-blog-header.phpの呼び出し元とリダイレクト条件を追跡する
不審コードを見つけたら、ファイル内だけで完結させず「誰が呼んだか」と「どの条件で応答が変わるか」を追います。
呼び出し元とHTTP条件を分けて調べると、index.php再感染の記事とは異なる、表示経路の乗っ取りを特定しやすくなります。
ルートindex.php以外の呼び出し元を検索する
通常はルートindex.phpから呼ばれますが、独自入口、古いコピー、別ディレクトリのWordPress、
テーマやプラグイン、攻撃者が置いたローダーから直接読まれる場合もあります。
サーバー内検索ではファイル名だけでなく、絶対パス、相対パス、変数を組み立てた読込も確認します。
読み取り検索の例（対象ディレクトリを限定する）
rg -n "wp-blog-header\.php|template-loader\.php|wp_did_header" /path/to/site
rg -n "HTTP_USER_AGENT|HTTP_REFERER|Location:|setcookie" /path/to/sitePC・スマホ・検索流入・Cookie有無を同じURLで比べる
条件付き転送は、同じURLへ異なる条件でアクセスして差を取ります。
通常ブラウザ、スマホ相当のUser-Agent、検索結果からのReferer、Cookieなし、ログアウト状態を用意し、
HTTPステータス、Location、Set-Cookie、最終URL、本文先頭を比較します。
転送先をむやみにブラウザで開くと、追跡や追加被害につながる可能性があります。
まずヘッダーとログを読み取りで確認し、調査用端末や隔離環境がない場合は外部URLへ追従しない設定で記録してください。
転送が.htaccessやサーバー設定で先に発生すれば、PHPへ到達せずwp-blog-header.phpは実行されません。
ルートの転送設定が繰り返し戻る場合は、次の記事の確認順も併用します。
アクセスログとPHPログで実行時刻を結び付ける
再現した時刻を秒単位で残し、アクセスログのURL、Referer、User-Agent、応答コード、送信量、転送先と照合します。
同時刻のPHPエラー、WAF検知、ファイル更新、Cron、管理画面ログイン、SFTP接続も並べると、表示条件と書き換え元を分離できます。
管理者のブラウザだけ正常なら「直った」と判断せず、Cookieを消した別端末と検索流入条件で再確認します。
リダイレクト被害全体の確認項目は、次の記事にまとめています。
wp-blog-header.phpは再投入元を止めてから安全に復元する
復元は、公開範囲を必要最小限に抑え、証拠を保存し、書き戻し元を止めた後に実施します。wp-blog-header.phpだけを先に戻しても、バックドア、Cron、侵害された認証情報が残れば同じ変更が再投入されるためです。
影響に応じてメンテナンス・アクセス制限を選ぶ
外部サイトへの転送、フィッシング、マルウェア配布、管理画面の侵害が疑われる場合は、被害拡大を防ぐ公開制限を優先します。
ただし全面削除はせず、注文や問い合わせなど更新データの保全、管理者用アクセス、復旧用の戻し方を決めてから切り替えます。
同じ版の公式ファイルへ完全置換する
由来不明の行だけを手作業で削るより、正常版が確定したコアファイルへ完全置換する方が、見落としを減らせます。
新しい一時名でアップロードし、所有者と権限を環境標準に合わせ、構文を確認してから短時間で切り替えます。
切替前の確認例
php -l /path/to/wordpress/wp-blog-header.php.clean
shasum -a 256 /path/to/wordpress/wp-blog-header.php.clean
切替後に確認する対象
wp-blog-header.php
wp-load.php
wp-config.php
wp-settings.php
wp-includes/template-loader.phpファイル更新中の瞬間に不完全な内容を読ませないよう、利用環境に合う原子的な切替方法を選びます。
共有サーバーでコマンドが使えない場合は、管理画面のバックアップとファイルマネージャーで同じ考え方を再現します。
コア外の書き戻し元と認証経路を同時に閉じる
テーマ、プラグイン、mu-plugins、uploads内PHP、cache、Cron、データベース、同居サイトを確認し、不審処理を隔離します。
WordPress本体だけを再インストールしても、コア外に残るローダーが次のアクセスで書き戻す可能性があります。
管理者、ホスティング、SFTP、SSH、データベース、メール、CDN、外部連携の認証情報も侵害範囲に応じて変更します。
感染の可能性がある端末から変更すると新しい情報も漏れるため、端末を確認した安全な経路を使ってください。
感染ファイルをサイト全体から探す基本手順は、次の記事で確認できます。
- 不審ファイル原本・属性・ログを保全した
- 同じWordPress版の公式ファイルを用意した
- 書き戻し元の候補を隔離または停止した
- 認証情報変更を安全な端末から実施した
- 問題時に戻せるバックアップと手順がある
wp-blog-header.php復元後にURL・テンプレート・転送を再試験する
復元後はトップページが開くだけで完了にせず、メインクエリとテンプレート選択が正しく動く代表ルートを試験します。
このファイルは表示処理の境界にあるため、投稿、固定ページ、検索、404、フィード、リダイレクトを分けて確かめる必要があります。
代表URLでクエリ結果とテンプレートを確認する
トップ、投稿詳細、固定ページ、カテゴリー、検索結果、存在しないURL、フィード、ページ送りを確認します。
各URLでHTTPステータス、最終URL、タイトル、本文、選ばれたテンプレート、ログの警告や致命的エラーを記録してください。
404が200になる、検索結果がトップへ戻る、固定ページだけ別テーマになる場合は、wp()後のクエリ状態やテンプレートローダー周辺に取り残しがないか再確認します。
パーマリンク設定を保存し直す操作は影響を説明できる時だけ行い、先に現在の.htaccessを保全します。
条件を変えて不正リダイレクトが消えたか確認する
復旧前に使ったPC、スマホ、検索Referer、Cookieなし、ログアウト状態を同じ順番で再試験します。
HTTPステータスとLocationだけでなく、JavaScript転送、meta refresh、短時間後の遷移、Set-Cookieの変化も確認してください。
CDN、ブラウザ、ページキャッシュ、サービスワーカーが古い応答を返す場合があります。
オリジン直結と配信URLを分け、キャッシュを消した新規セッションでも同じ結果になることを確かめます。
ハッシュ・時刻・ログを基準に再発を監視する
復元直後のwp-blog-header.phpハッシュ、更新時刻、所有者を基準値として保存します。
過去に再発した間隔より短い周期で確認し、Cron実行、管理者ログイン、外部アクセスの前後に変化がないか見ます。
短期監視を通過した後は、コア整合性、更新管理、WAF、ログ保管、バックアップ復元テストを通常運用へ組み込みます。
復旧後の確認と再感染防止は、次の記事も併せて利用してください。
- 代表URLが期待するHTTPステータスと内容を返す
- 投稿種別に合うテンプレートが選択される
- 条件を変えても不正転送や広告挿入が再現しない
- PHP・WAF・アクセスログに新しい異常がない
- 基準ハッシュと更新属性が監視期間中に変わらない
WordPressのwp-blog-header.php改ざんでよくある質問
wp-blog-header.php改ざんは処理境界と条件付き応答を追って復旧する
wp-blog-header.phpは、WordPress環境を読み込んだ後、メインクエリを開始し、テンプレート選択へ渡す境界です。
ルートindex.phpの再書き換えだけを扱う調査とは分け、ガード前後、読込パス、直接出力、HTTP条件を確認してください。
調査は、原本・属性・ログの保全、同じ版の公式ファイルとの比較、呼び出し元と読み込み先の追跡、条件付き転送の再現という順番で進めます。
再投入元を止めてから公式ファイルへ完全置換し、トップ以外のURL、テンプレート、404、検索、フィードまで再試験することが重要です。
表示が戻っても、コア外のバックドアや侵害された認証情報が残れば再発します。
過去の再発間隔を超えてハッシュとログを監視し、同居サイトを含む復旧後対策まで完了させてください。
wp-blog-header.phpの改ざんと不正リダイレクトが自分で解決できない時は
wp-blog-header.phpの不審コード、条件付き転送、読み込み先の改ざん、再感染でお困りなら、
クイックレスキューが原因調査から安全な復旧まで対応します。
- wp-blog-header.phpの差分が安全か判断できない
- スマホや検索流入だけ別サイトへ転送される
- 公式ファイルへ戻しても不審コードが再発する
- 呼び出し元や読み込み先を自分で追えない
- 証拠とデータを残しながら安全に復旧したい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
