WordPressデータベースのoptionsに不正リダイレクトが入った時の探し方

「WordPressを開くと知らないサイトへ飛ぶ」「ファイルを直したのに不正リダイレクトが残る」と困っていませんか？

転送先のURLや不審なコードは、テーマやプラグインだけでなく、データベースのoptionsテーブルに保存されることがあります。
ただし、検索結果に外部URLが出たからといって、見つけた行をすぐ削除するのは危険です。

optionsにはWordPressの基本URL、使用中のテーマ・プラグイン、ウィジェット、各種設定が入ります。
誤った直接編集は、管理画面へ入れない、設定が消える、PHPのシリアライズデータが壊れるといった別の障害を招きます。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、optionsの証拠保全から安全な検索・修正、再発元の調査まで順番に解説します。

結論から言うと、WordPressのoptionsに不正リダイレクトが疑われる時は、現状を保全してから読み取り検索を行い、
option名・値・autoload・由来を確認したうえで、WordPressの仕組みを通して修正するのが安全です。

該当値を消して表示が戻っても、ファイルやCronなどの再投入元が残れば再発します。
データベース修正を入口に、WordPress全体の侵害調査へつなげましょう。

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

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

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

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

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

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

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

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

WordPressのoptionsに不正リダイレクトが疑われる時の初動

WordPressのoptionsを触る前に行うべきことは、症状、データベース、ファイル、ログの保全です。

不正な転送が起きている最中は、早くURLを消したくなります。
しかし、最初の状態を残さず変更すると、どの設定が書き換えられ、何が再発させているのかを追いにくくなります。

転送が起きる条件と時刻を記録する

最初に、トップページ・個別記事・管理画面のどこで起きるか、PCとスマートフォンで同じかを確認します。
検索結果から来た時だけ、初回訪問だけ、ログアウト中だけという条件があれば記録してください。

転送元URL、転送先のドメイン、確認時刻、利用端末、ブラウザー、参照元をメモします。
危険な転送先へ何度もアクセスせず、画面録画や開発者ツールを使う場合も安全な調査環境で行います。

現在のデータベースと関連ファイルを別に保全する

データベースは修正前に、サイト専用の保存先へ日時付きでエクスポートします。
同時にwp-config.php、テーマ、プラグイン、mu-plugins、.htaccess、uploads、サーバーのアクセス・エラーログも保全してください。

公開被害を止めてもWordPressを初期化しない

訪問者を詐欺サイトへ送っている、警告画面が出る、個人情報を入力させる状態なら、公開制限を優先します。
可能なら侵害されたWordPressのプラグインではなく、サーバーパネルやWAFなど上位の管理面から制限してください。

WordPressのoptionsテーブルを正しく特定する

WordPressのoptionsを調べる時は、接続先データベースと実際のテーブル接頭辞を先に確認します。

一般的な解説ではwp_optionsと書かれますが、すべてのサイトがwp_を使っているわけではありません。
別環境やステージング用のテーブルを調べると、本番の不正値を見落としたり、無関係なデータを変えたりします。

wp-config.phpの接続先とtable_prefixを照合する

まずwp-config.phpでDB_NAME、DB_HOST、テーブル接頭辞を確認し、サーバーパネルやphpMyAdminで同じ接続先を開きます。
秘密の値は一般のチャット、スクリーンショット、作業ログへ貼らないでください。

複数のWordPressが同じデータベースを共有している場合、optionsに相当するテーブルも複数あります。
テーブル内のsiteurlやhomeを読み取り、対象サイトのURLと一致するかを確認すると取り違えを減らせます。

option_id・option_name・option_value・autoloadを一組で記録する

候補行を見つけたら、値だけでなくoption_id、option_name、option_value、autoloadを一組で保存します。
どの機能の設定か、ページ表示時に読み込まれるか、修正後に同じ値が戻ったかを比較するためです。

siteurlとhomeだけで原因を決めつけない

