WordPressサイトが改ざんされた相談は、これまで何度も受けてきました。

実際に多いのは「ある日突然リダイレクトされる」「検索結果に怪しいページが増える」「管理画面に入れるのにサイト内容が書き換わっている」といったケースです。

私が最初にWordPress改ざんの復旧対応をしたときも、クライアントから「突然海外の通販サイトに飛ばされる」と連絡を受けたことがきっかけでした。

WordPress改ざんは「表面の修正」では解決しないケースが多く、原因を追わないとすぐ再発します。

この記事では、私が実際に現場で行っている調査手順と復旧方法を、再発防止まで含めて解説します。

WordPress改ざんの典型症状

WordPressの改ざんは、最初は小さな違和感から始まることが多いです。

私も最初のころは「テーマの表示崩れ」や「キャッシュ不具合」と勘違いしてしまうことがありました。

しかし実際には、改ざんの兆候にはいくつか共通パターンがあります。

ここを見逃すと復旧が遅れるので普段から注意しておきましょう。

よくある改ざんの症状

現場で確認する代表的な症状は次のとおりです。

• 検索結果に存在しないページが表示される
• 海外のECサイトにリダイレクトされる
• サイト下部にスパムリンクが追加される
• 管理者ユーザーが勝手に追加される
• index.php が書き換わる
• wp-content 内に不審なPHPファイルが増える

特に多いのがSEOスパム型の改ざんです。

これはGoogle検索にだけスパムページを表示させるタイプです。サイト運営者は気づきにくい特徴があります。

サーバー内の典型的な改ざんファイル

実際に復旧作業で見つかるファイルの例を紹介します。

/wp-content/uploads/2023/09/wp-vcd.php
/wp-includes/wp-class.php
/wp-admin/css/colors/blue/blue.php

uploadsフォルダは本来画像しか置かない場所です。

ここにPHPがある場合、かなり高い確率でバックドアです。uploadsフォルダにPHPがある場合、まず疑うことをお勧めします。

私が過去に対応した案件でも、uploadsフォルダの奥に数百個のバックドアが置かれていました。

当初、1つ削除すれば解決すると思いました。

しかし別の場所に設置されたcron型の復元スクリプトが原因で、削除してもすぐ復活しました。

そのため、今は単発削除ではなく、サイト全体を調査するようにしています。

改ざんされたWordPressを復旧する基本手順

WordPress改ざんの復旧は、順番を間違えると再感染します。

重要なのは「削除」より「原因調査」を先に行うことです。

復旧の基本フロー

• サイトをメンテナンスモードにする
• バックアップを取得
• 改ざんファイルの特定
• WordPressコア再インストール
• テーマ・プラグイン再設置
• パスワード変更
• 脆弱性対策

この順番を崩さないことが重要です。

1. サイトをメンテナンス状態にする

まず被害拡大を防ぎます。
.htaccessでアクセス制限をかける方法が簡単です。

 order deny,allow deny from all allow from xxx.xxx.xxx.xxx

こうすることで、IPを自分だけ許可する形になります。

私は初期の頃、この作業をせずに調査を始めておりました。

そうすると調査中にもマルウェアが増え続け、最終的にファイル数が3倍になってしまいました。

今は必ず最初にアクセス制限をかけています。

2. サイト全体をバックアップ

次に必ず完全バックアップを取ります。後で調査が必要になるケースがあるためです。

• ファイルバックアップ
• データベースバックアップ

mysqldumpで取得できます。

 mysqldump -u user -p database > backup.sql

バックアップを取らず削除を始めるのは危険です。

以前、クライアントが自己判断で「怪しいファイル」を削除してしまったことがありました。

しかしその中に侵入経路のログが残っていました。結果、原因が特定できずに再感染しました。

このように、バックアップは調査資料としても重要になります。

改ざんファイルの調査方法

改ざん復旧で一番時間がかかるのは、この調査です。

ただし、「怪しいPHPだけ削除」だけでは不十分であり、この作業を丁寧にやらないと再発する可能性があります。

更新日時でファイルを調査

侵入された日時が分かる場合、更新日時で検索します。

 find . -type f -mtime -5

これは5日以内に更新されたファイルを抽出します。改ざんは同時刻に複数ファイルが書き換わることが多いです。

実際の案件でも、同じ秒数で20ファイル以上変更されていました。

一見、単なるWordPress更新だと勘違いすることも多いですが、よく見るとコアファイルと関係ないPHPが含まれている場合も多いので気を付けましょう。

怪しいコードの特徴

マルウェアには典型パターンがあります。

• base64_decode
• gzinflate
• eval
• str_rot13

