UpdraftCentralの鍵が悪用、UpdraftPlus導入サイトにバックドア

2026年10月19日、セキュリティ企業のNethembaとPatchstackが、WordPressのバックアッププラグイン「UpdraftPlus」に同梱されているリモート管理機能「UpdraftCentral」の鍵を使った攻撃を相次いで公表しました。攻撃者は有効なUpdraftCentralの秘密鍵で署名したコマンドを送り、接続済みのWordPressサイトにバックドア用のプラグインを導入しています。Patchstackのテレメトリでは、最初の導入は10月18日15:32に観測されています。UpdraftPlus本体の脆弱性ではなく、2026年10月19日時点でベンダーの修正は出ていません。UpdraftPlusを使っているなら、まずサイトに鍵が残っていないかを確認し、あれば削除するのが当面の対処です。

署名は本物なので、サイト側のチェックを通ってしまう
バックドアは「Editor」を名乗る管理者を作る
確認する4か所：鍵、プラグイン、ユーザー、ログ
まず鍵を消す。バックアップ機能は止まらない
バックドアが見つかったときの対処手順
両社の観測は重ならない。名前ではなく、説明文と権限で探す
出典

署名は本物なので、サイト側のチェックを通ってしまう

Patchstackの記事によると、攻撃者は署名付きの plugin.upload_plugin コマンドをサイトのルートへのPOSTリクエストで送り、WordPressの標準のインストーラ経由でプラグインを導入・有効化させます。コマンドは正規の秘密鍵で署名されているため、サイト側の検証はすべて通ります。このため、最新版のUpdraftPlusも影響を受けると、両社は書いています（バージョンは、Patchstackが1.26.11 / 2.26.11.26、Nethembaが2.26.11と表記）。

Nethembaは、ダッシュボード側の秘密鍵がUpdraftCentral Cloudの環境から漏れたと見ています。分かっていないのは漏れた経路で、根本原因の確定はこれからです。TeamUpdraftからは、記事公開時点で返答がないとのことです。自己ホスト型のダッシュボードが影響を受けるかどうかも未確認です。

バックドアは「Editor」を名乗る管理者を作る

導入されたバックドアは、リクエストの早い段階（init）で、URLパラメータに入った32文字のトークンを監視します。トークンが一致すると、固定のパスワードを持つ隠しアカウントを作り、Editorロールに加えて manage_options と install_plugins の権限を与え、ログイン用のCookieを発行してwp-adminへ誘導します。ログインフォームを通らないので、2要素認証やログイン試行の制限は働きません。

アカウントはユーザー一覧に「Editor」として表示されるため、見落としやすくなります。Patchstackは、アカウント名ではなく「Editorなのに manage_options を持っている」という権限の組み合わせで探すのが有効だと説明しています。プラグインを削除しても、作られたアカウントは残り、攻撃者はそのパスワードを知っています。

確認する4か所：鍵、プラグイン、ユーザー、ログ

両社が挙げた侵害の兆候のうち、サイト管理者が自分で確認しやすいものを整理します。

鍵：wp option get updraft_central_localkeys で出力があれば、そのサイトにはUpdraftCentralの鍵があります（Patchstack）。UpdraftCentralを使っていない人も確認の対象です。TeamUpdraft.comのアカウントを接続した場合、「UpdraftCentralに追加する」のチェックボックスが既定でオンで、知らないうちに鍵が作られていることがあるとPatchstackは指摘しています。
プラグイン：説明文が「Small maintenance toolkit」で始まるもの。Patchstackは、全文の「Small maintenance toolkit: keeps option storage tidy.」が最も確かなファイル単位の指標で、名前は「Site Health Cache」が繰り返し使われる以外は、ばらばらだと書いています。Nethembaが自社の3サイトで確認したフォルダ名は load-stack-35c と text-gantry-eb0 で、名前は手がかりにならないと考えたほうがよさそうです。
ユーザー：data-ops43、media-staff96 のようなユーザー名、メールアドレスが @example.org、表示名が「Site Tools」のもの。
ログ：UpdraftCentralのログに、probe.central.updraftplus.com に続いて Command received: plugin.upload_plugin が残っていないか。Nethembaによると、このログは直近50件で切れるため、Webサーバーのアクセスログも見る必要があります。手がかりは、攻撃元IPの 43.250.53.42、User-Agentが WordPress/6.4; class-udrpc.php のPOST、そして32文字のトークン付きのリクエストです。

Patchstackは、攻撃元のIPが2つ（IPv4とIPv6）あり、同時に使われ、1日のうちにインフラも切り替えられたと書いています。IPのブロックだけでは防げないので、鍵の削除を優先したほうがよさそうです。

