UpdraftPlus 脆弱性：接続キー流出の確認とバックドア除去・1.26.13更新

2026年10月17〜18日、WordPressのバックアッププラグインUpdraftPlusの開発元TeamUpdraftが不正アクセスを受け、遠隔管理機能UpdraftCentralの接続キーが流出しました。盗まれた鍵を使って、各地のWordPressにバックドア用のプラグインが入れられています。この記事では、影響を受けるサイトの条件、WP-CLIで鍵・偽装プラグイン・隠れた管理者を調べるコマンド、見つかった場合の除去順序を整理します。「UpdraftPlus 脆弱性」で確認しておきたい6月のCVE-2026-10795など過去のCVEと修正版も一覧にしました。内容は2026年10月24日時点の公開情報にもとづきます。

まとめ：1.26.13への更新だけでは消えないバックドアと鍵の削除・痕跡確認

UpdraftCentral Cloudにつないだことがあるサイトは、無料版・Premium版を問わず対象です。まず無料版1.26.13、Premium版2.26.13以上へ更新し、接続キーを削除します。更新は流出した鍵を失効させるだけで、すでに入れられたプラグインと作られたアカウントはそのまま残ります。

次に、偽装プラグイン、管理者権限を持つ編集者アカウント、アクセスログのトリガーを確認しましょう。1つでも見つかれば全面侵害として扱い、10月17日より前のバックアップから戻します。複数サイトの点検と復旧を手が回る範囲で済ませられないなら、WordPress保守・メンテナンスへの点検・復旧の依頼が可能です。バックアップの取り方と復元テストはWordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順にまとめています。

TeamUpdraft侵害によるUpdraftCentral接続キー流出と対象サイト

TeamUpdraftのインシデント報告によれば、攻撃者は顧客データベースに到達したとみられます。そこにUpdraftCentral・UpdraftVault・UpdraftCloneの接続情報も入っていました。UpdraftPlus本体の配布物とセルフホスト版のUpdraftCentralは影響を受けていません。

UpdraftCentral Cloud接続歴のある無料版・Premium版の対象サイト

エックスサーバーの10月20日の注意喚起は、影響版を無料版1.26.12以下、Premium版2.26.12以下とし、UpdraftCentralを使っているサイトが攻撃対象になると書いています。

見落としやすいのは、使っているつもりが無いサイトです。Patchstackの解析によると、teamupdraft.comのアカウントをプラグインにつなぐ画面には「UpdraftCentralにこのサイトを追加（5サイトまで無料）」のチェックが最初から入っています。鍵には有効期限が無く、2025年11月に発行された鍵が2026年10月でも使えた例が確認されています。UpdraftVaultの容量を買うためにアカウントを連携しただけのサイトも、鍵の有無を調べてください。

攻撃が観測された10月19日の時間帯と1.26.12・1.26.13の修正の違い

Patchstackが攻撃を観測したのは10月18日15時32分〜19日9時23分（UTC）、日本時間では19日0時32分〜18時23分です。国内では日曜の深夜から夕方にあたり、休日で監視が手薄な時間帯でした。

WordPress.orgの更新履歴では、1.26.12と1.26.13がどちらも10月19日付です。1.26.12は事案以前に作られたUpdraftCentral Cloudの鍵を失効させる版でしたが、1.26.13の記載は「1.26.12の失効を正しく適用する」修正でした。1.26.12で止まっているサイトは失効が効いていない前提で、1.26.13へ上げます。TeamUpdraftは英国時間10月18日13時7分（日本時間21時7分）より前の接続を失効の対象としています。

6月修正のCVE-2026-10795と今回の鍵流出を分けて考えるべき理由

6月に公表されたCVE-2026-10795は、UpdraftCentralとの通信で署名検証を回避でき、鍵が無くても管理者としてコマンドを偽造できたプラグインの欠陥です。1.26.5で修正されました。

10月の件はコードの欠陥ではありません。攻撃者は正規の鍵で署名したコマンドを送っており、プラグインから見れば正しい管理操作です。修正版に上げていても、鍵が残っていれば侵入されます。CVEの番号が付かない事案なので、脆弱性スキャナの結果だけを見ていると「該当なし」と判定されます。

盗まれた鍵で入れられたバックドアプラグインの挙動と隠れた管理者アカウント

TeamUpdraftの報告にはバックドアの名称が載っていません。以下はPatchstackが観測した検体の情報です。

Site Health Cacheなど99種類の偽装名と共通する説明文の手がかり

攻撃者はUpdraftCentralのplugin.upload_pluginコマンドで、WordPress標準のインストーラーからプラグインを入れて有効化しました。名前は「Site Health Cache」「Speed Kit」「Seo Helper」「Css Forge」のように保守や表示速度の改善を装い、観測されただけで99種類あります。