例：eval(base64_decode("ZXZhbCgkX1BPU1RbJ2NtZCddKTs="));

このようなコードは外部から命令を実行するバックドアです。意味が分からない難読化PHPは、ほぼマルウェアです。

私が対応したサイトでも、functions.phpの一番下にこのコードがありました。

不自然に改行のない長い文字列が着目ポイントです。

この経験から、今は難読化コードを最優先で確認しています。

WordPressコアを安全に再インストールする

改ざんファイルの調査がある程度進んだら、次に行うのがWordPressコアの再インストールです。

ここは意外と軽視されがちですが、私はほぼ必ず実施する工程にしています。

理由はシンプルで、コアファイルは数百個あり、すべてを手動で確認するのは現実的ではないからです。

WordPressコアの安全な再インストール方法

基本的な手順は次の通りです。

• wp-admin フォルダ削除
• wp-includes フォルダ削除
• WordPress公式から最新ZIPを取得
• コアファイルを再アップロード

このとき削除しないフォルダは以下です。

• wp-content
• wp-config.php

これらのフォルダはサイトデータや設定が入っているため、削除をしないようにしましょう。

公式ファイルを使う理由

必ず公式サイトからダウンロードします。GitHubや配布サイトから取得したファイルを使うのは危険です。

公式はサイト：https://wordpress.org/download/

以前、開発環境からコピーしたWordPressファイルを使ったことがあります。

しかしその環境には古いプラグインが残っていました。

結果として、復旧したはずのサイトが別の脆弱性を抱えた状態になりました。

それ以降は必ず公式配布パッケージを使っています。

テーマ・プラグインの再インストール

WordPress改ざんでは、テーマやプラグインも感染している可能性があります。

そのため、私は基本的にすべて再インストールする方針にしています。

削除対象の判断

次のようなものは削除対象です。

• 使っていないプラグイン
• 更新されていないテーマ
• 不明な作者のプラグイン

特に放置されたプラグインは侵入口になりやすいです。

実際にあったケースでは、古いスライダープラグインのupload機能からの侵入が原因でした。

この予防として、使わないプラグインは即削除をした方が良いです。

再インストールの基本方針

再設置の際のポイントが大きく３つあります。

• 公式ディレクトリから再取得
• 最新版を利用
• 必要最小限のみ導入

特に「古いまま使う」は避けるべきです。プラグインが多いほど攻撃対象が増えます。
WordPressの安全性は「プラグインの数」に比例して下がります。

パスワードとユーザー権限の見直し

復旧作業の終盤では、必ずアカウント周りを見直します。

ここを忘れると、侵入者がまだログインできる状態が残る可能性があります。

変更すべきパスワード

• WordPress管理者
• FTPアカウント
• サーバー管理画面
• データベース

これらはすべて変更するのが基本です。

過去にFTPパスワードはそのままで、WordPressだけパスワード変更して対応した案件があります。

こちらはFTPアカウントの漏洩により、数日後、再び改ざんされました。

そうならないためにアカウント管理は慎重に行ってください。

不審ユーザーの確認

WordPressのユーザー一覧も確認します。次のようなユーザーは要注意です。

• admin2
• wpadmin
• support

これらはバックドア用に追加されることがあります。

私が対応したサイトでも、管理者が3人増えていたケースがありました。

侵入者が管理アカウントを作成していたのです。この経験から、今は必ずユーザー一覧を確認しています。

WordPress改ざんの再発防止対策

復旧が終わっても、それで安心ではありません。

むしろ本当に重要なのはここからです。再発防止をしないと、同じ攻撃を受けます。

最低限のセキュリティ対策

• WordPress自動更新
• ログイン試行制限
• WAF導入
• ファイル権限見直し

特に効果が高いのはWAFです。代表的なサービスは以下です。

• Cloudflare
• SiteGuard
• Wordfence

私は現在、ほとんどのサイトでWAFを導入しています。

以前は「小規模サイトだから不要」と判断していました。

しかし攻撃はアクセス数とは関係がなく、過去に月間数百アクセスのあるサイトを改ざんされた事例があります。

そのため、今は規模に関係なく対策しています。

定期監視の重要性

セキュリティは一度設定して終わりではありません。定期的なチェックが必要です。

• ファイル変更監視
• ログ監視
• Google Search Console確認

Search Consoleで「ハッキングされたサイト」と警告されることがあります。これは重要なサインです。

検索結果の異変は、改ざんの初期サインです。

Search Console通知を必ず確認することをお勧めします。

FAQ

Q1. WordPress改ざんはどこから侵入されるのですか？

最も多い侵入経路は次の3つです。

