不正アクセス後にWordPressのSALTキーを変更する理由と安全な手順

WordPressが不正アクセスされた後は、管理者パスワードの変更だけで安心してはいけません。
攻撃者が盗んだログインCookieを持っている場合、SALTキーと認証キーを更新し、既存セッションを無効化する必要があります。

ただし、SALTキーだけを先に変えても、バックドアや漏えいした管理メールが残っていれば再侵入されます。
証拠保存と侵入口の封鎖を進め、安全な端末からwp-config.phpを更新し、全ユーザーの再ログインまで確認することが正解です。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。SALT変更は短い作業ですが、順番を誤るとログインループや復旧担当者の締め出しにつながります。

この記事ではWordPress標準の8つの認証用定数をまとめてSALTキーと呼びます。
厳密にはKEYとSALTは別の定数ですが、復旧時は一部だけでなく8行を一組として交換するのが安全です。

作業前に現在のwp-config.phpを複製し、変更時刻と担当者を記録してください。
不正操作が続いている場合は、この記事の手順より先にアクセス制限などの封じ込めを優先します。

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

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

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

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

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

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

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

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

WordPressのSALTキーを不正アクセス後に変更する理由

SALT変更は盗まれたログインCookieを無効化する

SALTキーを変える最大の理由は、発行済みのログインCookieを一斉に無効化するためです。
攻撃者のブラウザーに有効なCookieが残ると、パスワード変更後も認証済み状態が続く恐れがあります。

WordPressはCookieの内容が改ざんされていないか、認証キーとSALTから作った値で検証します。
サーバー側の値を交換すると古い値で署名されたCookieは一致せず、正規ユーザーを含む既存セッションが切れます。

nonceも認証情報と時刻に基づいて検証されるため、管理画面で開いたままの編集画面は保存に失敗することがあります。
作業担当者は編集中の内容を保存し、更新後に新しい画面から操作をやり直してください。

SALTキーはユーザーパスワードではない

SALTを更新しても、WordPressユーザーのパスワードや投稿が書き換わるわけではありません。
ホスティング、SFTP、SSH、データベース、管理メール、CDNの認証情報も変わらないため、別々に漏えい範囲を判断します。

SALTを変えたから侵入者のパスワードも消えた、と考えるのは危険です。
不審な管理者、Application Passwords、APIトークン、二段階認証の復旧コードも個別に棚卸ししてください。

SALT変更は感染ファイルの削除にもなりません。
バックドアが残れば攻撃者は新しいCookieを取得できるため、セッション失効と侵入経路の除去を同じ復旧計画で進めます。

変更対象はKEYとSALTの合計8行

wp-config.phpにはAUTH_KEY、SECURE_AUTH_KEY、LOGGED_IN_KEY、NONCE_KEYと、対応する4つのSALTがあります。
一部だけを更新すると古い値を見落としやすいため、8行すべてを新しい一意な値へ交換します。

同じ値を別サイトで使い回すと、一つのサイトから秘密が漏れた時に影響が広がります。
本番、開発、ステージング、別ドメインは、それぞれ異なる8行を使ってください。

公式のSecret-key Serviceが返す値は長く、記号も含みます。
人が覚える必要はないため短く加工せず、生成されたdefine行を一組のまま安全に扱います。

AUTH_KEY / SECURE_AUTH_KEY / LOGGED_IN_KEY / NONCE_KEY
AUTH_SALT / SECURE_AUTH_SALT / LOGGED_IN_SALT / NONCE_SALT
※実際の値は安全な端末で新規生成し、この例を使わない

WordPress乗っ取り判定｜管理者アカウントと権限を確認する方法

不正アクセス後のSALTキー変更前に確認すること

証拠と現在の設定を先に保存する

SALTは侵入経路とバックドアを確認せず最初の一手として変更しないでください。
先に変えても、改ざんPHPや盗まれた管理メールから新しいセッションを作られる可能性があります。

