PHPの重大な脆弱性のニュースを受けて管理サイトを点検したら、別ルート(UpdraftPlusの脆弱性)で2サイトに不正プラグインが仕込まれていた。発見から復旧、お客様への報告までの一日の記録です。
10月21日、PHPに重大な脆弱性が見つかったというニュースが流れました。首相まで注意を呼びかける騒ぎになりましたが、正直に言うと、私はどこか**「よその大きいサイトの話」**だと思っていました。
そんな中、ホームページを担当しているお客様から1通のメールが届きました。
PHPのニュースで大騒ぎになっておりますが、ホームページは問題ないでしょうか。
これをきっかけに、管理しているサイトを1つずつ点検することにしました。結果、2つのサイトに不正なプログラム(バックドア)が仕込まれていました。
この記事は、その一日の記録です。同じようにWordPressサイトを管理している方の参考になれば幸いです。
前提：私の管理環境
- 管理しているWordPressサイトは十数サイト
- サーバーはすべてエックスサーバー
- 多くのサイトにバックアップ用プラグイン「UpdraftPlus」を導入
まずはPHPのバージョン確認から
今回のPHPの脆弱性は、修正版が 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 として公開されています。
エックスサーバーのような共用サーバーでは、こうした重大な脆弱性にはサーバー会社側で修正が自動適用されます。実際、確認したサイトはすべて PHP 8.3.36 になっていて、まずはひと安心でした。
各サイトでは、次の4点を確認していきました。
- サイトが普通に表示されるか
- 管理画面のユーザー一覧に、見覚えのないユーザーがいないか
- プラグイン一覧に、見覚えのないプラグインがないか
- 念のため、バックアップを取得
順調に「問題なし」が続いて、半分ほど終わったところで……。
「このサイトで重大なエラーが発生しました」
あるサイト(同じドメインの下にある、別のWordPress)を開いたところ、真っ白な画面に一文だけ。
このサイトで重大なエラーが発生しました。
WordPressからは「サイトで技術的な問題が発生しています」という通知メールが届いていて、原因のプラグイン名が書かれていました。
「Load Forge」
……聞いたことがありません。インストールした覚えもありません。
中身を見て確信した「これはバックドアだ」
サーバーのファイルマネージャーで plugins フォルダを開くと、load-forge というフォルダが確かにありました。更新日時は 10月19日 15:04。私はこの日、一日パソコンに触っていません。
中のPHPファイルを開いてみると、説明文には「Small maintenance toolkit(小さな保守ツール)」とそれらしいことが書かれていました。しかし中身は、
- 特定の合言葉付きのURLでアクセスすると
- 隠しユーザーを作成し
- そのユーザーに管理者級の権限を与えて
- その場でログインさせる
という、**完全な裏口(バックドア)**でした。
皮肉なことに、攻撃者のバグで助かった
サイトがエラーになっていたのは、攻撃者のコードに書き間違いがあったからです。存在しない値を参照していたせいで、WordPressが起動するたびにエラーで止まっていました。
つまり、
- バックドアは一度も動いていなかった
- バグがあったおかげで発見できた
ということです。もしバグがなければ、サイトは普通に表示され続け、私は今も気づいていなかったと思います。これが一番ゾッとした点です。
侵入経路は「PHP」ではなく「UpdraftPlus」だった
最初はPHPの脆弱性を疑いましたが、攻撃があったのは10月19日。PHPの脆弱性が公表される前の日付です。
SiteGuardのログイン履歴を見ると、10月19日にはログイン成功の記録が1件もありません。つまり、攻撃者はログイン画面を通らずに入ってきています。
決め手になったのは、エックスサーバーのアクセスログでした。10月19日の15:04前後を見ると、こんなアクセスがありました。
POST /〇〇〇/wp/ "WordPress/6.4; class-udrpc.php"class-udrpc.php は、UpdraftPlusの遠隔管理機能(UpdraftCentral)の通信部品です。調べてみると、UpdraftPlusにはこの部分の認証をすり抜けられる脆弱性 CVE-2026-10795 がありました。
- 対象：UpdraftPlus 1.26.4以前(無料版)
- 修正：1.26.5
- 内容：ログインなしで管理者として操作でき、プラグインのアップロード・有効化まで可能
- 実際の攻撃が多数確認されている
攻撃者はこの穴を使い、管理者になりすまして偽プラグインをインストールしていたのです。
2つ目のサイトも同じ手口
点検を続けると、もう1サイトで同じエラーが出ていました。今度のプラグイン名は 「Asset Suite」。
名前は違いますが、エラーの内容(同じ行の、同じ書き間違い)はまったく同じ。設置日時は 10月19日 15:59。最初のサイトの約1時間後です。
同じ攻撃者が、名前だけ変えて、同じサーバー上のサイトを順番に回っていたようです。
実際にやった対処の手順
同じ状況になった方のために、私がやった手順を順番に書いておきます。
① バックドアを取り除く
- 不正なプラグインのフォルダを、証拠としてダウンロードして保管してから削除
- サイトが表示されることを確認
② 侵入の痕跡を確認
- ユーザー一覧に見覚えのないユーザーがいないか
wp-content/mu-plugins/フォルダがないか(ここにも隠されやすい)pluginsフォルダを更新日時順に並べ、他に見覚えのないフォルダがないかuploadsフォルダに.phpファイルがないか(画像しか入らないはずの場所)
③ 締め出す
- WordPressの管理者パスワードを変更
wp-config.phpの認証用キー(SALT)を差し替え → ログイン中のセッションがすべて無効になる- データベースのパスワードを変更
💡 エックスサーバーの「簡単インストール」で入れたWordPressなら、サーバーパネルの「MySQLユーザ一覧」でDBパスワードを変更すると、
wp-config.phpも自動で書き換えてくれます。これはありがたかったです。
④ 原因を直す
- UpdraftPlusを最新版(1.26.13)に入れ直し
- UpdraftPlusの「高度なツール → UpdraftCentral」で、接続キーが登録されていないことを確認
⑤ 他のサイトも確認
- すべてのサイトで、UpdraftPlusのバージョンが1.26.5以上か
- すべてのサイトの
pluginsフォルダに、10月19日前後の見覚えのないフォルダがないか
気づいたこと・教訓
1. 「表示されている = 無事」ではない
今回はたまたま攻撃者のバグでエラーになったから気づけました。ちゃんと動くバックドアなら、見た目は何も変わりません。
点検では「表示」だけでなく、plugins フォルダの更新日時まで見ることが大事だと痛感しました。
2. ニュースになった脆弱性「以外」の穴もある
PHPの件で点検を始めたのに、実際の原因はUpdraftPlusでした。大きなニュースは、点検のいいきっかけになります。
3. 権限「000」はサーバー会社からのサイン
被害のあったサイトでは、updraftplus フォルダの権限が 000(鍵マーク付き)になっていました。サーバー会社が、危険なプラグインを止めてくれた跡だと思われます。ファイルマネージャーでこれを見かけたら、要注意のサインです。
4. お客様には、隠さず・不安をあおらず
報告メールでは、
- 何が起きたか
- 実害はあったか(なかったこと)
- 何をしたか
- お客様側でやることはない
の4点を、専門用語を減らして書きました。
5. 手順を一つずつ。バックアップは二重に
wp-config.php を書き換えるときは本当に怖かったです。作業前にダウンロードし、さらに複製しておいたおかげで、落ち着いて進められました。
おわりに
ニュースを見ていたときは、他人事だと思っていました。でも攻撃者は、大きいサイトか小さいサイトかなんて関係なく、同じ穴を持つサイトを機械的に回っています。
今回は運よく実害はありませんでした。それでも、「自分の管理サイトは大丈夫」という思い込みがいちばん危ないと身にしみた一日でした。
WordPressサイトを管理している方は、この機会にぜひ、
- UpdraftPlusのバージョン(1.26.5以上か)
pluginsフォルダの見覚えのないフォルダ
の2点だけでも確認してみてください。