名前は使い回されないため、一覧の目視では見抜けません。Patchstackがファイル単位で最も確かな手がかりとして挙げるのは、説明文の「Small maintenance toolkit: keeps option storage tidy.」です。名前の中では「Site Health Cache」が繰り返し使われています。

編集者ロールにmanage_optionsを足して管理者一覧から外れるアカウント

バックドアはパスワードを埋め込んだアカウントを作ります。ロールは管理者ではなく編集者で、そのうえで設定を変えるmanage_optionsとプラグインを入れるinstall_pluginsを個別に付けます。管理画面で「管理者」を絞り込んでも出てきません。

観測されたユーザー名はdata-ops43やmedia-staff96のように「英単語2つ＋数字2桁」の形で、メールアドレスのドメインはexample.org、表示名は「Site Tools」でした。プラグインを消してもアカウントは残ります。名前が_sync_tokenで終わるオプションも作られます。

ログイン画面を通らず二要素認証を回避するトリガーと500エラーの理由

バックドアは、URLに「_」で始まる4〜10文字のパラメータと32文字のトークンが付いたリクエストを待ちます。合致するとログインフォームを通さずにCookieを直接発行するため、二要素認証やログイン試行の制限は働きません。

Patchstackが見た初期の検体には、トークンを照合する前に致命的エラーになるコードの誤りがありました。被害サイトがキャッシュの無いリクエストにHTTP 500を返したのはこのためです。Patchstackは「直すとバックドアが動き出す」として、修復ではなく削除を求めています。10月19日前後に原因不明の500が出たサイトは、真っ先に調べる対象です。

WP-CLIで接続キー・偽装プラグイン・隠れ管理者を確かめるコマンド手順

確認はSSHでWordPressの設置ディレクトリに入り、WP-CLIで行います。管理画面からも見られますが、編集者ロールのアカウントやMust-Useプラグインは目視で漏れやすいためです。

updraft_central_localkeysの有無で鍵の残存を確認するコマンド

UpdraftCentralの鍵はupdraft_central_localkeysというオプションに保存されます。中身が出力されれば、そのサイトは露出していました。

# 接続キーが残っているか（出力があれば露出していたサイト）
wp option get updraft_central_localkeys --format=json

# UpdraftPlusの版（1.26.13未満なら先に更新する）
wp plugin list --name=updraftplus --fields=name,status,version

Premium版はプラグインのスラッグが異なる場合があるので、–nameを外して一覧で版を確かめます。管理画面では「設定」の「UpdraftPlus」から「詳細ツール」を開き、「UpdraftCentral」のタブに鍵の一覧があります。

説明文と権限の個別付与から99種類のバックドアを洗い出すコマンド

プラグインは説明文で、アカウントは「編集者なのにmanage_optionsを持つ」条件で探します。SQLはPatchstackの解析に載っているものです。テーブル接頭辞がwp_でなければ書き換えてください。

# 1. 共通の説明文を持つプラグイン（Must-Useも含めて探す）
grep -rl "Small maintenance toolkit: keeps option storage tidy" \
  wp-content/plugins/ wp-content/mu-plugins/ 2>/dev/null

# 2. 有効・無効を問わずプラグインを説明文つきで一覧
wp plugin list --fields=name,status,version,description --format=csv

# 3. 編集者ロールなのにmanage_optionsを持つユーザー
wp db query "SELECT u.ID,u.user_login,u.user_email,u.user_registered
  FROM wp_users u JOIN wp_usermeta m ON m.user_id=u.ID
  WHERE m.meta_key='wp_capabilities'
    AND m.meta_value LIKE '%editor%' AND m.meta_value LIKE '%manage_options%'"

# 4. 名前が_sync_tokenで終わるオプション
wp option list --search="*_sync_token" --fields=option_name

wp plugin listはdescriptionを追加の項目として出せます。見覚えのない名前は、WordPress.orgと照合するwp plugin verify-checksums –allでも浮かび上がります。配布元に存在しないプラグインは照合に失敗するためです。

アクセスログのトリガーパラメータとUser-Agentを照合する方法

バックドアが使われたかどうかは、アクセスログで判断します。正規のUpdraftCentralの通信は、User-Agentの末尾に「class-udrpc.php/2.0; https://teamupdraft.com」のような版とURLが付きます。攻撃側の通信にはこれがありません。