まず鍵を消す。バックアップ機能は止まらない

両社が共通して勧めているのは、サイト側のUpdraftCentralの鍵を削除することです。wp-adminなら、設定 → UpdraftPlus Backups → Advanced Tools → UpdraftCentral から既存の鍵をすべて削除します。WP-CLIなら次のコマンドです。

wp option delete updraft_central_localkeys --skip-plugins --skip-themes

Nethembaによると、バックドアが入っているサイトではキャッシュ以外のすべてのリクエストが500エラーになり、WP-CLIも落ちます。そのため --skip-plugins --skip-themes を付けて実行します。両社とも、ダッシュボード側からの削除だけでは足りず、重要なのはサイト側に残っている鍵だと説明しています。鍵を消しても、バックアップの機能はそのまま動き、止まるのはリモート管理だけです。ベンダーが原因を説明するまでは再接続を避けること、修正版が出たあとも、攻撃者はすでに鍵を持っているため削除を勧めることも、Patchstackは書いています。

どうしてもリモート管理が要る場合は、install_plugins の権限を持たないアカウントで鍵を作る方法があります。Nethembaが調べた3サイトのうち1つは、鍵の持ち主にプラグインの導入権限がなく、攻撃が失敗しています。ただしPatchstackは、有効化されなかったサイトにもバックドアのファイルは届いていたので、それらも影響を受けたものとして扱うべきだとしています。権限を絞っても万全の対策ではありません。

バックドアが見つかったときの対処手順

PatchstackとNethembaが示す対処手順の要点は、次のとおりです。

先にUpdraftCentralの鍵を削除する。そうしないと、攻撃者が、不具合を直した（きちんと動く）バックドアを送り込める。
見つけたバックドアのプラグインのフォルダ（wp-content/plugins/<スラッグ>/）だけを、公開ディレクトリの外へ移す。wp-adminから削除すると、アンインストール処理が痕跡を消すおそれがある。UpdraftPlusなど、ほかのプラグインのフォルダは動かさない。
バックドアの <スラッグ>_sync_token という名前のDBオプション（例：load_stack_35c_sync_token）と、バックドアのアカウントを削除する。_sync_token で終わるというだけで、ほかのオプションを消さないよう注意する。

アカウントが存在する、またはアクセスログにトークン付きのリクエストがある場合は、サイトが完全に侵害されたものとして扱います。攻撃前のバックアップから復元し、クリーンなインストールとファイルを比較し、追加権限を持つユーザーをすべて確認します。管理者とUpdraftCentral Cloudのパスワード変更、全セッションの終了、2要素認証の有効化も勧められています。

なお、導入されたバックドアにはコードの不具合があり、Nethembaが調べた検体では、キャッシュ以外のすべてのリクエストが500エラーになりました。この不具合のせいでバックドアが動かなかったことが、被害に気づくきっかけになっています。Patchstackは、このエラーを「直す」とバックドアが動いてしまうので、修復せず削除するよう注意しています。

両社の観測は重ならない。名前ではなく、説明文と権限で探す

影響を受けたサイト数は、現時点で公表されていません。Nethembaは、6月に修正されたCVE-2026-10795（CVSS 8.1。1.26.4 / 2.26.4以前は、鍵がなくてもコマンドを偽造できる）に関するベンダーの推定として、UpdraftCentralまたはMigratorの鍵を持つサイトは全体の10%未満、最大で約40万サイトと書いています。今回の攻撃そのものの被害規模を示す数字ではありません。

Patchstackは、観測したバックドアのプラグイン名が99種類あったと書いています。一方、Nethembaが確認した2つの名前は、この一覧に入っていません。両社が観測した範囲は重なっておらず、命名規則もそろっていないので、名前でバックドアを探すのは当てになりません。

個人的に見落としやすいと思うのは、「鍵の有効期限」よりも「誰の権限で鍵を作ったか」です。UpdraftCentralは、鍵を作ったWordPressユーザーの権限で命令を実行します。Nethembaのサイトは、鍵の持ち主に導入権限がなかったために有効化に至りませんでした。それでも、ファイルが置かれること自体は防げません。検出は、説明文の1行と、「Editorなのに manage_options を持つ」という権限の組み合わせで行うのが確実だと考えます。受託でテーマやプラグインを納品する立場なら、クライアントのサイトにTeamUpdraftのアカウントを接続した覚えがあるかも、あわせて確認しておきたいところです。なお、Patchstackによると、鍵に有効期限はなく、2025年11月に発行された鍵が2026年10月にも有効でした。

別件ですが、直近のコアの更新として、WordPress 7.1.3のセキュリティ修正も確認しておいてください。今回のUpdraftCentralの件は、WordPressを更新しても防げません。