タグアーカイブ WordPress

WordPressサイトがハッキングされた時の難読化PHPコードの見つけ方と完全駆除手順

WordPressサイトのindex.phpなどのコアファイルに難読化された悪意あるPHPコードが埋め込まれ、不審なサイトへリダイレクトされる被害が発生した場合、感染ファイルの完全削除とコアファイルの再インストール、全認証情報の変更を同時に進める必要がある。

この種の改ざんは「goto文」や16進数エンコードした文字列、外部サーバーとの通信機能などを使って巧妙に隠されている。残骸を残さず駆除し、再侵入経路をすべて塞ぐ手順を具体的に追っていく。

なぜWordPressサイトに難読化された悪意あるコードが仕込まれるのか

攻撃者が難読化コードを埋め込む目的は大きく3つある。不正なリダイレクトによるアフィリエイト収益の横取り、サイト訪問者の個人情報やパスワードの窃取（フィッシング）、そしてサイト自体を踏み台にして別のサーバーを攻撃するスパム配信やDDoS攻撃の中継だ。

コードの難読化は、セキュリティプラグインや手動の目視検査をすり抜けるために施される。変数名や関数名をランダムな文字列にし、goto文で処理の流れを複雑に飛ばすことで、実際に何を実行しているのかを読み取りにくくしている。この手のコードは、単独のファイルに留まらず、複数のテーマファイルやアップロードディレクトリに分散して設置されることが多い。

上記の例は、攻撃者が検索エンジンのボットを判別し、Googleなどのクローラーには元の正常なページを見せ、一般の訪問者だけに不正サイトへ飛ばす「クローキング」という手法の典型的な挙動を示している。

感染したWordPressサイトを手動で完全に駆除する手順

感染が疑われるファイルとディレクトリを優先して検査する

改ざんされたコードは、WordPressのルートディレクトリ直下のindex.phpやwp-config.phpだけでなく、テーマやプラグインのディレクトリ、アップロードディレクトリにも潜む。次の場所を重点的に確認する。

• ルートディレクトリの全.phpファイル（index.php、wp-load.php、wp-settings.phpなど）
• /wp-content/themes/ 配下の全テーマ（特にアクティブなテーマのfunctions.php）
• /wp-content/plugins/ 配下の全プラグインファイル
• /wp-content/mu-plugins/（もし存在すれば）
• /wp-content/uploads/ 配下のPHPファイル（本来PHPファイルが存在すべきではないディレクトリ）
• /wp-includes/ 配下のコアファイルの改ざん有無（後述のチェックサム検証で判別可能）
• .htaccess ファイル（リダイレクトルールや不正なコードブロックが追記されていないか）

WordPressコアファイルの再インストールとチェックサム検証

wp-content ディレクトリと wp-config.php を除き、WordPressのコアファイルをすべて公式の配布ファイルで上書きするのは安全かつ最も確実な駆除方法だ。管理画面の「ダッシュボード」→「更新」から「再インストール」を実行するか、手動で行う場合は次の手順を踏む。

管理画面にアクセスできるなら「ダッシュボード」→「更新」の「WordPressを再インストール」ボタンを押すだけで同等の処理が完了する。手動で行う場合も、wp-content と wp-config.php を保護している限り、データ消失の心配はない。

感染源を特定するためにサーバーログとタイムスタンプを照合する

どの脆弱性から侵入されたかを特定するには、改ざんされたファイルのタイムスタンプとサーバーのアクセスログ、エラーログを突き合わせる。ログに「POST /wp-admin/admin-ajax.php」や「POST /xmlrpc.php」への不自然な連続リクエストが記録されていれば、ブルートフォース攻撃やXML-RPCを経由した侵入が疑われる。

ホスティングのコントロールパネルから「Raw Access Logs」や「エラーログ」をダウンロードし、改ざん発生日時の前後を中心に調べる。プラグインやテーマのアップデートを長期間放置していた場合は、脆弱性情報データベース（CVE）で該当バージョンの既知の脆弱性を検索し、侵入経路の仮説を立てる。

適切なファイルパーミッションに設定し直す

ディレクトリは755、ファイルは644を基本とし、wp-config.phpだけは440または400に設定して読み取り権限を厳格にする。特にwp-content/uploads/ 配下にPHPファイルが置かれている場合は、そのディレクトリでPHPの実行を.htaccessで明示的に拒否しておくべきだ。

# .htaccess を wp-content/uploads/ に設置する場合
<FilesMatch "\.(php|php\.)$">
    Require all denied
</FilesMatch>

プラグインとテーマをクリーンな状態に置き換える

すべてのプラグインとテーマを、公式ディレクトリまたは購入元から再ダウンロードした完全に新しいファイルで上書きする。非公式サイトから入手したプラグインやテーマ、長期間更新が止まっているものは、この機会に削除するか代替に切り替える。

とくに mu-plugins ディレクトリは、手動で設置しない限り通常は存在しない。見慣れないディレクトリ名やPHPファイルがあれば、即座に削除する。

データベース内の不正なコードや管理者アカウントを検査する

