「WordPressにログインできない」その裏で動いていたもの
「先日まで普通に使えていたのに、ある日突然WordPressの管理画面にログインできなくなった」――もしあなたが今そんな状況なら、それは単なるパスワードの問題ではないかもしれません。
先日、コーチング・研修事業を手がける企業のWordPressサイトで、まさにこの症状の調査をお引き受けしました。調べてみると、その裏では第三者が仕込んだマルウェアが静かに動いていたのです。この記事では、実際の対応をもとに「WordPressにログインできない」の本当の原因と、復旧までの全手順を解説します。前半は運営者の方向けに、後半は復旧を担うエンジニア・制作会社向けに具体的な手順をまとめました。

ログインできない症状の正体は「バックドア型マルウェア」
ご相談は「/wp-admin も /wp-login.php も『Access denied』と表示されて入れない」というものでした。一見ありふれた不具合に見えます。ところがサーバー内を確認すると、wp-content フォルダの直下に身に覚えのない BypassBest.php というファイルが置かれていました。

これは「バックドア型マルウェア」として知られる不正プログラムで、設置されるとサイトの乗っ取り・スパムの配信・別のウイルスの呼び込みなど、深刻な被害を引き起こします。「ログインできない」という症状は、その被害の氷山の一角にすぎなかったのです。
なぜ感染したのか?原因は「放置された脆弱なプラグイン」
侵入経路を調べたところ、原因はほぼ特定できました。このサイトには WP File Manager という、認証なしで誰でもファイルをアップロードできてしまう深刻な脆弱性を抱えたプラグインが、修正されないまま残っていたのです。攻撃者はこの「開きっぱなしの窓」から、マルウェア本体を直接送り込んでいました。
そして根本にあったのは長期間の放置です。サイトのオーナー様は「事業の見直しに伴いHPを刷新しようと、約3年ぶりにログインを試みた」とのこと。WordPress本体も数年前の古いバージョンのままでした。
更新の止まったサイトは、攻撃者にとって格好の標的です。鍵の壊れた空き家のように、脆弱性を突かれて侵入されてしまいます。これは決して珍しいケースではなく、放置されたWordPressサイトで最もよくある被害の形です。更新を止めることの危険性はWordPressの更新を放置するリスクと安全な運用法でも詳しく解説しています。
パーミッション「000」の正体はサーバーの自動防御
調査でもうひとつ分かったのが、ログインできない直接の原因です。サイトのログインを担う wp-login.php というファイルが、パーミッション(権限)が「000」=誰も読めない状態になっていました。だからサーバーがファイルを開けず、「Access denied」となっていたのです。

なぜそうなったのか。これはエックスサーバー(Xserver)の「Web改ざん検知」機能が、感染ファイルを見つけて自動的に無効化(000化)した跡でした。サーバー会社がマルウェアの活動を止めるための緊急措置です。
| ここで大事なポイント | 理由 |
|---|---|
| 000のファイルは権限を元に戻さない | 戻すとマルウェアが再び動き出し、再感染する恐れがあるため |
| 戻すのではなく「削除・置き換え」する | クリーンな正規ファイルに入れ替えるのが安全だから |
つまり「ログインできるように権限を戻す」のは最もやってはいけない対処です。ここを知らずに触ると、被害が再発します。同じ「ログインできない」でもパスワードやプラグイン由来の場合があり、切り分けはWordPressにログインできないときの対処法もあわせてご覧ください。
「不審な投稿」は本当にマルウェアの仕業?よくある誤解
データベースを確認すると、身に覚えのない投稿がずらりと並んでいました。多くの方は「マルウェアが勝手に記事を作ったに違いない」と考えます。私たちも当初その可能性を疑いました。
しかし1件ずつ精査した結果、その正体はお問い合わせフォームやコメント欄への迷惑メッセージ(スパム)でした。営業メールや海外からのスパムが自動投稿されていただけで、記事そのものへの改ざんではなかったのです。本来の投稿・固定ページはすべて無傷でした。
とはいえ、その量は相当なものでした。英語のスパムコメントが3,000件以上、フォームへのスパム送信が1,000件以上――長期間放置されていた間に、これだけの迷惑投稿が静かに溜まり続けていたのです。これらはマルウェアの仕業ではありませんが、放置が生んだ「もう一つの被害」と言えます。