ただし不正操作が進行中なら、完全な調査を待たずセッション失効を優先する判断も必要です。
ログ、画面、対象ユーザー、変更時刻を最低限保存し、封じ込めとSALT変更を続けます。

変更前のwp-config.phpはWeb公開領域外へ複製し、更新日時、所有者、権限、SHA-256、取得時刻を記録します。
後から改ざんの有無と作業差分を説明できる状態を作ってください。

秘密を含むwp-config.phpを安全に保管する

wp-config.phpのバックアップをチケットやチャットへ貼ってはいけません。
SALTだけでなくデータベース接続情報も含むため、共有範囲を限定し、保管期限を決めます。

公開ディレクトリへwp-config.php.bakやwp-config-old.phpとして残す方法も危険です。
Webサーバー設定の変化でダウンロードされる事故を避けるため、公開領域外へ置いてください。

証拠用原本は読み取り専用で保管し、実際の編集は複製した作業用ファイルで行います。
原本と変更後ファイルのハッシュを残せば、どの作業で差分が生じたか追跡できます。

安全な管理経路と戻し手段を確保する

作業端末が感染していないか確認し、信頼できる回線とSFTPまたはホスティングのファイル管理を使います。
WordPress管理画面だけに依存すると、構文エラーや全ログアウト後にwp-config.phpを戻せません。

管理メールへアクセスできること、別の担当者へ連絡できること、SFTP接続が通ること、直前ファイルへ戻せることを確認します。
会員サイトでは全ログアウトの告知と問い合わせ窓口も準備してください。

不審な管理者、uploads内PHP、mu-plugins、テーマ、wp-cron、外部Webhookも並行して調べます。
正規ファイルとの比較とアクセスログを使い、SALT変更後に再侵入される経路を探します。

WordPressハッキング発覚直後の初期対応チェックリスト

WordPressのSALTキーを安全に変更する手順

安全な方法は、公式のランダム値を安全な端末で取得し、wp-config.php内の既存8定数を丸ごと置き換えることです。
行を追加せず、同名defineが重複しないよう現在の8行を特定して交換します。

1. 作業開始時刻を記録し、wp-config.phpの複製とSHA-256を保存する
2. SFTPまたはファイル管理で対象サーバーを確認する
3. 安全な端末からWordPress.org公式Secret-key Serviceで新しい8行を生成する
4. wp-config.php内の既存KEY・SALT 8行だけを置き換える
5. 半角引用符、括弧、セミコロン、同名定数の重複を確認する
6. 反映後にフロント画面とwp-adminのHTTP応答を確認する
7. 別ブラウザーで旧セッション失効と新規ログインを確認する
8. 変更後ファイルのハッシュと結果を記録し、秘密値自体は転記しない

公式生成サービスの8行を一組で使う

公式Secret-key Serviceはアクセスするたびに異なるランダム値を返します。
値を自作したり、検索結果や他サイトのwp-config.phpから流用したりせず、対象サイトごとに新しく生成してください。

生成結果は秘密情報として扱い、スクリーンショット、シェル履歴、共同編集メモ、Gitへ残さないようにします。
漏れた可能性がある値は再利用せず、もう一度新しい8行を生成します。

パスワード管理ツールへ保管する場合も、サイト名、環境、更新日を明確にし、閲覧権限を必要な担当者へ限定します。
作業報告には値そのものではなく、更新済みという結果だけを書きます。

wp-config.phpの既存8行だけを置き換える

対象行は通常Authentication Unique Keys and Saltsのコメント付近にあります。
末尾へ新しいdefineを追加すると古い定数が先に読まれるため、必ず既存行を置換します。

スマートクォートや全角記号へ変換する文書アプリは使わず、プレーンテキスト対応エディターで編集します。
値には記号が含まれるため、途中だけを加工せず生成された行を崩さず扱います。

AUTH_KEYからNONCE_SALTまで各定数が一度だけ存在するか検索します。
wp-config.phpのPHP開始タグや「編集が必要なのはここまで」の位置を変えず、対象8行以外へ不要な差分を作らないことも重要です。