siteurlとhomeが知らないドメインへ変わっていれば重要な異常ですが、正しい場合でも不正リダイレクトは起こります。
ウィジェット、テーマ設定、広告・解析コード、リダイレクト系プラグイン、キャッシュされた設定にURLが埋め込まれることがあるためです。

WordPressのoptionsから不正リダイレクトを安全に探す

WordPressのoptions検索は、既知の転送先URLから始め、読み取りだけで候補を絞るのが安全です。

「怪しそうな行を全部削除する」のではなく、実際に観測したドメイン、URLの一部、特徴的な文字列を手掛かりにします。
転送先が毎回変わる場合は、共通するドメイン部分や生成元の設定名を探します。

phpMyAdminではSELECTだけで候補を確認する

phpMyAdminの検索機能を使うか、権限のある担当者が読み取り用のSELECTを実行します。
次の例では、実際の接頭辞へ置き換え、調査用の無害な例示ドメイン部分を検索しています。

SELECT option_id, option_name, autoload
FROM wp_options
WHERE option_value LIKE '%example.invalid%'
LIMIT 100;

この段階ではUPDATEやDELETEを実行しません。
検索結果が多い時は、option_nameとautoloadを記録してから、候補の値を個別に確認します。

管理画面・WP-CLI・データベース検索を使い分ける

正規の設定画面が分かる場合は、まずその画面で現在値を確認します。
WordPressのOptions APIを使う管理画面なら、値の形式を保って保存できる可能性が高く、直接SQLより安全です。

WP-CLIを安全に実行できる環境では、optionの一覧や個別取得を使って読み取り確認できます。
コマンド履歴や共有ログへ秘密情報を残さないよう、値を丸ごと表示する対象は選んでください。

wp option get home
wp option get siteurl
wp option list --search='*redirect*' --fields=option_name,autoload

URLが入り得る設定を由来ごとに調べる

siteurl・homeが正常なら、active_plugins、theme_modsで始まる設定、ウィジェット、ヘッダー・フッター挿入、広告、解析、リダイレクト、キャッシュ関連を確認します。
名称は環境ごとに違うため、「このoption名なら必ず感染」といった一覧だけで削除しないでください。

候補のoptionがどのテーマ・プラグインに属するかを調べ、正規の設定画面と比較します。
無効化済みプラグインの残存設定や、削除済みテーマの設定が残ることもあるので、存在するだけでは実行中とは限りません。

WordPressのoptionsで誤判定とデータ破損を避ける

WordPressのoptionsに外部URLや長い文字列があっても、正常な設定と改ざんを切り分けてから変更します。

optionsには更新確認先、API接続先、画像CDN、ライセンス、埋め込み、キャッシュなど、正規の外部URLも多数保存されます。
見慣れないドメインという理由だけで消すと、テーマやプラグインの機能が止まることがあります。

正規URL・一時データ・不審値を分ける

候補値は、導入中の機能、公式配布元、作業履歴、正常な別環境と照合します。
WordPress.org、契約中サービス、CDN、決済、フォームなど、運用上必要な接続先で説明できるかを確認してください。

名前にtransientやsite_transientが含まれる一時データは、期限付きキャッシュとして使われることがあります。
不審URLを含む場合でも、元の設定やファイルが残っていれば、キャッシュだけ消しても再生成されます。

反対に、正規プラグインに似せたoption名でも、内容と作成経路が説明できなければ調査が必要です。
名前の見た目ではなく、値の用途、更新時刻、読み込むコード、再生成の有無を組み合わせて判断します。

シリアライズされたoption_valueを直接置換しない

配列やオブジェクトを保存したoption_valueは、PHPのシリアライズ形式になっていることがあります。
文字列の長さ情報を含むため、URL部分だけをSQLで置換すると長さが合わず、値全体を読み込めなくなる場合があります。