そこで今回は、使われていなかったコメント機能そのものを閉鎖しました。コメント欄はスパムの入口であり、攻撃の起点にもなり得ます。事業で活用していないのであれば、思い切って閉じてしまうのが安全です。お問い合わせはフォームに一本化し、スパムフィルタもあわせて整えました。このように「不審な投稿=マルウェアの改ざん」と早合点しないことが、過剰な対応も見落としも防ぐコツです。
ここまでのまとめと、復旧の基本方針
ここまでを整理すると、今回の被害はサーバー上のファイルに仕込まれたバックドアに限定され、記事データそのものは無事でした。だからこそ復旧方針は明快です。サイトのプログラム一式を、クリーンな状態へまるごと入れ替えること。感染ファイルを1つずつ消す方法は、見落としによる再感染のリスクが残るためです。
ここから先は、実際に復旧を担当するエンジニアや制作会社の方に向けて、より具体的な手順とコマンドを交えて解説します。運営者の方は、最後の「同じ被害を防ぐためにできること」まで読み飛ばしていただいて構いません。
【技術解説】感染の特定と安全な除去の手順
バックドア型マルウェアの怖さは、本体を消しても「再感染用の裏口(ローダ)」が残っていると数時間で復活する点にあります。そのため、まず「何を消し、何を残すか」を確定させる調査が肝心です。今回のケースでは、次のポイントを確認しました。
- wp-content/uploads 配下に本来あるはずのない .php ファイルがないか
- wp-config.php や各テーマの functions.php に難読化コード(eval / base64_decode 等)がないか
- mu-plugins ディレクトリに不審なローダが仕込まれていないか
- 感染日前後の日時で作成・変更されたファイルがないか
- wp_users に身に覚えのない管理者、wp_options の active_plugins に不審な項目がないか
これらの捜索は、SSHが使えるなら次のようなコマンドで一気に洗い出せます。
|
1 2 3 4 5 6 7 8 |
# uploads配下のPHP(=ほぼ確実に不正)を洗い出す find wp-content/uploads -type f -name "*.php" # 難読化・裏口の常套句を全文検索する grep -rEl "eval\(|base64_decode|gzinflate|str_rot13" . --include="*.php" | head -50 # 感染が疑われる期間に作成・変更されたPHPを時系列で確認する find . -name "*.php" -newermt "2024-03-01" ! -newermt "2024-05-01" -printf "%TY-%Tm-%Td %p\n" | sort |
今回は幸い、mu-plugins は存在せず、wp-config.php も改ざんなし、.htaccess もクリーンでした。裏口は見つからず、侵入経路の WP File Manager(CVE-2020-25213 として知られる脆弱性)から直接設置された単独型のWebシェルと判断できました。なお、自動更新の跡で日付が新しいコアファイルは、推測で済ませず公式のチェックサムと照合して改ざんの有無を確定させます。
|
1 2 |
# WP-CLIが使えるなら、コアファイルを公式MD5と照合して改ざんを検出 wp core verify-checksums |
そのうえで、復旧の中核はpublic_html をまるごと作り直すことです。DBと、クリーンと確認できた uploads のメディアだけを残し、WordPress本体・テーマ・プラグインは公式の配布元から新規取得して置き換えます。上書きではなく「一度空にしてから新品を置く」のがポイントで、これにより見落としによる再感染をゼロにできます。侵入経路となった脆弱なプラグインは二度と導入しない――これが再発防止の最重要点です。
復旧で直面した、もう一つの壁――PHPのバージョン
実際の作業では、もう一つ現実的な壁にぶつかりました。サイトを動かす土台であるPHPのバージョンが、EOL(サポート終了)済みの非常に古いもの(7.0系)だったのです。
このまま最新のWordPressを置くとパースエラーで停止します。かといってPHPをいきなり最新へ上げると、今度は長年使ってきたテーマが対応しておらず、Fatal errorで停止してしまう。古いテーマには、PHP 8.0で削除された create_function() などが残っていることが多いためです。順序を誤ると確実に止まります。
| 手順 | ポイント |
|---|---|
| 1. 先にPHPを7.4へ | まず7.4で表示を確認。WPコアを置くのはこの後 |
| 2. テーマの互換を確認 | create_function / each / 旧構文の有無を grep で点検 |
| 3. 問題なければ8.2へ | テーマが対応できる場合のみ、段階的に引き上げる |
今回は安定動作を優先し、当面はPHP 7.4で運用、テーマの更新(または create_function の無名関数化)は将来の課題として残す形で着地させました。これは長く放置されたサイトほど「あちこちが古くなり、連鎖的に動かなくなる」という、放置の怖さを象徴する出来事でした。
再発防止:仕上げに必ず行う恒久対策
復旧の最後に、認証情報の総入れ替えと、攻撃の入口をふさぐ設定を行います。マルウェア侵入時はパスワードが抜かれている前提で、WP管理者・DB・FTP/SSH・サーバーパネル、そして wp-config.php の認証ソルトまで、すべて再発行します。ソルトを入れ替えると、攻撃者の不正ログインセッションも一括で無効化できます。
あわせて、メディアフォルダでのPHP実行を禁止しておくと、仮に再びファイルを置かれても実行を防げます。
|
1 2 3 4 |
# wp-content/uploads/.htaccess ―― uploads配下でのPHP実行を禁止 <FilesMatch "\.(php|phtml|php3|php4|php5|phps)$"> Require all denied </FilesMatch> |
マルウェアの除去手順そのものをもう少し体系的に知りたい方は、WordPressがマルウェアに感染したときの除去方法もあわせてご覧ください。
同じ被害を防ぐためにできること
今回の根本原因は「長期間の放置」でした。裏を返せば、日頃のちょっとした手入れで防げる被害だったということです。最低限、次の対策をおすすめします。
- WordPress本体・テーマ・プラグインを常に最新に保つ(自動更新の有効化)
- 使っていないプラグイン・テーマは「停止」ではなく「削除」する
- 古い・更新が止まったプラグインは使わない(脆弱性の入口になりやすい)
- 使っていないコメント機能は閉じる(スパムや攻撃の入口を減らせる)
- 管理者ログインに2段階認証を設定する
- サーバーの改ざん検知・WAFを有効にする
- 定期的なバックアップと、月1回でも更新・点検する運用を続ける
とはいえ、本業のかたわらでこれらを継続するのは簡単ではありません。自分で保守するか専門家に任せるかの判断はWordPressの保守は自分でできる?自社運用と外注の判断基準も参考になります。「気づいたときには手遅れだった」を防ぐには、専門家による定期的な見守りが確実です。
まとめ:手遅れになる前に、プロの目でチェックを
「WordPressにログインできない」という症状の裏に、マルウェア感染が潜んでいることがあります。今回のように被害範囲を正しく見極めれば、コンテンツを失うことなく復旧は可能です。ただし、権限000のファイルを安易に戻す・感染ファイルを1つずつ消すといった対処は、かえって再感染を招きます。マルウェアの除去は、自己流で触る前に専門家へ相談するのが安全です。
私たちEdel Heartsは、WordPressのマルウェア除去・復旧から、再発を防ぐ保守までを一貫して対応するWordPress専門チームです。「しばらくログインしていない」「更新が止まっている」――心当たりがあれば、手遅れになる前に一度ご相談ください。
- マルウェア感染・トラブルの緊急対応:WordPressトラブル対応サービス
- 感染を未然に防ぐ保守:WordPress保守サポート
- サイトの状態を無料でチェック:無料AI診断
- まずは相談してみたい方:お問い合わせフォーム