反映直後にエラーとログアウトを確認する

保存後はトップページ、ログイン画面、管理画面のHTTP応答を確認します。
500エラーやParse errorなら、引用符、括弧、セミコロン、文字コード、同名defineの重複を調べます。

以前からログイン中だった別ブラウザーで管理画面を開き、ログイン画面へ戻されることを確認します。
次に安全な端末から新しいセッションでログインし、直後に再びログアウトするループがないか見ます。

変更作業中に開いていた投稿編集画面はnonceが古くなり、保存に失敗することがあります。
新しいログイン後に画面を再読込し、未保存内容を失わないようローカルへ控えてから操作してください。

WordPressのユーザー権限を間違えると危険？管理者・編集者・投稿者の違い

SALTキー変更後に全セッション失効を確認する方法

旧ブラウザーと複数権限で再ログインを試す

完了条件はファイルを保存できたことではありません。
旧Cookieが無効になり、正規ユーザーが新しくログインでき、主要機能が正常に動くことまで確認して完了です。

管理者だけでなく編集者、投稿者、会員など実際に利用する権限でログインを確認します。
ログイン状態保存、会員ページ、パスワード保護記事、コメント、フォームもテスト対象です。

旧Cookieが残るブラウザーでwp-adminへ入れないこと、新しいログイン後は遷移できること、ログアウトも成功することを記録します。
シークレットウィンドウでも試し、キャッシュの影響を分けます。

REST API・XML-RPC・外部連携を確認する

通常のSALT変更はApplication Passwordsそのものを自動失効する手段ではありません。
外部投稿、バックアップ、監視、モバイルアプリ、REST API、XML-RPCの認証情報は別に棚卸しします。

外部連携が止まった場合、SALTを元へ戻す前に認証方式を確認してください。
Cookieとnonceを使う連携は再ログインが必要ですが、Application Passwordsなら別原因の可能性があります。

不要なApplication PasswordsやAPIトークンは証拠保存後に失効し、必要な連携だけを最小権限の専用ユーザーで再設定します。
一つの認証情報を複数サービスで共有しない運用へ改めます。

アクセスログと監査ログで再侵入を監視する

変更時刻を基準に、旧Cookieや不審IPからの認証失敗、管理者ログイン、ユーザー作成、プラグイン追加、ファイル更新を追います。
wp-cronが後から動くこともあるため、数時間から数日の監視を続けます。

新しい管理者や不審ファイルが再び現れた場合は、別の侵入経路が残っている可能性が高いです。
再び封じ込め、ログと差分を保存し、クリーンな公式ファイルからの復元範囲を見直します。

ログ保存期間が短い場合は、調査を始める前にローテーション設定と退避方法を確認します。
確認できなかった期間は安全と断定せず、証拠が存在しない範囲として調査記録へ明記してください。

WordPressのXML-RPCは無効化してよい？Jetpack・アプリ利用時の判断基準

SALTキー変更で起きるエラーと安全な戻し方

500エラーは構文とファイル形式を確認する

500エラーは秘密値より、引用符やセミコロンの欠落、途中改行、同名定数の重複、不要文字の混入が原因になりやすいです。
PHPエラーログと変更差分を確認します。

直せない場合は変更直前に取得し、ハッシュを記録した元ファイルへ一度戻します。
感染の可能性がある古いバックアップを無条件で採用せず、戻した時刻と理由も記録してください。

ファイル転送が途中で切れる環境では、一時ファイルへアップロードしてから同じディレクトリ内で切り替える方法を検討します。
ただしホスティングの仕様と権限を確認し、安全な手順を優先します。

複数Webサーバーでは8行を揃える

ロードバランサー配下で各ノードが別のwp-config.phpを読む場合は、全ノードの8定数を同じ新しい組へ更新します。
値が異なるとアクセス先が変わるたびにCookie検証が失敗します。