JSONに見える値、エスケープされた文字列、改行を含むCSSやJavaScriptも、単純な検索置換で壊れることがあります。
修正には正規の設定画面、Options API、シリアライズを理解するWP-CLIなど、値の形式を保てる方法を優先してください。

option単体で侵入経路や安全性を断定しない

不正URLがoptionsにあることは改ざんの重要な証拠ですが、侵入経路までは示しません。
脆弱なプラグイン、盗まれた管理者、SFTP、別サイトのバックドア、サーバー側の不正処理など、複数の経路から書き込めます。

また、検索で該当URLが見つからなくても、ファイル側の条件分岐、外部スクリプト、DNS・CDN・Service Workerが転送している可能性があります。
「optionsにないから感染していない」と結論づけず、症状に応じて調査範囲を広げてください。

WordPressのoptionsを安全に修正して再発元を止める

WordPressのoptions修正は、バックアップ、候補の無効化、正規値の復元、再発元の停止を一つの工程として進めます。

値だけを消すと一時的に転送が止まることはありますが、それで復旧完了ではありません。
書き込んだコードやアカウントが残っていれば、数分後や次のアクセス時に同じoptionが再作成されます。

変更前後を比較できる形で一項目ずつ修正する

修正前にDB全体と該当行を保存し、option名、変更前値のハッシュ、変更理由、担当者、時刻を記録します。
正常値は、信頼できるバックアップ、正規の設定画面、運用担当者の記録から決めてください。

siteurlやhomeを戻す場合も、公開URL、WordPress設置先、SSL、リバースプロキシ、移転中かどうかを確認します。
見た目だけでURLを決めると、リダイレクトループや管理画面へのログイン不能を起こすことがあります。

テーマやプラグインの設定は、可能なら正規の管理画面から保存し直します。
管理画面が使えない場合は、検証環境でWP-CLIやWordPress APIを使い、値の形式と動作を確認してから本番へ反映します。

optionsを書き戻すファイル・Cron・アカウントを調べる

修正後は、該当optionの値と更新時刻を監視します。
再び変わった時刻とアクセスログ、PHP実行ログ、WP-Cron、サーバーCron、管理者操作を照合すると、再投入元を絞りやすくなります。

WordPress本体、テーマ、プラグイン、mu-plugins、uploads、.htaccessに不審コードがないか確認してください。
難読化されたPHP、外部URL取得、update_optionの呼び出しが見つかっても、実行せず、正規版との差分と由来を調べます。

不審な管理者、Application Passwords、覚えのないプラグイン、WP-Cronイベントも確認します。
同じサーバー契約に複数サイトがある場合は、古いCMSや別WordPressから書き込める範囲まで調査が必要です。

認証情報を失効し、WordPress全体をクリーンに戻す

DBへ不正な値を書けた時点で、管理者やサーバー権限が侵害された可能性を考えます。
安全な端末から、メール、ドメイン、サーバーパネル、SFTP・SSH、データベース、WordPressの認証情報を範囲に応じて更新します。

WordPressの認証キーとソルトを交換して既存ログインCookieを無効化し、不審ユーザーとセッションを失効させます。
本体は正規配布物、テーマ・プラグインは信頼できる配布元と照合し、不要なものを停止・削除します。

感染時点を含むバックアップを丸ごと戻すと、不正optionやバックドアも復元されます。
復元世代を選び、最新の正規データとプログラム部分を分けて扱う判断が必要です。

わたしの実務では、値を消した時刻より、同じ値が再び入った時刻を追うことが再発元の発見につながります。

WordPressのoptions復旧後に不正リダイレクトの再発を防ぐ

WordPressのoptions復旧後は、転送停止だけでなく、侵入口、変更監視、主要機能を確認して完了を判断します。

トップページが開けても、検索経由・スマートフォン・ログアウト状態で転送が残ることがあります。
最初に記録した条件を使って再テストし、数日から数週間は同じoptionとログの変化を監視してください。