phpMyAdminやWP-CLIを使って、wp_options テーブルの「siteurl」や「home」、wp_posts の投稿内容に不審なスクリプトタグやiframeが埋め込まれていないかを調べる。同時に、wp_users テーブルで身に覚えのない管理者アカウントが追加されていないかも必ず確認する。

データベース内の隠し管理者を一括で探すには、WP-CLIで次のコマンドを実行すると早い。

wp user list --role=administrator

全認証情報を変更しセキュリティキーを再生成する

駆除作業が完了したら、WordPress管理画面の全ユーザーパスワード、データベースパスワード、SFTP/SSHパスワード、ホスティングのコントロールパネルパスワードをすべて変更する。wp-config.php の「AUTH_KEY」「SECURE_AUTH_KEY」などのセキュリティ用ソルトも、WordPress.orgの公式ソルト生成ツールで新しいものに置き換える。

よくある質問

クリーンなバックアップがない場合、復旧の優先順位はどう決めればよいか

バックアップが存在しない、またはバックアップ自体が感染後のものである場合は、コアファイルの再インストールとプラグイン・テーマの全置き換えを最優先する。データベースの修復はその後で、不正な投稿やユーザーを手動で削除する。サイトのダウンタイムを最小限にするため、メンテナンスモードを有効にして作業するのが安全だ。

無料のプラグインやテーマが感染の原因になることはあるか

公式ディレクトリで配布されている無料プラグインでも、深刻な脆弱性が発見されて更新が滞れば攻撃の糸口になりうる。とくに、公式ディレクトリ以外のサイトから配布されている「nulled（クラック）」版の商用プラグインやテーマは、ほぼ確実にバックドアが仕込まれているため、絶対に使用してはいけない。

データベースを直接編集する際の注意点は何か

phpMyAdminなどでデータベースを直接操作する場合は、必ず事前にデータベース全体のダンプ（エクスポート）を取っておく。wp_options テーブルの「active_plugins」行を誤って削除すると全プラグインが無効化されるため、行の値を直接編集するよりも、WP-CLIのwp optionコマンドを使うほうが安全に操作できる。

cronジョブに疑わしいタスクが仕込まれていないか調べる方法は

WordPressの疑似cron（WP-Cron）はwp_options テーブルの「cron」オプションに格納されている。WP-CLIでwp cron event listを実行すると登録されている全タスクを一覧できる。ホスティング側の本物のcronジョブ（crontab）に不正なエントリが追加されていないかも、ホスティングの管理画面またはSSHで確認する。

攻撃者に検索エンジンのボット判定をすり抜けられた場合の追加対策は

難読化コードがボット判定を行っている場合、駆除後もクローキング用のキャッシュがCDNや検索エンジンに残っている可能性がある。サイト駆除後にGoogleサーチコンソールで「URL検査」→「インデックス登録をリクエスト」を実行し、CDNの全キャッシュをパージする。HTTPヘッダーを改ざんされていないかも、curlコマンドなどで確認しておくべきだ。

この記事のポイント

• 難読化PHPコードは複数ファイルに分散して設置されるため、ルート直下、テーマ、プラグイン、アップロードディレクトリをすべて検査する
• WordPressコアファイルは wp-content と wp-config.php を保護したうえで公式ファイルで完全に上書きする
• 改ざんファイルのタイムスタンプとサーバーログを照合し、侵入経路を特定して永続的な対策を講じる
• 全認証情報の変更とソルトの再生成を駆除と同時に行い、再侵入を防ぐ
• クリーンなバックアップがある場合は、全ファイルとデータベースの削除後にバックアップから復元するのが最も確実な方法である

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

PHP Warning Undefined array key value エラーの原因と直し方

WordPress で PHP 8.x 環境に移行した後、サーバーのエラーログに「Warning: Undefined array key」という警告が大量に記録されるようになった場合、最も確実な解決策は原因となっているプラグインを最新バージョンに更新することだ。この警告はいわゆる「Notice」より深刻度が一つ上の「Warning」だが、サイトの表面的な表示や動作が完全に停止する致命的なエラーではない。

PHP 8.x 環境で「Undefined array key」が頻発する根本的な原因とは

PHP 8.0 以降、コードの実行エンジンが大幅に厳格化された。以前の PHP 7.x 系では配列に存在しないキーを参照しても警告が出ずにスルーされたが、PHP 8.x では「Undefined array key」という警告が発生する。WordPress のプラグインを一手に引き受ける制作会社や個人開発者の視点では、これは「昔のコードの書き方が許されなくなった」状態といえる。

具体的には、配列のキーを直接参照するコードが原因だ。例えば、$field['value'] のように配列のキーを直接指定すると、そのキーが存在しない限り例外や警告が出る。今回の「lib-widget-fields.php」のように、ウィジェット側で「value」キーを出力する仕様になっていないのに、テンプレート側でそれを読み込もうとすると、PHP の厳格な構文チェックに引っかかる。

エラーログを止める最も確実な方法「プラグインのアップデート」