コンテナの稼働インスタンスだけを直接編集すると、再起動で古い設定へ戻ります。
Secret管理、環境変数、デプロイ定義など正本を更新し、全インスタンスへ反映します。

反映確認は一つの画面を一度開くだけでは不十分です。
複数回アクセスし、各ノードの設定ハッシュやデプロイ世代を確認して、古いノードが混在していないか調べます。

管理ホスティングでは設定の正本を確認する

ホスティング会社がwp-config.phpを自動生成する、管理画面から認証キーを管理する、直接編集を制限する場合があります。
独自手順がある環境では公式マニュアルを優先します。

書き込み権限を一時的に広げた場合は、作業後に元の所有者と権限へ戻します。
バックアップを.bakとして公開領域へ残さず、アクセス制限された保管先へ移します。

WAFやファイル改ざん検知が更新を止めることもあります。
防御機能を恒久的に無効化せず、保守時間中の正規変更として記録し、反映後に監視が再開したことを確認します。

SALTキー変更後の再発防止と運用

認証情報を種類ごとに台帳化する

WordPressパスワード、Application Passwords、SFTP、SSH鍵、データベース、ホスティング、DNS、管理メールを分けて記録します。
秘密値ではなく用途、所有者、保管場所、発行日、失効担当を残します。

退職者や外注先の権限が残らないよう、契約終了時の確認へユーザー、セッション、API認証、共有バックアップを含めます。
SALT変更は不要アカウント削除の代わりにはなりません。

定期棚卸しでは、最終利用が古い認証情報、担当者不明の連携、共有アカウントを優先して整理します。
削除前に業務影響を確認し、誰が何のために使うか説明できる状態を保ちます。

バックアップと開発環境を見直す

バックアップにwp-config.phpを含める場合は暗号化、アクセス制限、保存期間、復元担当を決めます。
古いバックアップが閲覧可能なら、現在のSALTを変えても同じ経路から再び漏えいします。

開発環境へ本番wp-config.phpを丸ごとコピーしないでください。
環境ごとに別のSALTと認証情報を用意し、公開リポジトリや配布ZIPへ秘密が含まれないか検査します。

復元テストでは、秘密を含むバックアップを誰が展開できるかも確認します。
保管だけ安全でも、復元用URLや一時ディレクトリが公開されれば情報流出につながります。

ログイン防御と監視を組み合わせる

二段階認証、ログイン試行制限、不要なXML-RPC制御、ユーザー名漏えい対策、管理画面アクセス制限を組み合わせます。
一つのプラグインだけに依存せず、サーバーとWAFのログも保存します。

クイックレスキュー365は不正ログインブロック、ログインURL変更、XMLRPC遮断などに利用できます。
マルウェアのスキャン機能はないため、感染調査にはWordfenceなどのスキャンや公式ファイル照合を別に行います。

平常時に一度、SALT変更から再ログイン、外部連携確認、戻し作業までをテストすると、事故時の停止時間を減らせます。
結果を手順書へ反映し、担当者交代後も実行できる状態にします。

日本製セキュリティ対策で不正アクセスを遮断「クイックレスキュー365」無料ダウンロード

プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。

WordPress・サイト保守クイックレスキュー365

WordPressのSALTキー変更でよくある質問

不正アクセス後のSALTキー変更は順番と検証が重要

SALTキー変更は盗まれた可能性があるログインCookieを無効化する有効な対策です。
しかし侵入口やバックドアを残したまま8行を交換しても、新しいセッションを作られれば再侵入は止まりません。

証拠とwp-config.phpを保存し、安全な管理経路を確保してからKEY・SALTの8行を一組で置き換えます。
反映後は旧セッション、新規ログイン、複数権限、外部連携、アクセスログを確認してください。

ログインループが続く、複数サーバーの設定場所が分からない、改ざんが再発する場合は秘密値を共有せず専門家へ相談してください。
SALT変更だけで終えず、侵入経路の特定とクリーンな復旧までつなげることが重要です。

WordPressの不正アクセス・乗っ取りが自分で直せない時は

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で