WordPressのwp-settings.phpを開いたら、公式版にない読み込みや長い難読化コードがあり、
どこまで消してよいのか分からず困っていませんか？
wp-settings.phpは、WordPress本体、プラグイン、テーマへ処理を受け渡す起動の中枢です。
改ざんされると、公開画面だけでなく管理画面、REST API、Cronでも不審処理が動くおそれがあります。
一方で、行数が多く読み込み順も複雑なため、知らないrequireを一つ見つけただけでは感染と断定できません。
先に証拠を残し、同じ版の公式ファイルと比較して、追加された処理の入口と出口を追う必要があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、wp-settings.phpの改ざんを安全に確認し、不審な読み込み元を残さず復元する順番を解説します。
- wp-settings.phpが担う起動処理と正常な読み込み範囲
- 削除や上書きの前に保全するファイル・属性・ログ
- 同じWordPress版の公式ファイルと比較する手順
- 不審なrequire・includeから実行元と参照先を追う方法
- 安全な復元と公開再開を判断する確認項目
結論は、wp-settings.phpをその場で部分編集せず、
原本・属性・ハッシュを保全してから同版の公式ファイルへ完全置換することです。
ただし、置換は最後です。先に不審な読み込み先、wp-settings.phpを書き戻す処理、
侵害された認証情報を止めなければ、正規ファイルへ戻しても再び改ざんされます。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
wp-settings.phpが改ざんされた疑いでは最初に実行を抑える
wp-settings.phpに不審な処理を見つけた時は、削除より先に被害の拡大を抑えます。
起動途中で読み込まれるため、調査中のアクセスでもコードが実行される可能性があるからです。
外部転送、偽ログイン、マルウェア配布、不正な管理者追加が進行中なら、
サーバー、CDN、WAF、Basic認証などWordPressより手前で公開を制限してください。
管理画面のメンテナンス機能だけに頼らない
WordPressのメンテナンス表示は、wp-settings.phpの処理を通った後で出る場合があります。
改ざん箇所がそれより前なら、メンテナンス中でも不審コードが動きます。
正規管理者の調査経路を残しながら、一般利用者とBotの到達を抑えるのが基本です。
共有サーバーでは、サーバー会社のアクセス制限や公開フォルダ切り替えも検討します。
自動更新と通常の編集作業を止めて時刻を固定する
調査開始後にコア更新、プラグイン更新、キャッシュ削除、バックアップ復元を行うと、
変更時刻が増えて侵入時の痕跡と正規操作を分けにくくなります。
担当者へ変更停止を連絡し、症状を確認した時刻、URL、端末、ログイン状態、
検索経由か直接アクセスかを記録します。画面録画やレスポンス保存も判断材料になります。
- 不審挙動がある場合はWordPressより手前で公開を制限する
- 更新・復元・ファイル編集を一時停止する
- 症状、発見時刻、対象URL、確認条件を記録する
- wp-settings.phpと関連ログを読み取り用に保存する
- 正規管理者の連絡経路と復旧作業者を一本化する
感染ファイルを探す全体の優先順位は、次の記事で確認できます。
wp-settings.phpだけに範囲を限定せず、同時に変更された場所を見落とさないでください。
wp-settings.phpの原本と属性を削除前に証拠保全する
改ざんの判断はコードの見た目だけでなく、ファイル内容、属性、更新時刻、ログを組み合わせて行います。
そのため、怪しい行をコメントアウトする前に、現在のwp-settings.phpをそのまま保存します。
絶対パス・ハッシュ・所有者を一組で残す
同じサーバーに複数のWordPressがあると、wp-settings.phpも複数存在します。
対象ドメイン、ドキュメントルート、WordPressの絶対パスをセットで記録してください。
ファイルのSHA-256、容量、更新日時、所有者、グループ、パーミッションを記録します。
コピーは公開領域外か安全な端末へ置き、URLから実行できる場所には残しません。
stat /path/to/wordpress/wp-settings.php
shasum -a 256 /path/to/wordpress/wp-settings.php
cp -p /path/to/wordpress/wp-settings.php /safe/evidence/wp-settings.php.suspectSFTPしか使えない場合は、ファイルをダウンロードし、サーバー画面の属性情報と取得時刻を保存します。
前後の起動ファイルとログも同じ時点で保存する
wp-settings.phpは単独で始まるファイルではありません。通常はwp-load.php、wp-config.phpを経由し、
wp-includes内の主要ファイル、mu-plugins、通常プラグイン、テーマへ処理が進みます。
wp-load.php、wp-config.php、default-constants.php、plugin.php、class-wp-hook.phpなど、
差分や読み込み元を確認するための周辺ファイルも同時点で保存します。
アクセスログ、PHPエラーログ、WAF、FTP・SFTP、管理者ログイン、Cronの記録は、
保存期間が短いことがあります。ファイル調査より先に退避が必要な環境もあります。
- 対象ドメインとWordPressの絶対パス
- wp-settings.php原本・SHA-256・属性
- wp-load.php・wp-config.phpと主要な参照先
- アクセス・PHP・WAF・認証・Cronログ
- 発見前後に行った更新・移行・復元の履歴
一つの不審PHPを隔離、復元、削除のどれに進めるか迷う場合は、
配置場所と由来を基準にした次の判断方法も使えます。
wp-settings.phpを同じWordPress版の公式ファイルと比較する
証拠を保存したら、稼働中と同じWordPress版の公式wp-settings.phpを取得して比較します。
別バージョンのファイルでは読み込み順が異なり、正規差分を改ざんと誤判定します。
版・ロケール・更新途中の混在を確認する
管理画面の表示だけでなく、wp-includes/version.php、WP-CLI、更新ログから版を確認します。
更新失敗で新旧ファイルが混在しているなら、感染調査と更新復旧を分けて考えます。
公式配布元から対象版を安全な端末へ取得し、ZIPの展開先と本番を混ぜません。
検索で見つけたコード断片や第三者配布のファイルを正解として使うのは危険です。
wp core version --path=/path/to/wordpress
wp core verify-checksums --include-root --path=/path/to/wordpress
diff -u /safe/official/wp-settings.php /safe/evidence/wp-settings.php.suspectチェックサムはコア全体の入口確認に便利ですが、結果を自動削除リストとして扱ってはいけません。
wp-config.php、wp-content、サーバー固有ファイルは別の基準で確認します。
差分を追加・削除・置換・位置変更に分ける
差分は、公式版にない追加、公式行の削除、値の置換、読み込み位置の変更に分けます。
同じコードでも実行位置が前へ移されると、認証やフィルターより先に動く場合があります。
ファイル先頭や末尾への追記だけでなく、既存のrequire列の間へ挿入された一行も確認します。
空白を除外した比較と、行番号を含む比較の両方を残してください。
- 同版の公式wp-settings.phpに存在しないrequire・includeがある
- 外部入力を復号してPHPとして実行する処理が加わっている
- 外部URLへの通信や未知の一時ファイル生成がある
- 特定Bot・Cookie・User-Agentだけで動く分岐がある
- 差分の参照先にWebシェル、不正転送、ユーザー追加処理がある
require、WPINC、ABSPATHが多いこと自体は異常ではありません。
正規版との差分、参照先、導入履歴、ログが一致した時に危険度を上げます。
wp-settings.phpの不審な読み込みを起動順に追跡する
wp-settings.php固有の調査価値は、WordPressのどの段階で不審処理が入ったかを絞れる点です。
追加行だけでなく、その直前までに利用可能な関数・定数と、直後に読み込まれる機能を確認します。
初期化・エラー設定・主要クラスの前後を確認する
起動前半では、定数、エラー処理、フィルター、オブジェクトキャッシュ、データベースなどが準備されます。
不審処理がこの段階に入ると、通常のプラグイン監視より前に実行される可能性があります。
追加コードが$wpdb、HTTP API、フック機構を使っているなら、
その時点で必要な正規ファイルが読み込まれているかを見ると、実行可能性を判断できます。
未定義の関数でも、別ファイルが先に読み込まれていれば動くため、呼び出し元と依存関係を確認します。
mu-plugins・通常プラグイン・テーマの境界を分ける
mu-plugins、ネットワーク有効プラグイン、通常プラグイン、テーマは同時に読み込まれるわけではありません。
不審コードの位置がどの境界より前か後かで、再生成元の候補が変わります。
たとえば通常プラグインより前に不審なPHPが読み込まれるなら、
管理画面でセキュリティプラグインを停止しても、その不審処理には届かない可能性があります。
逆に、追加行が特定プラグインのファイルを読む場合は、そのプラグインの正規配布物、更新履歴、
autoload設定、mu-plugins側のローダーを確認し、正規連携か偽装かを判断します。
mu-pluginsの安全な隔離と業務影響の確認は、次の記事で手順を分けています。
参照先から書き戻し元まで逆向きにも追う
不審なrequire先を見つけたら、そのファイルが何をするかだけでなく、
誰が作成し、誰がwp-settings.phpへ読み込み行を書いたかを逆向きに追います。
ファイル名、特徴的な文字列、保存先、ハッシュを、アクセスログ、Cron、テーマ、プラグイン、
同居サイトから検索します。感染コード自体を本番で実行して解析してはいけません。
- 起点となるwp-settings.phpの行番号と前後の正規処理
- require・include先を絶対パスへ解決した結果
- 参照先がさらに読むファイルと外部通信先
- ファイルを生成・更新するCron、リクエスト、アカウント
- 同じ特徴がある別サイト・テーマ・プラグイン
wp-settings.phpの書き換え元と侵入経路を止める
不審な読み込みを特定しても、wp-settings.phpだけを戻してはいけません。
書き換え元が残れば、次のアクセス、Cron、外部ログインで同じ差分が再作成されます。
更新時刻を中心に複数ログを時系列で並べる
wp-settings.phpの更新時刻を基準に、直前のPOST、管理者ログイン、SFTP接続、
プラグイン更新、Cron、同居サイトへのアクセスを同じタイムゾーンへ揃えて並べます。
ファイル時刻は移行や攻撃者の操作で変えられるため、単独では断定材料になりません。
アクセスログのレスポンス、作成された別ファイル、DB変更時刻と一致するかを確認します。
再発間隔から常駐処理と外部侵入を分ける
正規ファイルへ戻した直後や一定間隔で再発するなら、Cron、常駐バックドア、
外部監視を装った処理、別サイトからの書き戻しを優先して調べます。
特定のURLへのアクセス直後だけ再発するなら、脆弱なプラグイン、アップロードされたPHP、
盗まれたApplication Password、管理者セッションなどリクエスト経路を疑います。
.htaccessも同じ時刻に戻る場合は、個別ファイルの問題ではなく共通の再生成元がある可能性があります。
次の記事の時刻照合と再生成元の確認も組み合わせてください。
- WordPress管理者・Application Passwords・有効セッション
- FTP・SFTP・SSH・サーバー管理画面
- WordPress Cron・サーバーCron・自動化タスク
- テーマ・通常プラグイン・mu-plugins・ドロップイン
- uploads・cache・tmpなど書き込み可能な場所
- 同一アカウントの別WordPress・古いCMS・管理端末
認証情報を変更する時は、安全確認済みの端末とメールを使います。
感染端末や侵害されたメールから変更すると、新しいパスワードも取得されるおそれがあります。
wp-settings.phpを公式ファイルへ安全に復元する
侵入口と再生成元を止めた後に、wp-settings.phpを同じ版の公式ファイルへ完全置換します。
怪しい行だけを削るより、出所が確認できる正規ファイルへ戻す方が取り残しを防げます。
置換前にロールバックとアクセス制限を準備する
交換中にリクエストが入ると、読み込み途中のファイルで500エラーになる場合があります。
WordPressより手前で短時間アクセスを制限し、元ファイルを証拠用として別名・別場所へ保全します。
感染状態のバックアップは調査用であり、そのまま本番へ戻す復元元ではありません。
安全なバックアップ、公式ファイル、疑わしい原本を明確に分けます。
一時名で配置して構文確認後に切り替える
正規ファイルを一時名で配置し、所有者、グループ、パーミッションをサーバー仕様へ合わせます。
PHP構文確認後に正規名へ切り替えると、中途半端なアップロードを避けやすくなります。
cp -p wp-settings.php /safe/evidence/wp-settings.php.before-replace
cp /safe/official/wp-settings.php wp-settings.php.clean-new
php -l wp-settings.php.clean-new
mv wp-settings.php.clean-new wp-settings.php構文エラーがないことは安全性の証明ではありません。
置換後に公式版とのハッシュ一致、所有者、パーミッション、不審な追加行がないことを再確認します。
コア全体にも差分がある場合は、一ファイルずつ場当たり的に戻さず、
版、ロケール、独自変更を確認したうえで正規コアへ復元してください。
- 公開画面と管理画面がPHPエラーなく開く
- ログイン、投稿保存、画像表示、フォームが動く
- REST API、Ajax、Cron、メール送信が必要範囲で動く
- プラグインとテーマの主要機能に回帰不良がない
- PHPエラーログに未知ファイルの読み込みがない
- wp-settings.phpのハッシュと更新時刻が維持される
サイト全体の感染確認、認証変更、公開再開までの順番は、
次の復旧手順と組み合わせると工程漏れを防げます。
wp-settings.php復元後は再感染と取り残しを監視する
wp-settings.phpが公式版と一致しても、別のバックドアや侵害された認証情報が残れば復旧完了ではありません。
コア外、データベース、設定、同居サイトを横断して確認します。
コア外とデータベースを別の方法で確認する
テーマ、プラグイン、mu-plugins、uploads、cache、ドロップインは、
配布元、管理記録、ファイル種別、更新時刻を基準に確認します。
データベースでは、未知の管理者、Application Passwords、options、Cron、投稿、
外部URL、難読化スクリプトを調べます。コアのチェックサムだけでは確認できません。
wp-config.php、.user.ini、サーバーCron、CDN Workers、同居サイトも確認し、
wp-settings.phpへ変更を戻せる経路を閉じてください。
直後・24時間後・72時間後・一週間後に再照合する
復元直後に正常でも、定期処理や攻撃者の再訪問で数時間後に再発する場合があります。
同じコマンドと同じ絶対パスでハッシュ、更新時刻、ログを再確認します。
PCとスマホ、ログイン済みと未ログイン、直接アクセスと検索経由も比較します。
条件分岐型のマルウェアは、管理者の確認時だけ正常に見せることがあるためです。
- wp-settings.phpと同版公式ファイルの一致が継続している
- 不審な読み込み先と書き換え元を隔離・停止した
- コア外・DB・設定・同居サイトの確認が終わった
- 侵害された認証情報とセッションを失効した
- 主要機能とPC・スマホ表示が正常である
- 監視期間中に再変更・未知の通信・不正ログインがない
駆除後に確認するユーザー、設定、検索結果、バックアップ、監視項目は、
次の記事のチェックリストも活用してください。
再発した場合は置換を繰り返さず、再発時刻と直前のリクエスト、Cron、ログインを照合します。
wp-settings.php改ざんと不審な読み込みのよくある質問
wp-settings.phpの改ざんは保全・比較・追跡・復元・監視で対処する
wp-settings.phpに不審なコードを見つけても、最初に行うのは削除ではありません。
実行を抑え、原本、属性、ハッシュ、周辺ファイル、ログ、症状を同じ時点で保存します。
次に同じWordPress版の公式ファイルと比較し、差分の位置から起動段階を確認します。
参照先を絶対パスで追い、ログと更新時刻から書き換え元と侵入経路を止めてください。
その後に公式ファイルへ完全置換し、主要機能、コア外、DB、認証、同居サイトを確認します。
直後から一週間まで再照合し、不審な変更が戻らないことを確認して復旧完了とします。
wp-settings.phpの改ざんと復元を自分で判断できない時は
wp-settings.phpの差分、読み込み順、参照先、書き換え元、復元範囲を判断できない場合は、
クイックレスキューが証拠保全、感染調査、正規復元、再発防止まで対応します。
- wp-settings.phpのどの差分が不審か判断できない
- 追加されたrequire先が複数あり影響範囲が分からない
- 正規ファイルへ戻しても再び書き換えられる
- 上書きでサイトや証拠を壊すのが不安
- 同居サイトや認証情報までまとめて調査してほしい