WordPress で「Undefined array key」が特定のプラグイン（たとえば Directorist のようなディレクトリ系テーマ・プラグイン）で発生する場合、最優先で行うべきはそのプラグインのアップデートだ。成熟したプラグインであれば、開発チームがすでにコードを修正し、PHP 8.x 向けに配列キーの存在チェックを追加した新しいバージョンをリリースしている可能性が高い。

管理画面の「ダッシュボード」→「更新」画面から手動で更新するか、利用しているプラグインの公式サイトで最新バージョンがリリースされていないか確認する。自動更新が無効になっていると、修正パッチが適用されずにいつまでもエラーログが肥大化し続ける。サイトヘルス画面やサーバーのディスク容量を圧迫する前に手を打つべきだ。

すぐに警告を非表示にする「wp-config.php」の設定変更

プラグインの更新がまだ提供されていない、または何らかの理由で更新できない事情がある場合、サーバー設定ファイル wp-config.php を調整して警告を非表示にできる。ただしこれはあくまで対症療法であり、根本的なコードの修正ではないことを理解しておきたい。本番環境では、エラーを画面に表示させず、ログだけに記録する設定が原則だ。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

上記の設定により、PHP の警告は画面に表示されなくなるが、/wp-content/debug.log には引き続き記録される。完全にログ出力自体をやめたい場合は WP_DEBUG を false にするが、別の問題が起きたときに原因究明が遅れるため、ログへの記録は有効にしたまま画面への表示を切る方法が現実的だ。

緊急時の応急処置としてコードを直接修正する

プラグインのアップデートがいつになるかわからず、かつデバッグ表示オフではカスタマイザー上での操作に支障が出るなどワークフロー上の問題がある場合、最終手段としてプラグインのソースコードを直接修正する手がある。

具体的には、配列のキーを読み込む前に、そのキーが存在するかチェックするか、PHP 7.0 から導入された Null 合体演算子（??）を使ってデフォルト値を与える。先の例でいえば、$field['value'] という部分を $field['value'] ?? '' に書き換えれば、キーが存在しない場合は空文字が代入され、警告は出なくなる。

この作業は必ず「FTP を使えるか」「バックアップが取れるか」という前提の下で行う。くれぐれも子テーマで上書きできる範囲の関数であれば function.php に記述するべきだが、プラグインのコアファイルは直接触らざるを得ない。修正後はそのプラグインの自動更新を一旦停止し、公式の修正版がリリースされたら必ず元に戻してアップデートする手順を徹底する必要がある。

よくある質問

このエラーはサイトを完全に停止させる致命的なエラーですか

多くの場合、これは「Warning（警告）」であり、サイトの表示が真っ白になるような「Fatal error（致命的エラー）」とは性質が異なる。サイトは表示され続けるが、サーバーのエラーログファイルが短期間で肥大化する原因になる。また、管理画面のウィジェット設定画面やカスタマイザーでレイアウトが崩れたり、意図しない文字列が出力される可能性はある。

WP_DEBUG を false にすれば解決しますか

WP_DEBUG を false にすれば、エラーメッセージが実際のサイト画面やログファイルにすら出力されなくなる。しかしこれは「警告を見えなくした」だけであり、コードの潜在的な問題が解決したわけではない。PHP 8.x における動作が保証されていないコードを放置することになるため、開発環境ではログを取りつつ、本番環境では画面表示を切るという運用が基本になる。

エラーログの場所がわかりません

WP_DEBUG_LOG が true の場合、通常は /wp-content/debug.log に出力される。サーバーのコントロールパネル（cPanel など）に「エラーログ」機能がある場合はそちらにも記録される。FTP でアクセスしても見つからない場合は、wp-config.php で WP_DEBUG_LOG が正しく定義されているか、ファイルの書き込み権限があるかを確認する。

さくらインターネットやエックスサーバーで PHP 8.3 に変更したらこのエラーが出ました

国内の主要レンタルサーバーでは、管理画面から PHP のバージョンを簡単に切り替えられる。PHP 7.4 から 8.3 へ一気に上げると、旧式のコードを抱えたプラグインやテーマが一斉に警告を出すことがある。切り替え前にローカルやステージング環境で動作確認を行うのが理想だが、もし本番環境で出てしまった場合は、まずプラグインの一括更新を試し、それでも直らないものだけ個別に開発元へ報告するのが現実的な対処法だ。

functions.php でエラーの轍を消せませんか

残念ながら、特定のプラグインが内部で無造作に配列を直接参照している場合、テーマの functions.php からその挙動を直接上書きしてなかったことにはできない場合が多い。プラグインのコードに isset() などが欠如しているならば、前述の通りプラグインファイル自体を修正するか、プラグインのフックが用意されていればそれで値を事前に定義するなどの手段を取る必要がある。

この記事のポイント

• 「Undefined array key」は PHP 8.x で厳格化された構文チェックが原因
• プラグインを最新バージョンに更新することで根本解決する
• 一時しのぎには wp-config.php で WP_DEBUG_DISPLAY を false に設定する
• Null 合体演算子（??）を用いたコード修正は応急処置であり、アップデートで上書きされる前提で行う
• エラーログの肥大化を防ぎつつ、開発元へ報告することで結果的にエコシステム全体が改善される

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

www.aandgweb.co.jp