• 古いプラグインの脆弱性
• 弱いパスワード
• テーマの不正コード

特に多いのはプラグインです。実際の復旧案件でも、原因の多くは更新されていないプラグインでした。

Q2. 改ざんされたらサイトは削除すべきですか？

必ずしも削除する必要はありません。ほとんどのケースでは復旧可能です。
ただし次の場合は作り直しも検討します。

• 改ざん範囲が広い
• バックアップがない
• 古すぎるWordPress

Q3. WordPress改ざんは自分で復旧できますか？

可能ですが、難易度は高めです。特に次の作業は専門知識が必要です。

• バックドアの特定
• ログ解析
• マルウェア除去

まとめ

WordPress改ざんの復旧で重要なのは、「見えている問題だけを直さないこと」です。

多くの場合、改ざんファイルは氷山の一角です。本当の原因は、別のバックドアや脆弱性にあります。

復旧時の判断軸は次の3つです。

• 改ざん箇所ではなく侵入経路を探す
• コア・テーマ・プラグインは再設置する
• アカウント情報をすべて変更する

この3つを徹底するだけで、再発率は大きく下がります。

もしWordPress改ざんが疑われる場合は、焦って削除を始めるよりも、まず状況を整理することをおすすめします。

その冷静な判断が、結果的に復旧を早くします。

WordPressのハッキング修復はWPプロサポに

WP.復旧センターは「ハッキングされた」「表示がおかしい」「ログインできない」などのWordPressのトラブルをスピーディに修復します。

WordPressサイトが突然「500 Internal Server Error」と表示される現象を、私は何度も現場で経験してきました。

管理画面にも入れず、ただ真っ白な画面かエラー表示だけが出る状態は、慣れていない方にとっては非常に不安だと思います。

私自身も、深夜に保守対応中のサイトで500エラーが発生し、原因の切り分けに想定以上の時間がかかったことがあります。

一見すると「サーバー側の問題」と思い込みがちですが、実際にはプラグイン、テーマ、.htaccess、PHPバージョン、メモリ制限など、複数の要因が絡みます。

この記事では、私が実際の対応現場で行っている判断プロセスと、具体的な修正手順を一次情報ベースで解説します。

「とりあえず再インストール」ではなく、原因を特定しながら確実に復旧させる方法を共有します。

500 Internal Server Errorとは何かを正しく理解する

経験者として最初にお伝えしたいのは、500エラーは「原因が特定されていないサーバー内部エラー」という意味だということです。

「500 Internal Server Error」はHTTPステータスコードの一種で、サーバーがリクエストを処理できなかったことを示します。

重要なのは「エラーの原因はブラウザではなくサーバー側にある」という点です。
そのため、ブラウザキャッシュ削除では解決しません。

確認すべき一次情報は以下です。

• サーバーのエラーログ
• WordPressのdebugログ
• .htaccessの記述
• PHPバージョン情報

多くのレンタルサーバーでは、コントロールパネルからエラーログを確認できます。

例えばエラーログに以下のような記述が出ることがあります。

PHP Fatal error: Allowed memory size exhausted
この一文だけで、メモリ不足が原因だと判断できます。

闇雲に触るのではなく、「ログを見てから動く」という姿勢が最短復旧につながります。

最初に行うべき切り分け手順

私は現場では必ず「触る順番」を決めています。

以前、焦って複数箇所を同時に変更し、原因が分からなくなったことがありました。
変更履歴を残していなかったため、復旧に余計な時間を使いました。

この経験から、今は必ず一つずつ検証します。

① プラグインの停止

最も多い原因はプラグインの不具合です。

管理画面に入れない場合は、FTPで /wp-content/plugins/ フォルダ名を一時的に変更します。

例：plugins → plugins_old

これで全プラグインが無効化されます。
エラーが消えた場合は、フォルダ名を戻し、1つずつ有効化して原因を特定します。

私は過去に、セキュリティ系プラグインのアップデート直後にエラーが出た経験があります。

アップデート直後という事実を軽視していましたが、実際はバージョン不整合が原因でした。
現在は「直前の変更」を必ず確認します。

② テーマの確認

テーマのfunctions.phpの記述ミスも頻出です。

FTPでテーマフォルダ名を変更すると、自動的にデフォルトテーマへ切り替わります。
それで表示されれば、テーマ内に問題があります。

特に独自カスタマイズをしている場合は注意が必要です。

私は一度、記号の打ち忘れ（;）が原因でサイト全体が停止しました。
以降はコード追加時は必ずテスト環境で検証して対策しています。

.htaccessの破損を確認する

経験上、意外と多いのが.htaccessの記述エラーです。