更新・最小権限・防御設定を見直す

WordPress本体、テーマ、プラグインを安全な版へ更新し、不要な管理者、未使用プラグイン、放置サイトを整理します。
サーバー、DB、SFTPのアカウントは用途ごとに分け、必要以上の権限を与えないようにします。

WAFや不正ログイン対策を有効にし、管理者へ多要素認証を設定します。
防御機能の導入だけで既存マルウェアは消えないため、復旧と予防を別工程として確認してください。

正常値・ファイルハッシュ・ログを監視する

重要なoptionの正常値またはハッシュ、更新が許可される操作、基準日時を記録します。
監視通知が出たら自動で削除する前に、変更時刻、実行ユーザー、リクエスト、同時刻のファイル更新を保存します。

公開・管理・フォーム・検索結果まで再確認する

PCとスマートフォン、検索・SNS・直接アクセス、初回・再訪、ログイン・ログアウトで再現確認します。
管理画面の保存、画像アップロード、問い合わせ、決済、予約処理、メール送信など、事業に必要な機能も試してください。

Google検索に不審ページやタイトルが残る場合は、サイト内の復旧後にSearch Consoleの警告・登録URLを確認します。
キャッシュが更新されるまで時間がかかることもあるため、サーバー側の再発と検索結果の反映待ちを区別します。

WordPressのoptionsと不正リダイレクトに関するよくある質問

WordPressのoptions調査で迷いやすい点を、修正前に短く整理します。

wp_optionsのsiteurlとhomeを戻せば直りますか？

その2項目が改ざんされていれば修正は必要ですが、別のoption、ファイル、プラグイン、DNS・CDNが転送している場合は直りません。実際の接頭辞と転送条件を確認し、再投入元まで調べてください。

知らない外部URLを含むoptionは削除してよいですか？

すぐ削除しないでください。更新確認、CDN、API、決済などの正規URLかもしれません。所属するテーマ・プラグイン、公式資料、更新時刻、正常環境を照合し、DBと該当行を保全してから判断します。

SQLのREPLACEで転送先URLだけ直してもよいですか？

シリアライズされた値では文字列長が崩れ、設定全体を読めなくする恐れがあります。正規の設定画面、Options API、WP-CLIなど形式を扱える方法を優先し、検証環境と復元可能なバックアップを用意してください。

optionsを修正した後に同じ値が戻るのはなぜですか？

不審なPHP、テーマ・プラグイン、mu-plugins、WP-Cron、サーバーCron、不審管理者、別サイトのバックドアなどが再び書き込んでいる可能性があります。戻った時刻とログ・ファイル更新を照合してください。

WordPressのoptionsは保全・検索・再発元調査の順で復旧する

WordPressデータベースのoptionsに不正リダイレクトが疑われる時は、まず症状と現状DB、ファイル、ログを保全します。
実際のテーブル接頭辞を確認し、観測したURLや特徴的な文字列をSELECTなどの読み取り操作で探してください。

候補が見つかっても、外部URLや見慣れないoption名だけで改ざんと断定してはいけません。
所属機能、作業履歴、更新時刻、autoload、正常環境を照合し、シリアライズ値の直接置換を避けます。

修正には正規の設定画面、Options API、WP-CLIを優先し、一項目ずつ変更前後を記録します。
同じ値を再投入するファイル、Cron、アカウント、同一サーバー内の別サイトまで調査して、再発経路を閉じましょう。

「不審URLを消した」ではなく、「再び書き込む経路を止めた」を復旧の完了基準にしてください。

WordPressのoptions改ざんを自分で復旧できない時は

options内の不審URL、繰り返すリダイレクト、シリアライズされた設定の修正でお困りなら、
クイックレスキューが証拠保全、感染調査、データベース復旧、認証情報の見直し、再発防止まで対応します。

値を削除して証拠を失う前に、現在の状態を保全してご相談ください。