WordPressのセキュリティスキャンで、wp-adminやwp-includesのファイルが
「変更されています」と表示され、どこまで直せばよいか迷っていませんか？
不審なコアファイルを見つけても、いきなり削除や上書きを始めるのは危険です。
正規の更新差分やロケール固有ファイルまで消すと、管理画面や自動更新が壊れることがあります。
反対に、同じ名前のファイルだけを上書きすると、攻撃者が追加した余計なPHPが残り、
見た目だけ直った後に再び改ざんされる可能性があります。
よこやま良平WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、公式チェックサムで改ざんを確認し、コアを安全に復元する順番を解説します。
- WordPress公式チェックサムで確認できる範囲
- WP-CLIでコア改ざんを調べる安全な手順
- 不一致・欠落・余計なファイルの読み分け方
- wp-admin・wp-includesを正規ファイルへ戻す方法
- 復元後に再感染と機能不良を確認するポイント
結論からいうと、安全な順番は「保全→環境確認→チェックサム照合→範囲確定→復元→再照合」です。
チェックサムの成功だけで感染なしとは判断せず、wp-content、データベース、認証情報も別に確認します。
まずは現在の状態を失わないように保存し、読み取り中心の確認から始めましょう。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPressコア改ざんはチェックサム確認から始める
WordPressコア改ざんを疑った時は、目視や更新日時だけでなく、
インストール中の公式版とファイル内容を照合することが重要です。
チェックサムは、ファイルの内容から作る照合用の値です。
公式配布版と現在の値が一致すれば、少なくとも比較対象の内容は同じと判断できます。
更新日時は、サーバー移転、バックアップ復元、自動更新でも変わります。
反対に攻撃者が時刻を偽装することもあるため、日時だけでは改ざんの証拠になりません。
公式チェックサムとの比較なら、文字を1文字追加した変更でも不一致として検出できます。
手作業で数千ファイルを開くより、調査の入口を短時間で絞れます。
- 公式コアファイルと内容が違うファイル
- 本来あるはずなのに欠けているコアファイル
- コア領域へ余計に追加された可能性があるファイル
- 照合したWordPressのバージョンとロケール
ただし、公式チェックサムが確認する中心はWordPress本体です。
テーマ、プラグイン、uploads、データベース、サーバー設定まで安全になるわけではありません。
不審ファイルを探す全体の優先順位は、次の記事で整理しています。
コア照合と並行して、感染が残りやすい場所も確認してください。
WordPressコアのチェックサム確認前に証拠と環境を固定する
チェックサムを実行する前に、現在のファイル、データベース、ログを保全してください。
先に更新や再インストールをすると、侵入時刻や変更元を追う手掛かりが消えます。
感染した状態のバックアップにも調査価値があります。
復元用の安全なバックアップとは分け、日付と取得元を付けて公開領域外へ保存します。
次に、実際のWordPress設置先、コアのバージョン、サイト言語を確認します。
サブディレクトリ設置や複数サイト環境では、別のWordPressを照合しないよう注意が必要です。
wp core version --path=/path/to/wordpress
wp eval 'echo get_locale();' --path=/path/to/wordpress
wp core is-installed --path=/path/to/wordpress/path/to/wordpressは、対象サイトのwp-load.phpがある場所へ置き換えます。
コマンド結果、実行日時、作業者、カレントディレクトリも調査メモへ残してください。
マルチサイトでは、ネットワーク全体でコアを共有します。
一つのサイトだけのつもりでコアを交換しても、同じ本体を使う全サイトへ影響します。
- WordPressファイル一式とデータベース
- アクセスログ・エラーログ・WAFイベント
- 管理者・FTP・SFTP・サーバー利用者の一覧
- コアのバージョン、ロケール、設置パス
- 更新前のチェックサム結果と不審ファイル一覧
公開画面、管理画面、検索結果、スマホ表示も保存しておくと、
復旧後に「どの症状が消えたか」を同じ条件で比較できます。
改ざんの有無をファイル、DB、ユーザー、ログから判断する全体像は、
次のチェック項目も合わせて確認すると見落としを減らせます。
WordPressコア改ざんをWP-CLIのチェックサムで調べる
環境を記録したら、WP-CLIのwp core verify-checksumsを使います。
このコマンドはWordPressを読み込む前に照合するため、感染が疑われる環境でも確認に使えます。
対象のバージョンとロケールは省略せず、先ほど確認した値に合わせます。
別バージョンのチェックサムを指定すると、正常なファイルまで大量に不一致になります。
wp core verify-checksums --version=確認した版 --locale=確認した言語 --include-root --path=/path/to/wordpress--include-rootを付けると、ルート直下の既知ファイルも確認対象に含められます。
ただし、wp-config.phpやサーバー固有ファイルは公式配布物と役割が違うため、出力を一律削除に使ってはいけません。
成功時は、コアがチェックサムを通過した旨が表示されます。
失敗時は、内容不一致、欠落、置くべきでないファイルなどを分けて記録します。
結果は画面だけで見ず、テキストへ保存して作業前後を比較します。
共有する場合は、サーバーパス、利用者名、顧客ドメインなどをマスキングしてください。
- 内容不一致: 正規版との差分を保全してコードと由来を確認
- 欠落: 同じ版の公式パッケージに存在するか確認
- 余計なファイル: 正規機能・保守会社・攻撃者の追加を切り分け
- 多数の不一致: バージョン・ロケール・設置先の指定ミスを再確認
チェックサムにないファイルが、すべてマルウェアとは限りません。
ホスティング会社の管理ファイルや、過去の手動設置物が含まれる場合もあります。
一方、wp-adminやwp-includes内の見覚えのないPHPは、
正規用途が少ないため、内容・更新時刻・アクセスログを優先して調べます。
WordPressコアのチェックサム不一致を正しく判定する
チェックサム不一致が出ても、その場で削除せず、差分の理由を一件ずつ分類します。
調査の目的は「違うファイル」を消すことではなく、変更主体と影響範囲を確定することです。
まず、公式パッケージの同じパスと比較し、追加行、外部通信、難読化、
不審な条件分岐、ユーザー入力を実行する処理がないかを確認します。
次に、サーバーの更新履歴、WordPress自動更新メール、保守会社の作業記録と照合します。
正規更新の途中で失敗すると、新旧ファイルが混在して多数の不一致になることがあります。
マルウェアは正常なコアファイルへ追記されるだけでなく、
公式には存在しないファイルを正規名に似せて追加することがあります。
不審なPHPの危険度を、配置場所、由来、正規版との差分、ログで評価する方法は、
次の記事でも具体的に解説しています。
- 同時刻に複数のコアPHPが変更されている
- 外部URL、eval、難読化、可変関数が追加されている
- ログに不審ファイルへの直接アクセスがある
- 削除後に同じファイルが自動で再作成される
- 未知の管理者、Cron、DB改ざんも同時に見つかる
正規のカスタマイズでコアを直接変更していた場合も、元へ戻すだけで機能が失われます。
差分を保全し、必要な処理を子テーマや独自プラグインへ移す計画を立ててください。
コア直接編集は、更新で消え、次回の改ざん判定も難しくします。
感染調査を機に、公式ファイルを変更しない構成へ戻すことが再発防止につながります。
WordPressコアのチェックサムを使えない環境で比較する
レンタルサーバーのプランや権限によっては、SSHやWP-CLIを使えないことがあります。
その場合も、同じ版・同じロケールの公式パッケージと安全な場所で比較できます。
最初に現在のコアをダウンロードし、原本として読み取り専用で保全します。
作業用コピーと公式パッケージを別フォルダへ展開し、同じ相対パス同士を比較してください。
比較対象は、ファイル名だけでなくサイズと内容です。
バイナリ比較やハッシュ比較を使えば、目視では分からない空白や末尾の追記も検出できます。
公式パッケージ側にないファイルは、一覧へ分けて由来を確認します。
正規版を上書きするだけでは、この「余計なファイル」が残るため特に注意が必要です。
- 現在のファイルとDBを保全して作業用コピーを作る
- 管理画面やversion.phpから版とロケールを記録する
- WordPress公式から一致するZIPを安全な端末へ取得する
- wp-admin・wp-includes・ルートの同一パスを内容比較する
- 変更・欠落・余計なファイルを別々の一覧へ記録する
非常に古い版や特殊なロケールでは、公式チェックサムを取得できない場合があります。
チェックサムがないことは安全の証明ではないため、正規アーカイブとの比較へ切り替えます。
管理画面の「再インストール」ボタンは便利ですが、証拠保全前には使いません。
また、正規ファイルの再配置だけでは、余計なPHPや別領域の感染を削除できません。
比較結果に自信がない場合は、変更を加えず一覧と原本を残してください。
誤って正常ファイルを消すより、調査可能な状態で専門家へ渡す方が復旧を早められます。
wp-admin・wp-includesを公式ファイルで安全に復元する
感染または破損が確認できたら、同名ファイルの上書きだけでなく、wp-adminとwp-includesを公式配布物から丸ごと入れ替えるのが基本です。
上書きだけでは、公式パッケージに存在しない不正ファイルが残ります。
旧ディレクトリを公開領域外へ保全してから、空の位置へ正規ディレクトリを配置します。
作業中は管理画面や公開画面が不完全になるため、メンテナンス表示やアクセス制限を使います。
侵害が進行中なら、業務影響より閲覧者への被害停止を優先してください。
- ファイル・DB・ログとチェックサム結果を保全する
- 同じ版・同じロケールの公式パッケージを別場所へ展開する
- 旧wp-admin・wp-includesを公開領域外へ隔離する
- 公式パッケージのwp-admin・wp-includesを新規配置する
- ルートのコアファイルを選別して正規版へ置き換える
- チェックサム再照合と機能テストを行う
公式パッケージは、感染サイト内ではなく安全な端末または隔離した作業場所で取得します。
出所不明のバックアップや第三者配布ZIPを、正規コアとして使わないでください。
ルート直下のindex.php、wp-load.php、wp-settings.phpなども比較します。
一方、wp-config.php、wp-content、独自設定は一括上書きしません。
.htaccess、.user.ini、サーバー会社の管理ファイルも、
公式コア外だから不要とは限りません。役割と内容を確認し、不審部分だけを復旧します。
WordPress公式の手動更新手順も、古いwp-adminとwp-includesを削除し、
新しいものへ置き換える流れを案内しています。感染対応では削除前の証拠保全を追加してください。
サイト全体の駆除順、正規ファイルへの復元、認証情報変更、公開再開の判断は、
次の完全手順と組み合わせると作業範囲を整理しやすくなります。
WordPressコア復元後もwp-content・DB・設定を確認する
コアが正規状態へ戻っても、感染源が別の場所に残れば再び書き換えられます。
コア復元は駆除の一工程であり、サイト全体の安全確認が終わったわけではありません。
wp-contentでは、テーマ、通常プラグイン、mu-plugins、uploads、
object-cache.phpなどのドロップインを正規配布物や管理記録と比較します。
データベースでは、未知の管理者、投稿・固定ページ、options、Cron、
外部URL、難読化スクリプト、見覚えのないApplication Passwordsを確認します。
ルート設定が何度も戻る場合は、Cron、別サイト、盗まれたSFTP情報、
侵害された管理者、サーバー側タスクが再生成している可能性があります。
特に.htaccessが修正後に戻る場合は、ファイル自体より書き換え元を止める必要があります。
再生成前に確認する場所は、次の記事で詳しく整理しています。
- テーマ・プラグイン・mu-plugins・uploads
- データベースのユーザー・投稿・設定・Cron
- wp-config.php・.htaccess・.user.ini
- FTP・SFTP・サーバー・メール・DNSの認証情報
- 同一アカウント内の別WordPressと古いCMS
WordPress本体、テーマ、プラグイン、PHPは、互換性とバックアップを確認して更新します。
不要な資産は停止だけで残さず、正規利用がないことを確認して整理してください。
管理者、サーバー、SFTP、DB、APIの認証情報は、安全確認済み端末から変更します。
感染端末や漏えいしたメールを使うと、新しい情報も取得されるおそれがあります。
WordPressコア復元後に再照合と動作確認を行う
復元後は、最初と同じ条件でチェックサムを再実行します。
版、ロケール、設置先を変えずに比較し、不一致が解消したことを確認してください。
チェックサムが成功しても、トップページが開くだけでは復旧完了にしません。
管理画面、投稿保存、画像アップロード、フォーム、REST API、Cronも試します。
PCとスマホ、ログイン済みと未ログイン、通常アクセスと検索結果経由を比較します。
攻撃者が条件分岐を使うと、管理者の端末だけ正常に見える場合があります。
アクセスログとエラーログを復元前後で並べ、隔離したファイルへの通信、
未知の外部接続、管理者追加、コアファイルの再生成が止まったかを確認します。
- 公式チェックサムの再照合が成功する
- 公開画面と管理画面の主要機能が正常に動く
- コア領域に余計なファイルが再作成されない
- 不審な管理者・Cron・外部通信が再発しない
- 検索結果・警告・サーバー制限の解除条件を満たす
直後だけでなく、24時間後、72時間後、一週間後にも変更とログを確認します。
定期処理や攻撃者の再アクセスで、時間を置いてから戻るケースがあるためです。
駆除後に確認するユーザー、設定、検索結果、バックアップ、監視の全体像は、
次の記事のチェックリストも活用してください。
WordPress公式も、更新、最小権限、信頼できる配布元、バックアップ、監視を重視しています。
チェックサムだけに頼らず、複数の防御と復旧準備を組み合わせましょう。
ファイルを戻した後は、所有者とパーミッションもサーバー会社の推奨値へ合わせます。
動かないからと一律777へ変更すると、第三者が書き換えやすい状態を作ってしまいます。
動作確認前に、WordPress、サーバー、CDN、ブラウザのキャッシュを整理します。
古いPHPコードやHTMLが残ると、復元失敗とキャッシュ残存を取り違えるためです。
隔離した旧コアは、感染状態へ戻すためのバックアップとして使いません。
調査と保管期限のために封印し、復旧用データとは明確に分けて管理してください。
WordPressコア改ざんとチェックサムのよくある質問
WordPressコア改ざんは保全・照合・復元・再確認で直す
WordPressコア改ざんを疑った時は、ファイルを急いで消さず、
現在の状態を保全してから公式チェックサムと照合してください。
不一致の理由と範囲を確定し、wp-adminとwp-includesは、
同じ版・同じロケールの公式配布物から丸ごと入れ替えるのが安全です。
最後に再照合、主要機能、ログ、再生成を確認し、wp-contentやDB、
認証情報、同居サイトに残る侵入口まで閉じて復旧完了とします。
WordPressコア改ざんと安全な復元を自分で判断できない時は
チェックサム不一致の原因や復元範囲が分からない場合は、
クイックレスキューが証拠保全、感染調査、コア復元、再発防止まで対応します。
- wp-adminやwp-includesの不一致が大量に出ている
- 正規更新とマルウェア改ざんを見分けられない
- 上書きしても不審ファイルが再作成される
- ファイルを消してサイトや証拠を壊すのが不安
- コア以外も含めて感染範囲を調査してほしい