私は当初、.htaccessは自動生成だから壊れないと思い込んでいました。
しかしセキュリティ設定追加時に記述を誤り、500エラーを引き起こしたことがあります。
それ以来、変更前バックアップを徹底しています。

まず現在の.htaccessをリネームします。

.htaccess → .htaccess_old

それで表示される場合、内容に問題があります。

WordPressの基本記述は以下です。

# BEGIN WordPress
RewriteEngine On RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

上記を再作成し、管理画面から「パーマリンク設定」を保存し直します。

私は一度、RewriteRuleを重複記載していたことに気づかず原因解明に時間を使いました。
今度同様なケースが発生した場合は、差分比較ツールを使うと時間短縮ができると考えています。

PHPバージョンとメモリ不足を確認する

私は保守の現場で、テーマやプラグインに問題が見当たらない場合、必ずPHP環境を確認します。

以前、WordPress本体を更新した直後に500エラーが発生し、原因特定に時間がかかりました。
当時はコードの不具合を疑っていましたが、実際はPHPバージョンが古く非対応だったことが原因でした。

現在は、更新前に動作要件を確認しています。

WordPressは公式で推奨PHPバージョンを公開しており、最新の推奨環境が確認できます。
特に注意すべき点は以下です。

• WordPressのバージョンとPHPの互換性
• 利用中テーマの対応PHPバージョン
• プラグインの動作要件

サーバー管理画面からPHPバージョンを切り替え、再表示を確認します。
切り替え後は数分反映に時間がかかる場合があります。
変更後は必ず時間を置いて確認することをおすすめします。

メモリ不足の対処方法

エラーログに「Allowed memory size exhausted」とある場合、メモリ不足が原因です。

wp-config.phpに以下を追記します。

 define('WP_MEMORY_LIMIT', '256M');

それでも改善しない場合、サーバー側の上限が制限されています。
その場合はサーバー設定で変更するか、サポートへ問い合わせます。

サーバー上限を確認せずWordPress側だけ変更した際に、その変更が実際には反映されていない場合があります。
必ずphpinfoで実効値を確認をしておくと安心です。

WordPressデバッグモードで原因を可視化する

 

表示される情報が少ない場合、私は必ずデバッグモードを有効化します。

以前、エラー内容が分からず手探りで修正し、状況を悪化させたことがあります。
原因が見えない状態での修正は、判断を誤りやすく注意が必要です。

wp-config.phpに以下を記述します。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

これにより /wp-content/debug.log に詳細エラーが出力されます。
表示はされずログだけ取得できるため、本番環境でも比較的安全です。

私は以前、WP_DEBUG_DISPLAYをtrueにしたまま公開し、エラー内容が表示されたことがあります。
現在はログ出力のみ有効にする運用にしています。

サーバー会社への問い合わせは最後の選択肢

私は現場で、安易にサーバー障害と決めつけないようにしています。

過去に、サーバー会社へ連絡したものの、実際は自作コードの構文エラーだったことがありました。

また問い合わせ前に確認すべき事項は以下になります。

• エラーログ取得済みか
• PHPバージョン確認済みか
• プラグイン無効化検証済みか
• .htaccess再生成済みか

問い合わせ内容には、発生日時、直前の変更点、エラーログ内容を明記すると、さらに解決が早まります。

FAQ

Q1. 管理画面にも入れません。どうすればよいですか？

FTP接続でpluginsフォルダをリネームしてください。
それで復旧すれば、原因はプラグインです。それでも改善しない場合はテーマを確認します。

Q2. 何も変更していないのに発生しました。

自動アップデートが原因の可能性があります。
WordPress本体、テーマ、プラグインの更新履歴を確認します。

Q3. 再インストールすれば直りますか？

原因を特定せず再インストールするのは推奨しません。
根本原因が解消されない場合、再発します。まずはログを確認することが最優先です。

まとめ

500 Internal Server Errorは「焦り」が最大の敵です。

私はこれまで多くの復旧対応をしてきましたが、最短で解決したケースは必ず「ログ確認 → 切り分け → 一つずつ検証」という順序を守っています。

重要なのは闇雲に触らないことです。
判断の軸は以下です。

• 直前の変更は何か
• ログに何が書かれているか
• 環境要件に問題はないか
• 再現性はあるか

500エラーは必ず原因があります。
ログを確認し、順番に切り分ければ解決できます。

まずは深呼吸をし、最初の一手としてエラーログを確認することから始めてください。
それが最短復旧への第一歩です。

WordPressのハッキング修復はWPプロサポに

WP.復旧センターは「ハッキングされた」「表示がおかしい」「ログインできない」などのWordPressのトラブルをスピーディに修復します。