# バックドアのトリガー（_xxxx=32文字のトークン）
grep -E '[?&]_[A-Za-z0-9]{4,10}=[A-Za-z0-9_]{32}([&"[:space:]]|$)' \
  /var/log/apache2/*access*

# 版とURLを持たないclass-udrpc.phpのUser-Agent（攻撃側）
grep 'class-udrpc\.php"' /var/log/apache2/*access*

nginxなら/var/log/nginx/に読み替えます。共用レンタルサーバーではログの保存日数が短い場合があるため、10月19日分が消える前に手元へ保存してください。攻撃元のIPアドレス（43.250.53.42など）も公開されていますが、Patchstackは送信元を変えられるのでIPの遮断は対策にならないとしています。

侵害が見つかった場合の除去順序と10月17日以前のバックアップからの復元

順序を間違えると、消したバックドアを入れ直されます。PatchstackとTeamUpdraftの推奨を、作業の順に並べました。

接続キーの削除を先にしてからバックドアを無効化・退避する5工程

1. wp option delete updraft_central_localkeys で接続キーを消す（残したままだと攻撃者が入れ直せる）
2. UpdraftPlusを無料版1.26.13、Premium版2.26.13以上へ更新する
3. バックドアのプラグインは管理画面から削除せず、ディレクトリごとWebルートの外へ移す
4. 見つかったアカウントと、名前が_sync_tokenで終わるオプションを削除する
5. 全管理者のパスワードを変え、全ユーザーのセッションを破棄して二要素認証を有効にする

3で管理画面の削除を使わないのは、アンインストール処理が痕跡を消すためです。ファイルは調査用に退避しておきます。アカウントはwp user deleteに–reassignで投稿の引き継ぎ先を指定して消し、セッションはwp user session destroyに–allを付けて全ユーザー分を破棄します。

アカウントかトリガーが見つかったサイトを全面侵害として扱う範囲

アカウントが存在した、またはログにトリガーが残っていたサイトは、バックドアが実際に使われたものとして扱います。この場合、上の5工程で止めてはいけません。攻撃者は管理者として他のファイルやデータベースにも手を入れられたからです。

10月17日より前に取ったバックアップから戻し、復元後にwp core verify-checksumsとプラグインの照合でコアと配布物の改ざんが無いことを確かめます。権限の追加されたユーザーが他にいないかも見直します。バックアップの世代が足りず17日以前に戻れないサイトは、今回を機に世代管理と外部保存の設計を見直してください。

UpdraftVault・UpdraftCloneと外部ストレージの認証情報の入れ替え

TeamUpdraftはUpdraftVaultの全接続を切り、新しい認証情報を発行しました。利用者は設定画面でVaultを選び直し、teamupdraft.comのメールアドレスと新しいパスワードでつなぎ直します。UpdraftCloneは旧キーがすべて無効になったため、キーを他者に渡していた場合だけ再発行が必要です。

Google Drive、Dropbox、Amazon S3などに置いたバックアップ自体は影響を受けていません。ただしUpdraftCentral経由で侵入されたサイトは、攻撃者が設定画面から保存先の認証情報を読めた可能性があります。保存先の再認証とアクセスキーの入れ替えまで済ませましょう。

「UpdraftPlus 脆弱性」で確認する過去のCVEと2026年の修正版一覧

300万以上のサイトで有効になっているプラグインなので、鍵の件とは別に、古い版のまま動くサイトが抱える穴も確認しておきます。

CVE番号が付いた脆弱性4件の影響版・修正版とCVSSの比較一覧

値はNVDの記載で、CVSSはWordfenceまたはNVDの評価です。

CVE-2026-10795は、復号の戻り値を確かめていないため暗号鍵がすべてゼロの予測できる値になり、認証なしで任意のRPCコマンドを管理者として実行できた欠陥です。悪用の前提は、UpdraftCentralの鍵か、有償版のMigratorの鍵が有効なことでした。TeamUpdraftの6月5日の告知は対象を利用者の1割未満と見積もり、更新できない場合のホットフィックス用プラグインも配っています。CVE-2022-0633は購読者アカウントで最新のサイトとDBのバックアップを落とせたもので、会員登録を受け付けるサイトほど影響が大きい種類です。

2026年8〜10月の更新履歴に並ぶ復元処理まわりのセキュリティ修正

CVE番号は付いていないものの、更新履歴には2か月で4回のセキュリティ修正が並んでいます。

• 1.26.9（10月14日）：管理者でない攻撃者が1MBを超えるデータを書き込めるサイトで、バックアップを復元すると任意のSQLが実行されうる問題（Wordfenceが報告）
• 1.26.10・1.26.11（10月15・16日）：上の問題の関連箇所と、まれなSQLモードNO_BACKSLASH_ESCAPESでの修正漏れ
• 1.26.8（9月17日）：移行後に.htaccessを直していないサイトで、ログインできる一般ユーザーがFTPなど保存先の認証情報を読める問題
• 1.26.7（8月21日）：外された元管理者が、現管理者にリンクを踏ませて古いバックアップを復元させる問題

いずれも1.26.13に含まれます。会員制サイトやコメント・フォームの投稿をDBに保存するサイトでは1.26.9の条件に当てはまりやすいので、鍵を使っていなくても更新は済ませてください。WordPress本体の脆弱性はwp2shell（CVE-2026-63030・CVE-2026-60137）の解説で扱っています。

判断：UpdraftCentralへ再接続する条件と、遠隔管理をやめる場面

TeamUpdraftは手順の最後に再接続を挙げていますが、Patchstackは原因が説明されるまで再接続しないよう勧めています。鍵に期限が無く、流出すれば発行元を問わず使われる以上、再接続するかは運用で決めます。

install_plugins権限の無い管理用アカウントで鍵を作れるなら再接続

再接続してよいのは、次の2条件を満たす場合です。1つ目は、鍵をinstall_pluginsを持たないアカウントで発行することです。UpdraftCentralのコマンドは鍵を作ったユーザーの権限で動くため、プラグインを入れられないアカウントなら、今回と同じ手口は通りません。Patchstackもこの方法を挙げています。

2つ目は、接続キーの有無とプラグイン一覧を定期的に確かめる仕組みがあることです。前の章のコマンドを週1回cronで回し、差分が出たら通知する程度で足ります。バックアップの取得だけが目的なら、遠隔管理は不要です。UpdraftCentralを外してもUpdraftPlusの定期バックアップは続きます。

多数のサイトを少人数で見る組織が遠隔管理を外部の保守へ移す判断

10サイト以上を1〜2人で見ていて、休日に攻撃が来たら月曜まで気づけない体制なら、自前で遠隔管理の鍵を持つのはやめるべきです。今回の攻撃は日本時間の日曜深夜から夕方にかけて行われ、更新を待つだけでは間に合いませんでした。

この場合は、サイトごとの鍵を削除して遠隔管理をやめるか、監視と更新を含めて保守を外部へ任せるかを選びます。内製と外注の分け方はWordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準に、更新とWP-CLIでの確認の組み方はWordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順にまとめました。

UpdraftPlusの鍵流出と脆弱性対応でよくある質問と回答

今回の事案と、UpdraftPlusの脆弱性対応で出てきやすい疑問に、10月24日時点の一次情報の範囲で答えます。

UpdraftCentralを使っていなければ対応は不要ですか？

鍵の件に限れば、鍵が1つも無いサイトは対象外です。ただし、teamupdraft.comのアカウントをつないだときにUpdraftCentralへの追加が既定でオンになっていたため、使っていないつもりでも鍵が作られている場合があります。wp option get updraft_central_localkeys か管理画面のUpdraftCentralタブで、鍵が無いことを確かめてから判断してください。

1.26.13に自動更新されていれば安全ですか？

更新は鍵を失効させ、その経路からの新たな侵入を止めるだけです。10月18〜19日にすでに入れられたプラグインとアカウントは消えません。自動更新が済んでいても、偽装プラグイン、編集者ロールで管理権限を持つアカウント、アクセスログのトリガーの3点は確認が必要です。1.26.12で止まっている場合は失効が正しく効いていないので、1.26.13へ上げます。

見覚えのないプラグインは管理画面から削除してよいですか？

勧められません。Patchstackは、アンインストール処理が痕跡を消すとして、無効化したうえでWebルートの外へ移すよう求めています。先に接続キーを削除しないと、攻撃者が鍵で同じプラグインを入れ直せる点にも注意します。コードの誤りでHTTP 500になっていても直してはいけません。直すとバックドアが動き出します。

レンタルサーバーの自動バックアップから戻せば十分ですか？

10月17日より前の世代が残っていれば、それを使えます。ただし共用サーバーの自動バックアップは保持日数が決まっており、確認が遅れるほど事案前の世代は消えていきます。契約中のプランの保持日数を先に確かめてください。戻したあとも接続キーが復元されるので、UpdraftCentralの鍵の削除とUpdraftPlusの1.26.13への更新は、復元のあとにもう一度行ってください。

UpdraftPlus以外のバックアッププラグインへ乗り換えるべきですか？

今回の件だけで乗り換える必要はありません。侵入経路は遠隔管理の鍵で、バックアップ機能や外部ストレージの仕組みが破られたわけではないからです。乗り換えを考えるべきなのは、遠隔管理を手放せず、かつ鍵を発行するアカウントの権限を絞れない場合です。プラグインを使わずサーバーのcronとWP-CLIでバックアップを組む方法もあります。

関連記事

• SEOポイズニングとは？仕組み・手口と2026年の攻撃事例・企業が取るべき対策：乗っ取ったWordPressが悪用される代表的な使われ方です。
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：開発元の侵害から利用者へ広がる攻撃の全体像です。
• Webシェルとは？Tomcatへの設置手口と検知・除去の手順をコマンド例で解説：設置されたバックドアを見つけて消す考え方を扱います。
• PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版・更新できない場合の設定：WordPressが動くPHP側の同時期の脆弱性です。
• WordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順：本体を安全に更新する手順をまとめています。