公式アップデートが感染源に：Rank Math PRO・UpdraftPlus・OVHcloud CLI・npmで続いた配布物の差し替えと、自分で確かめる手順

「ソフトは常に最新の版に更新しておきましょう」というのは、セキュリティの基本中の基本として繰り返し言われてきたことです。ところが2026年10月の前半から後半にかけて、その「更新」そのものが攻撃の入口になる事件が立て続けに起きました。具体的には、次の4つです。

• WordPressの人気SEOプラグイン「Rank Math PRO」の公式の更新にバックドア（裏口）が仕込まれ、バックアップ用プラグイン「UpdraftPlus」の運営元から盗まれた接続キーで、利用者のサイトに勝手にプラグインが入れられました。
• クラウド大手OVHcloudのコマンドラインツールは、GitHubに置かれた正式なリリースのファイルが、検証用のチェックサムごと差し替えられました。
• npmでは、本物の開発者のアカウントや公式の配布の仕組みを使って、情報を盗むプログラムが配られています。
• GitHub Actionsでも、本物の開発者のアカウントや公式の配布の仕組みを使って、情報を盗むプログラムが配られています。

どの事件にも共通しているのは、「偽物のサイトから怪しいファイルを落とした」のではなく、「いつもの公式の場所から、いつもの手順で受け取ったもの」が汚れていたという点です。利用者の側に落ち度があったわけではありません。むしろ、まじめに更新していた人ほど早く被害を受けた事件もあります。

この記事では、10月5日から19日までに起きた4つの系統の事件（Rank Math PRO、TeamUpdraft、OVHcloud CLI、npmとGitHub Actions）を、各社の公式の告知とセキュリティ会社の一次の分析をもとに整理します。

そのうえで、このブログ自体もWordPressで動いていることから、WordPressのサイトを運営している人が自分のサイトを確かめる具体的な手順を厚めに書き、最後に、CLIやnpmの部品を使う開発者が「公式から届いたもの」をどう確かめればいいのかをまとめます。

先に結論を書いておくと、次の5つです。

4つの事件を並べると見える「公式から届いた毒」

まずは、今回取り上げる事件を日付の順に並べておきます。いずれも、配布する側の仕組みやアカウントが乗っ取られ、正規の経路を通って利用者に届いた事件です。日時は主に協定世界時（UTC）で書いています。日本時間は9時間足してください。

表を見ると、「何が汚されたのか」は事件ごとにかなり違うことが分かります。Rank Math PROでは配布されるファイルそのもの、TeamUpdraftではサイトを操作するための鍵、OVHcloudではすでに公開済みのリリースのファイル、npmの2件では公開の手順や元のソースコードです。ただ、利用者の目から見ると、どれも「公式の場所から、公式の形で届いた」という点で同じです。

このように、ソフトの部品や配布の仕組みを汚して、それを使う大勢に被害を広げる攻撃を「サプライチェーン攻撃」と呼びます。サプライチェーンは、もとは部品の調達から製品の出荷までの流れを指す言葉です。

関連記事の「”Black October”の10日間」では、AIの部品として使われるPythonのライブラリ「LiteLLM」が汚された事件を取り上げましたが、今回の4つの系統もそれと同じ種類の事件です。この記事では、LiteLLMの件にはこれ以上触れず、WordPressとCLI、npmの側を掘り下げます。

なお、悪用については「攻撃の試みが観測された」のか「侵入が成功したことが確かめられた」のかを区別して書くようにします。今回の事件の多くは、汚れた配布物が実際に配られ、それを受け取ったサイトや機械があったことまでは確認されています。一方で、被害を受けたサイトや機械の数は、どの当事者もはっきりした数字を出していないものがほとんどです。

Rank Math PRO 3.0.123：11時間だけ配られた、自分で復活するバックドア

Rank Math（ランクマス）は、WordPressのサイトを検索エンジンに見つけてもらいやすくするための「SEOプラグイン」です。

BleepingComputerによると、無料版はWordPress.orgの公式ディレクトリで400万を超えるサイトに入っている人気のプラグインで、今回問題になったのは、その有料版「Rank Math PRO」でした。有料版は、WordPress.orgではなく、Rank Mathの公式サイトから配られ、プラグインの更新もRank Mathのサーバーから届く仕組みになっています。

何が起きたのか：Rank Mathの告知から

Rank Mathが公式サイトのナレッジベースに掲載した告知によると、2026年10月15日20時02分から16日7時12分（協定世界時）までの間に、Rank Mathの公式サイトからダウンロードされた、または更新として届いたRank Math PRO 3.0.123の一部のファイルに、悪意あるプログラムが入っていました。日本時間にすると、16日の朝5時02分から夕方16時12分までです。

BleepingComputerはこれを「11時間の窓」と表現しています。

Rank Mathは、問題のファイルをすぐに取り除き、汚れていない3.0.124を公開したと説明しています。影響を受けたのは「限られた数の利用者」としていますが、具体的な数は告知に書かれていません。

BleepingComputerは、影響を受けたサイトの数と最初の侵入の経路を問い合わせましたが、Rank Mathからは回答がなかったと伝えています。10月24日の時点でも、攻撃者がどうやってRank Mathの配布の仕組みに入り込んだのかは公表されていません。

バックドアは何をするのか

バックドアは、攻撃者があとで好きなときに入り込めるように、こっそり作っておく裏口のことです。Rank Mathの告知や、脆弱性の情報をまとめているWordfence（WordPress向けのセキュリティ製品の会社）の記録によると、今回のプログラムには次のような働きがありました。

• 感染したサイトに、継続して入り込める状態を作る
• 「rank1cdn.com」という攻撃者のドメインと通信する
• 誰かがサイトを訪れるたびに、隠したバックドアを作り直す（ファイルを消しても戻ってくる）
• データベースのパスワード、APIキーなど、Webサーバーから読める秘密の情報をさらす

3つ目の「作り直す」という性質が、この事件をやっかいなものにしています。プラグインを無効にしたり、3.0.124に更新したりしても、プラグインの外の場所に置かれた裏口や、データベースに書き込まれた設定は残ります。

そして、サイトに誰かが来るたびに、残った部分から裏口が作り直されます。Wordfenceの告知は、3.0.124を入れても、マルウェアがすでにほかの場所に作ったファイルやアカウント、定期実行のタスクは消えない、と注意しています。

この事件には、Wordfenceが脆弱性の識別番号CVE-2026-111862を付け、深刻度を表すCVSS（0〜10の点数で、10が最も深刻）で9.8としています。CVEは、世界共通で脆弱性に付ける通し番号のことです。

WordPressの脆弱性のデータベースを運営するPatchstackも10月17日に情報を載せ、「Rank Math SEO PROの配布の仕組みそのものへのサプライチェーン攻撃なので、仮想パッチ（攻撃の通信を手前で止めるルール）で防ぐことはできない」と書いています。サイトの手前で攻撃を止める仕組みは、外から来る攻撃を止めるためのものなので、正規の更新として入ってきたものには役に立たない、ということです。

痕跡（IOC）として公表されたもの

攻撃の痕跡を「IOC（侵害の指標）」と呼びます。Rank Mathの告知には、自分のサイトが感染していないかを確かめるための痕跡が、かなり具体的に書かれています。主なものを表にしておきます。

表の中の「wp_options」は、WordPressがサイトの設定を保存しておくデータベースの表です。「mu-plugins」は「必ず使うプラグイン（Must-Use plugins）」を置くための特別なフォルダで、ここに置かれたファイルは、管理画面のプラグイン一覧で無効にすることができず、自動で読み込まれます。攻撃者が裏口を置く場所としてよく使われます。

「crontab」は、サーバーで決まった時間ごとに命令を動かすための設定です。WordPressの中だけでなく、サーバーの側にまで仕掛けが及んでいる可能性があることが分かります。

BleepingComputerは、マルウェアの解析サイトVirusTotalに上がっていたPHPファイルが、これらの痕跡（XORの鍵の文字列、データベースの行の名前、cronの印、管理者アカウントの名前の付け方）を共有していると報じました。このファイルはバックドアを作る最初の段階のスクリプトのように見え、命令の実行やデータベースの書き換えのほか、AWS・Cloudflare・Google Cloud・Azureの認証情報やSSHの鍵を盗む機能も持っていたとされます。

ただし、このファイルは公式の告知には載っておらず、プラグインを通じて配られたものと同じかどうかは確認できていない、と記事自体が断っています。

「更新すれば直る」ではない理由と、公式の推奨

Rank Mathの告知は、自分のサイトの状況を3つに分けて、それぞれやることを示しています。

有効にしていたサイトについて、Rank Mathがまず勧めているのは、10月15日20時02分（協定世界時）より前に取ったバックアップから、サイトのファイルとデータベースの両方を戻すことです。日本時間では16日の5時02分より前のバックアップということになります。そのうえで、次の順に進めます。

1. セキュリティスキャンをかける
2. すべてのパスワードと認証情報を変える
3. 最後に3.0.124を入れ直す

また、3.0.124は、Rank Mathの公式サイトに自分で直接アクセスしてログインし、そこからダウンロードするよう求めています。Rank Mathは、ログインやダウンロードのリンクをメールで送ることはないので、そうしたメールは疑ってほしいとしています。事件のあとには、「対策版はこちら」と装ったニセのメールが出回ることがよくあるためです。

TeamUpdraft：プラグインは無事、盗まれたのは「遠隔操作の接続キー」

2件目は、WordPressのバックアップ用プラグインとして広く使われている「UpdraftPlus（アップドラフトプラス）」の運営元、TeamUpdraftの事件です。この件は、Rank Math PROとは仕組みがまったく違います。

配られたプラグインのファイルは汚れていません。盗まれたのは、多数のサイトをまとめて管理するための「接続キー」でした。

UpdraftCentralという遠隔管理の仕組み

UpdraftPlusには、「UpdraftCentral（アップドラフトセントラル）」という機能の受け口が組み込まれています。UpdraftCentralは、いくつものWordPressサイトを1つの管理画面からまとめて更新したり、バックアップを取ったりするための遠隔管理の仕組みです。

Web制作会社や、複数のサイトを持っている人が、サイトごとにログインし直さなくても作業できるようにするためのものです。TeamUpdraftが運営するクラウド版（UpdraftCentral Cloud）と、自分のサーバーで動かす版があります。

Patchstackの分析によると、サイトをUpdraftCentralの管理画面につなぐと、サイトの側で暗号の鍵の組（RSAの鍵ペア）が作られ、管理画面側の公開鍵が保存されます。それ以降、サイトは、管理画面側の秘密の鍵で署名された命令を、接続を作ったユーザーの権限で実行します。

命令が届くたびに人が確認する仕組みはありません。そして、クラウド版の場合、その秘密の鍵はTeamUpdraftのクラウドの側に置かれていました。

Patchstackは、次の点も指摘しています。

• この受け口がUpdraftPlusの無料版と有料版のすべてに含まれていること
• TeamUpdraftのアカウントにサイトをつなぐ画面で、接続キーを作るチェックボックスが最初から付いていたこと
• 作られたキーには有効期限がなく、2025年11月に作られたキーが2026年10月にも使えたこと

つまり、自分では遠隔管理を使っているつもりがなくても、以前にアカウントとつないだことがあれば、キーが残っている可能性があるということです。

TeamUpdraftの公式発表と、その後の更新

TeamUpdraftが公式ブログに出した告知によると、10月17日から18日の週末に、teamupdraft.comへの不正なアクセスが見つかりました。同社は侵入の経路を閉じ、すべてのアカウントをログアウトさせ、影響を受けた可能性のある鍵や認証情報を入れ替えています。

攻撃者が読んだとみられる顧客のデータベースには、次の情報が入っていました。

• 名前、メールアドレス、請求先住所、注文の履歴
• アカウントのパスワード（ハッシュという、元に戻しにくい形に変換したもの）
• 二段階認証の設定
• UpdraftCentral、UpdraftVault（同社のバックアップ保管サービス）、UpdraftClone（サイトの複製サービス）の接続キー

一方で、同社は次の点をはっきり書いています。

• カードの情報はStripeとPayPalが扱っているため、同社は保存していないこと
• UpdraftPlusのプラグインとそのダウンロードは汚されていないこと
• 利用者が自分で用意したGoogle Drive・Dropbox・Amazon S3などのバックアップの保管先も影響を受けていないこと
• 自分のサーバーで動かすUpdraftCentralも影響を受けていないこと

同社は、無料版のUpdraftPlus 1.26.13と、有料版のPremium 2.26.13を10月19日の夜（英国夏時間22時過ぎ、日本時間では20日の朝6時過ぎ）に公開しました。これらの版は、英国夏時間10月18日13時07分（協定世界時12時07分）より前に作られたUpdraftCentralの接続を切断するもので、WordPress.orgからは自動で更新が配られました。

国内では、エックスサーバーが10月20日に注意喚起を掲載し、影響を受ける版を無料版1.26.12以下、Premium版2.26.12以下として、管理画面の「設定 → UpdraftPlus → 詳細ツール → UpdraftCentral」で接続キーをすべて消すよう呼びかけています。

告知はその後も何度か書き足されています。

• 10月21日の追記では、攻撃者が漏れた鍵を使ったこと、攻撃を速めるためにAIが使われた疑いがあること、外部のセキュリティ会社を入れて警察にも連絡したこと、攻撃者がまだアクセスできる証拠はないことが書かれました。
• 22日の追記では、19日以降に作られた見覚えのない接続がないか、UpdraftCentralのサイト一覧を見直すよう求めています。

CSO Onlineによると、同社は英国の個人情報の監督機関（ICO）にも報告しています。

攻撃はどう行われたか：Patchstackの観測

Patchstackは、最初のバックドアの設置を10月18日15時32分（協定世界時）に観測し、19日9時23分までの約18時間にわたって攻撃が続いたと報告しています。攻撃を最初に見つけたのは、スロバキアのセキュリティ会社Nethembaで、自社のサイト3つが狙われ、そのうち2つに悪意あるプラグインが入れられたと報じられています。

攻撃者は、盗んだ鍵で署名した「plugin.upload_plugin」という命令をサイトに送り、WordPressにプラグインを入れさせて有効にしました。命令は本物の秘密の鍵で暗号化・署名されているので、サイト側のプラグインが行う確認はすべて通ってしまいます。

ここが、この事件のいちばん大事な点です。署名の確認は「その命令が正しい鍵の持ち主から来たか」を確かめる仕組みであり、鍵そのものが盗まれていれば、攻撃者の命令も「正しい命令」になってしまいます。

入れられたプラグインは、Patchstackが確認しただけで99種類の名前がありました。これはプラグインの名前の種類の数で、被害を受けたサイトの数ではない点に注意してください。被害を受けたサイトの数は、どこからも公表されていません。

Patchstackの分析によると、これらのプラグインは次のように動きます。

• サイトへのあらゆる通信の早い段階で動き、URLに付けられた32文字の秘密の値を待ち受ける
• その値が来ると、決まったパスワードを持つ「編集者」のアカウントを作り、設定の変更とプラグインの追加の権限を足す
• 長く有効なログイン用のCookieを渡して、ログイン画面も二段階認証も通さずにログイン状態にする
• プラグインを消しても、作られたアカウントは残る

Patchstackが痕跡として挙げているものを、表にしておきます。

これらの痕跡を確かめる具体的な方法は、後半の手順4で書きます。

「鍵を消しても終わりではない」

Patchstackも、TeamUpdraftも、CSO Onlineが引用した解説も、同じことを強調しています。接続キーを無効にしても、すでに入れられたプラグインや作られたアカウント、有効なままのログイン状態は消えません。

1.26.13への更新は「これから入られないようにする」ための手当てであり、「すでに入られたサイトを掃除する」ものではないということです。TeamUpdraftは、怪しい点があれば、10月17日より前のバックアップから戻すことを検討するよう勧めています。具体的な確かめ方は、後半の「WordPressのサイトを自分で確かめる手順」でまとめて書きます。

OVHcloud CLI：チェックサムごと差し替えられた約1時間半

3件目は、WordPressの外の話です。フランスのクラウド大手OVHcloudが、自社のクラウドを黒い画面（コマンドライン）から操作するために配っている「ovhcloud-cli」という道具が狙われました。

CLI（コマンドラインインターフェース）は、マウスで画面を操作する代わりに、文字の命令を打ち込んで操作する道具のことです。このCLIはGo言語で書かれており、GitHubの「リリース」という機能で、Windows・macOS・Linux向けに組み立て済みのファイル（バイナリ）が配られていました。

何が起きたのか：GitHubの告知とissueから

OVHcloudがGitHubに出したセキュリティアドバイザリー（GHSA-862f-55f5-vmvw、深刻度High）によると、10月19日の14時47分から16時21分（中央ヨーロッパ夏時間、協定世界時では12時47分から14時21分、日本時間では21時47分から23時21分）の間に、v0.11.0からv0.15.0までのリリースのバイナリが、悪意あるものに差し替えられていました。

アドバイザリーは公開されていた時間を約1時間33分、ダウンロードの数を約250件としています。フランスのIT-Connectは、これを「94分」と報じています。数え方の違いで、1分ほどずれています。

最初に気づいたのは、OVHcloudの顧客でした。GitHubの公開のissue（番号300）によると、この利用者は、自分のCI（コードを変更するたびに自動でテストやビルドを行う仕組み）で、Linuxのarm64向けのファイルのSHA-256というハッシュ値を固定して確かめていました。その値が合わなくなったことで、差し替えに気づいたのです。

issueには、v0.15.0の元のファイルと差し替え後のファイルのハッシュ値が並べて書かれています。

ところが今回は、そのchecksums.txtも一緒に書き換えられていました。つまり、ダウンロードしたファイルのハッシュ値を計算して、同じリリースのページにあるchecksums.txtと比べると、「一致する」という結果になってしまいます。差し替えに気づけたのは、事件の前に自分で記録しておいた値と比べていた利用者がいたからでした。

issueの報告者は、差し替えられたバイナリが、10月13日のコミット（ソースコードの変更の記録）から、コミットされていない変更を含んだ「汚れた」状態で作られていたこと、正規のビルドの手順で入るはずのバージョン番号が入っていなかったことも指摘しています。正規の仕組みで作られたものではなく、誰かが手元で作ったものが上げられていた、ということです。

原因：開発者の私物のMacに入った、VS Codeの拡張機能

アドバイザリーによると、原因は、OVHcloudの開発者の1人が、2025年10月に自分の私物のMacBookに、悪意あるVS Codeの拡張機能「color-picker-universal 2.8.91」を入れていたことでした。VS Codeは、プログラムを書くための人気の編集ソフトで、拡張機能を入れると色々な機能を足せます。

この拡張機能によって認証情報が盗まれ、パソコンの中にNode.jsで動く常駐のプログラムが残されました。盗まれた鍵を使って、リリースのバイナリが差し替えられたとしています。会社のノートPCは侵害されていないとみているそうです。

アドバイザリーは、この拡張機能が使っていた暗号資産（Solana）のウォレットが、「GlassWorm（グラスワーム）」と呼ばれる攻撃者に結び付けられているとしています。悪意あるコードの分析を公開しているOpenSourceMalwareも、同じアカウントで3月に個人のリポジトリが書き換えられていたことなどから、GlassWormの関与を指摘しています。

ただし、OpenSourceMalware自身、3月の書き換えと10月の差し替えが同じ人物によるものだとは証明できない、と断っています。

OVHcloudの創業者オクターヴ・クラバ氏は、X（旧Twitter）への投稿で、ソースコードやビルドの仕組み（CI/CD）は影響を受けておらず、根本の原因は、リポジトリで「リリースの書き換え不可（immutability）」の設定が有効になっていなかったことだと説明したと、IT-Connectは伝えています。十分な権限を持つアカウントなら、公開済みのリリースのファイルをGitHub上で直接書き換えられる状態だったということです。同社はこの設定をすべてのリポジトリに適用したとしています。

盗まれたもの：開発者のパソコンにある、ありとあらゆる鍵

アドバイザリーによると、差し替えられたバイナリには「envchecker」という情報を盗む部品が入っていて、次のようなものを集めていました。

• 編集ソフトとAIの道具の設定とデータベース：VS Code、Cursor、Continue、Sourcegraph Cody、OpenCode、Hermes、Claude
• クラウドの認証情報：AWS（S3を含む）、Google Cloud、Azure、DigitalOcean
• 基盤の道具の設定：Docker、Kubernetes、Terraform、npm
• SSHの鍵、.netrc（ネットワークのログイン情報を書いておくファイル）、Gitの全体の設定

集めたデータは、Solanaのブロックチェーンに書かれた情報から送り先を調べたうえで、特定のIPアドレスに送られていました。送り先を直接プログラムに書かず、ブロックチェーンの記録に置いておくのは、送り先を後から自由に変えられるようにするためです。アドバイザリーも、送り先はいつでも変わりうると注意しています。

確かめる手がかりとして、アドバイザリーは、実行するたびに一時フォルダに「envchecker-」に9〜10けたの数字が続く名前のフォルダができ、それが消されずに残ることを挙げています。また、付録に各OS向けの悪意あるバイナリのハッシュ値（MD5）を載せています。

OVHcloudは、期間中に影響を受けた版を動かした機械にあった秘密の情報は、すべて漏れたものとして扱うよう求めています。具体的には、次のことです。

• バイナリを消してv0.16.0以降を入れる
• 上に挙げたクラウド、SSH、Git、Docker、Kubernetes、AIの道具の認証情報をできるだけ早く交換する
• 送り先のIPアドレスをできる範囲で遮断する
• 問題の拡張機能を入れていた場合は、常駐のプログラムを調べる

一方で、影響を受けなかった使い方もはっきりしています。次の図に、影響を受けなかった使い方と、受けた使い方を分けて示します。

go installの件は、IT-Connectによる指摘です。逆に、IT-Connectは、指紋を確かめない導入用のスクリプトや手でのダウンロードは影響を受けたと指摘しています。OpenSourceMalwareは、Dockerのイメージ（ovhcom/ovhcloud-cli）はOVHcloudの社内の仕組みで作られており、GitHubのリリースのファイルを使っていないため影響はなかったとしています（同社は独自には確かめていないと断っています）。

v0.16.0で何が変わったか

OVHcloudは、v0.16.0を「署名付きのタグ」と「書き換え不可のリリース（immutable release）」として公開しました。GitHubの公式の説明によると、書き換え不可のリリースでは、公開したあとにタグが特定のコミットに固定されて動かせなくなり、添付されたファイルも変更や削除ができなくなります。

さらに、リリースの「証明（attestation）」が自動で作られます。これは、タグ、コミット、ファイルの組み合わせを、暗号の仕組みで後から確かめられるようにした記録です。

ただし、GitHubの説明には「書き換え不可は、これから公開するリリースにだけ適用される」とも書かれています。設定を有効にしても、それ以前に公開したv0.10.0からv0.15.0までのリリースは、書き込みの権限を持つアカウントなら今も技術的には書き換えられる、とIT-Connectは指摘しています。設定を変えたからといって、過去の配布物までさかのぼって守られるわけではない、という点は覚えておくとよさそうです。

npmとGitHub Actions：SubQuery、Tensorlake、GhostActionの新しい波

4つ目の系統は、JavaScriptの部品の配布所であるnpmと、GitHubの自動化の仕組みであるGitHub Actionsで起きた事件です。npmは、Node.js（サーバーなどでJavaScriptを動かすための仕組み）向けの部品を、命令ひとつで取り込めるようにする公式の配布所です。

GitHub Actionsは、リポジトリに変更があったときなどに、テストやビルド、公開の作業を自動で動かす仕組みで、その手順を書いた設定ファイルを「ワークフロー」と呼びます。

10月5日：@subql/common 5.8.3（公開の手順の乗っ取り）

SubQuery（サブクエリ）は、ブロックチェーンのデータを読みやすい形に整えて、アプリから使えるようにするための仕組みです。その部品のひとつ「@subql/common」の5.8.3が、10月5日11時56分（協定世界時）にnpmで公開されました。

StepSecurity（GitHub Actionsの安全を守る製品の会社）の分析によると、この版は、本体のソースコードに悪意ある変更が入ったのではなく、公開の手順が乗っ取られて作られたものでした。

攻撃者は、一時的なブランチ（本流から分けた作業用の枝）で、公開用のワークフローを、手で起動する「試験版（カナリア）」用のものに書き換えました。その後の流れは、次のとおりです。

• まず11時24分に、中身は5.8.2と同じ試験版を公開して手順を確かめた
• 続く11時52分のコミットで、公開の直前に外部のサイト（ci-artifacts.dev）から圧縮ファイルを取ってきて、部品の中身を丸ごと置き換える手順を足した
• そして11時56分に5.8.3が公開された

この取り込みには、ハッシュ値や署名の確認がありません。

仕込まれたプログラムは、部品を入れるとき（npmのpostinstallという「インストールの後に自動で動く命令」）と、プログラムからこの部品を読み込んだとき（import時）の両方で動くようになっていました。StepSecurityは、インストール時の命令を止めるだけでは足りないと注意しています。

働きとしては、npm・AWS・SSH・Kubernetesなどの認証情報の収集、LinuxのGitHub Actionsの実行環境のメモリからの秘密情報の読み出し、クラウドやKubernetes、Vault（秘密情報の保管庫）からの収集、盗んだトークンで触れるリポジトリへのワークフローの追加、外からの命令の実行が挙げられています。ただし、これらは分析で分かった「できること」であり、特定の機械から実際に盗まれたことを確かめたものではない、とStepSecurityは書いています。

この件で注意したいのは、ほかのSubQueryの部品（@subql/cli 6.6.3、@subql/node-core 19.3.1など）が、「~5.8.2」という書き方で@subql/commonに依存していたことです。この書き方は「5.8.2以上、5.9未満」を意味するので、自動で5.8.3が選ばれる可能性がありました。自分で@subql/commonを直接入れていなくても、ほかの部品を通じて間接的に入っていた可能性がある、ということです。

10月8日：tensorlake 0.5.144（Shai-Hulud系のワーム）

Tensorlake（テンソルレイク）は、AIのアプリで使う文書の処理などを提供するサービスで、そのTypeScript（JavaScriptに型を足した言語）向けの公式の部品が「tensorlake」です。Socketによると、週に約1万2,000回ダウンロードされています。

その0.5.144が、10月8日1時12分（協定世界時）にnpmで公開されました。Socketはこれを公開から約11分後の1時23分に見つけています。

攻撃者の動きは、資料によって細部の説明が少し違います。

• Endor Labsの分析によると、攻撃者はまず10月7日にプロジェクトの本流のブランチを書き換え、あとは正規のGitHub Actionsの公開の仕組みに任せて公開させました。原因として最も可能性が高いのは、メンテナー（部品を管理する人）のアカウントの乗っ取りだとしています。
• Snykは、リポジトリの管理者のアカウントで本流に直接コミットされたと説明しています。

npmからはすでに削除されていて、0.5.143が汚れていない版とされています。

この版には、インストールの前に自動で動く命令（preinstall）が足されていて、部品を読み込まなくても、入れるだけで動きました。中身は、Bunという別のJavaScriptの実行環境の上で動く、情報を盗み、自分を広げる「ワーム」です。

ワームは、感染した先から次の感染先へ自分で広がっていくプログラムのことで、今回は、盗んだnpmのトークンで公開できる別の部品を探し、汚れた版を公開し直す働きを持っていました。こうした働きは、2025年に大きな騒ぎになった「Shai-Hulud（シャイ・フルード）」と呼ばれるワームの系統に当たるとされ、Socketは、以前のShai-Huludの波で見られた文字列がコードに含まれていたと書いています。

盗む対象として、Socketは次のものを挙げています。

• npm・GitHub・AWS・Vault・Kubernetesの認証情報
• SSHの鍵
• .envファイル
• 暗号資産のウォレット
• メッセージアプリのデータ
• Claude・Cursor・Kiro・Windsurf・ZedといったAIの道具の設定やMCPの設定ファイル

MCPは、AIの道具がほかのサービスとつながるための仕組みで、その設定ファイルには鍵が書かれていることがよくあります。リポジトリに.claude/settings.jsonや.vscode/tasks.jsonを書き込み、Claude CodeやVS Codeでそのプロジェクトを開いたときにまた動くようにする仕掛けも報告されています。

トークンを無効にすると、ホームフォルダが消される

tensorlakeの件で、普段の対応の順番を変えなければならない点がひとつあります。このワームは、盗んだGitHubのトークンがまだ使えるかどうかを定期的に確かめる「見張り役」を、パソコンに常駐させます。

Socketによると、この見張り役が動いている間にトークンを無効にすると、攻撃者が用意した処理が動き、利用者のホームフォルダ（自分のファイルが入っている場所）が消されます。どこからトークンを無効にしても同じだとしています。

そのため、Socketは「トークンを無効にする前に、まず見張り役を取り除く」よう求めています。Socketが示している場所は次のとおりです。

• Linux：「gh-token-monitor.service」を止めて無効にし、「~/.config/gh-token-monitor/」を消す
• macOS：「~/Library/LaunchAgents/com.user.gh-token-monitor.plist」を読み込み解除する
• Windows：ログオン時に動く「monitor.ps1」のタスクを消す

来歴（プロベナンス）が付いていても、中身は汚れていた

tensorlakeの汚れた版には、正規のGitHub Actionsで作られたことを示す、有効な「来歴（プロベナンス）」の記録が付いていました。

npmのプロベナンスは、部品が「どのリポジトリの、どのコミットから、どのワークフローで作られたか」を、Sigstoreという署名の仕組みで記録するものです。手元のパソコンで勝手に作られて上げられた部品を見分けるのには役立ちます。

しかし、Endor Labsが書いているとおり、プロベナンスは「どこで作られたか」を確かめるもので、「元のソースコードが安全だったか」は確かめません。本流のブランチそのものが書き換えられ、正規の仕組みで作られれば、来歴の記録はきちんと付いてしまいます。

SubQueryの件でも、試験版にはプロベナンスの記録が付いていました。来歴の記録は大事な手がかりですが、それだけで「安全」と判断することはできません。

GhostActionの新しい波（10月7〜9日）

GhostAction（ゴーストアクション）は、乗っ取った開発者のアカウントで、リポジトリに秘密情報を送り出すワークフローを足していく攻撃の呼び名です。最初の波は2025年9月に報告されました。

StepSecurityの10月9日の報告によると、10月8日に、次の2つのアカウントのリポジトリに、悪意あるワークフローが足されました。内容を表にまとめます。

10月9日の時点で、378のリポジトリで悪意あるワークフローが本流に残っていたとしています。StepSecurityは、これらは攻撃者のアカウントではなく、被害者のアカウントだと断っています。

足されたワークフローは「security-audit.yml（Security Audit）」「github_actions_security.yml（Github Actions Security）」などの、いかにも安全のための設定らしい名前でした。働きは2つあります。

• リポジトリに登録されたGitHub Actionsの秘密情報（npmやPyPIに部品を公開するためのトークンなど）を送り出すこと
• 今回の波で新しく加わったもので、リポジトリのすべてのブランチの、すべての履歴（git log -p --all）を調べて、AWS・Anthropic・OpenAI・OpenRouter・GitHub・GitLab・Google・Slack・SendGridの鍵など13種類の型に合う文字列を探し、送り出すこと

過去に一度コミットしてから消した鍵も、履歴には残っているので見つかってしまいます。

Socketは、その後の追記で、10月7日以降に500を超えるGitHubのアカウントがこのワークフローを数万のリポジトリにコミットしたと書いています。ただ、この数字はCloud Security Allianceの解説で「上限に近い見積もり」として扱われており、独立した確認は見当たりません。

10月9日の時点で、SocketはPyPIやcrates.io（Rustの部品の配布所）に汚れた版が公開された様子は観測していないとしています。もっとも、公開用のトークンが盗まれた以上、交換するまでは、次の汚れた版がいつ出てもおかしくない状態です。

なぜ「公式だから安全」が崩れたのか：チェックサム・署名・来歴の違い

4つの系統の事件を並べると、「ダウンロードしたものが本物かどうかを確かめる」ための仕組みが、それぞれ違う形で役に立たなかったことが分かります。ここで、よく使われる確かめ方を整理しておきます。

「同じ場所から届いた値」どうしで比べても意味がない

OVHcloudの件が教えてくれるのは、「ファイルと、それを確かめるための値が、同じ場所から同じ人によって置かれている」場合、その場所が乗っ取られれば両方とも差し替えられてしまう、ということです。チェックサムは、もともと「ダウンロードの途中でファイルが壊れていないか」を確かめるためのもので、配布元そのものが乗っ取られた場合を想定したものではありません。

確かめる値は、ファイルとは別の場所、別の仕組みから手に入れる必要があります。たとえば、次のようなものです。

• 事件の前に記録しておいた値（今回のCIのように）
• 配布元とは別の透明性の記録（誰でも後から確かめられる、書き換えられない公開の記録）に残された署名
• GitHubの書き換え不可のリリースに付く証明

Go言語の部品をgo installで入れる場合には、Goの公式のチェックサムデータベース（sum.golang.org）で、一度公開された版の中身が後から変わっていないかが確かめられます。OVHcloudの件で、go installで入れた人が影響を受けなかったのは、タグが書き換えられていなかったことに加えて、こうした仕組みの違いもあります。

署名は「鍵の持ち主」しか保証しない

署名は、チェックサムより一歩進んだ仕組みです。配布元だけが持っている秘密の鍵で署名し、利用者は公開されている鍵でそれを確かめます。配布ページが乗っ取られても、秘密の鍵が盗まれていなければ、攻撃者は正しい署名を作れません。

WordPressの本体の更新にも、2019年のWordPress 5.2から署名の確認が入っています。

ただし、TeamUpdraftの件のように、秘密の鍵そのものが盗まれてしまえば、署名は攻撃者の命令を「正しいもの」として通してしまいます。しかも、UpdraftCentralの鍵には有効期限がなく、1つの場所（クラウドの側）に大量の鍵がまとまって保管されていました。署名の仕組みの強さは、「鍵をどこに、どれだけの期間、どれだけの数まとめて置いているか」で決まると言えます。

来歴と「再現可能ビルド」

来歴（プロベナンス）は、「この部品は、このリポジトリのこのコミットから、このワークフローで作られた」という記録です。手元のパソコンで勝手に作られたものを見分けられるので、OVHcloudの件のような「誰かが手元で作ったバイナリを上げた」差し替えには効果があります。一方で、tensorlakeのように、元のソースコードやワークフローそのものが書き換えられた場合には、来歴は「正しく」付いてしまいます。

もうひとつ、よく話題になるのが「再現可能ビルド（reproducible build）」です。同じソースコードから、誰が、どの機械でビルドしても、まったく同じバイナリができるようにする取り組みのことです。

これができていれば、配布されたバイナリと、自分でソースコードからビルドしたものを比べて、ハッシュ値が一致するかを確かめられます。OVHcloudの件では、差し替えられたバイナリに正規のビルドなら入るはずのバージョン番号がなく、コミットされていない変更を含んでいたことが手がかりになりました。ビルドの中身を後から比べられること自体が、差し替えを見抜く力になるということです。

どの仕組みにも得意なことと苦手なことがあり、ひとつだけで安全を保証できるものはありません。だからこそ、いくつかを組み合わせ、さらに「出たばかりのものをすぐには入れない」「入れたものを後から棚卸しできるようにしておく」といった運用で補うことが大切になります。

WordPressのサイトを自分で確かめる手順

ここからは、WordPressのサイトを運営している人が、今回の2つの事件の影響を受けていないかを確かめる手順です。このブログもWordPressで動いているので、自分のサイトを確かめるつもりで書いていきます。PHPの更新やバックアップの取り方、管理画面の守り方といった一般的な話は、関連記事「このブログもPHPで動いています」で扱ったので、ここでは今回の事件に絞ります。

手順の中には、WP-CLI（WordPressを黒い画面から操作する公式の道具）のコマンドが出てきます。レンタルサーバーでSSH（サーバーに文字の命令で接続する仕組み）が使える場合は、サイトのフォルダに移動してから実行してください。

SSHが使えない場合は、管理画面とサーバー会社のファイルマネージャー、phpMyAdmin（データベースをブラウザで操作する道具）で同じことを確かめられます。作業の前に、今の状態のバックアップを1つ取っておくと、あとで調べ直すときに役立ちます。

手順1：Rank Math PROとUpdraftPlusが入っているか、版は何か

まず、管理画面の「プラグイン」の一覧で、Rank Math PRO（「Rank Math SEO PRO」と表示されます）とUpdraftPlusが入っているか、版の番号はいくつかを確かめます。WP-CLIならwp plugin listで一覧を出せます。無料版のRank Math SEOだけを使っている場合、Rank Math PROの件の対象にはなりません。

Rank Math PROが入っている場合は、10月16日前後に3.0.123に更新されたかどうかが分かれ目です。自動更新にしていた場合や、16日の日中（日本時間）に手で更新した場合は、期間に当たっている可能性があります。いつ更新したか分からない場合は、サーバーのファイルの更新日時（rank-math-proフォルダの中のファイル）や、操作の記録を残すプラグインのログを見ると手がかりになります。

手順2：Rank Math PROの痕跡を探す

3.0.123に当たっていた可能性がある場合は、Rank Mathが公表した痕跡を探します。確かめる場所と方法を、表にまとめます。

データベースで値が返ってきたら、感染しているものとして扱います。テーブルの名前の頭（wp_）は、サイトによって違う場合があります。

手順3：UpdraftPlusの接続キーが残っていないか

UpdraftPlusが入っているサイトは、版の番号に関係なく、UpdraftCentralの接続キーが残っていないかを確かめます。Patchstackは、遠隔管理を使ったことがないと思っていても確かめるよう勧めています。WP-CLIならwp option get updraft_central_localkeysで確かめられ、何か値が返ってくれば、キーが残っているということです。

管理画面では、「設定 → UpdraftPlus Backups → 詳細ツール（Advanced Tools）→ UpdraftCentral」の画面で、作られているキーの一覧を見られます。使っていないキーはここで削除します。WP-CLIならwp option delete updraft_central_localkeysですべて消せます。

Patchstackは、UpdraftCentralの管理画面の側からサイトを外すだけでは足りず、サイトの側のキーを消す必要があるとしています。キーを消しても、バックアップの機能はそのまま使えます。

そのうえで、UpdraftPlusを1.26.13（Premiumなら2.26.13）以降に更新します。遠隔管理を引き続き使いたい場合は、TeamUpdraftの案内どおり、キーを消して更新してから接続し直します。Patchstackは、どうしても遠隔管理を使うなら、プラグインを追加する権限（install_plugins）を持たないアカウントでキーを作るよう勧めています。そうすれば、鍵が盗まれても、プラグインを入れる命令は通りません。

手順4：UpdraftCentral経由のバックドアの痕跡を探す

接続キーが残っていた場合は、すでに何か入れられていないかを確かめます。プラグインの一覧で、次のようなものがないかを見ます。

• 「Small maintenance toolkit: keeps option storage tidy.」という説明文のプラグイン
• 「Site Health Cache」という名前のプラグイン
• 入れた覚えのない2〜3語の名前のプラグイン

管理画面の「プラグイン」の一覧の上にある「使用必須」（mu-plugins）のタブも忘れずに確かめてください。TeamUpdraftも、使用必須のプラグインを含めて見るよう求めています。

アカウントの側では、wp user listで全員の一覧を出し、「data-ops43」のような「単語＋単語＋2けたの数字」の名前、@example.orgのメールアドレス、「Site Tools」という表示名のアカウントがないかを確かめます。今回のバックドアは管理者ではなく「編集者」としてアカウントを作り、そこに権限を足していたので、管理者だけでなく編集者の一覧も見る必要があります。

アクセスのログが見られる場合は、User-Agent（アクセスしてきた道具の名乗り）が「class-udrpc.php」になっている通信や、UpdraftCentralのログに「Command received: plugin.upload_plugin」という記録がないかも手がかりになります。レンタルサーバーなら、管理画面からアクセスログをダウンロードできることが多いです。

バックドアのプラグインが見つかった場合、Patchstackは次の順番を勧めています。

1. まず接続キーを消す
2. 次にプラグインを無効にし、管理画面から削除するのではなく、Webで公開されている場所の外にファイルを移す（調べるための証拠として残すため）
3. 「_sync_token」で終わる設定をデータベースから消し、作られたアカウントを消す
4. アカウントが作られていたり、ログに合図の通信が残っていたりした場合は、サイト全体が侵害されたものとして扱い、事件前のバックアップから戻す

手順5：感染していたら、何を交換するか

どちらの事件でも、感染していた場合は、バックアップから戻したあとにパスワードと鍵の交換が必要です。漏れたものとして扱うべきものを、立場を問わず挙げておきます。

• WordPressのすべての管理者・編集者のパスワード。ほかのログインしている端末をすべてログアウトさせる
• wp-config.phpのデータベースのパスワード（サーバーの管理画面でデータベースのユーザーのパスワードを変え、wp-config.phpも書き換える）
• wp-config.phpのセキュリティキーとソルト（WordPress.orgの公式の生成ページで新しい値を作って入れ替えると、全員のログイン状態が切れる）
• サイトに登録しているAPIキー（Googleのサービス、メール送信、決済、AIのサービスなど）
• サーバーの管理画面、FTP、SSHのパスワードと、SSHの公開鍵の一覧（authorized_keys）に見覚えのないものがないか
• UpdraftPlusを使っていた場合は、バックアップの保管先（Google Drive、Dropbox、S3など）の接続のやり直しと、アクセスキーの交換

セキュリティキーとソルトは、WordPressがログイン状態を覚えておくためのCookieを作るときに使う秘密の値です。これを入れ替えると、攻撃者が持っている長く有効なログイン用のCookieも使えなくなります。TeamUpdraftの件のバックドアは、長く有効なCookieでログイン状態を作っていたので、ソルトの入れ替えは特に意味があります。

仕上げに、Rank Mathの告知が勧めているとおり、Wordfenceなどのセキュリティプラグインでスキャンをかけ、wp core verify-checksumsとwp plugin verify-checksums --allを実行します。ただし、プラグインのチェックサムの確認は、WordPress.orgで配られているプラグインしか対象になりません。Rank Math PROのような有料のプラグインは、公式サイトから落とし直した汚れていないファイルと比べる必要があります。

そして数日の間は、消したファイルやアカウントがまた現れないかを見張ります。現れた場合は、まだどこかに仕掛けが残っているということなので、もう一度探すか、専門家に頼むことを考えます。

手順6：レンタルサーバーの利用者が頼れるところ

共用のレンタルサーバーでは、サーバーのcrontabやプロセスの一覧、ほかの利用者の領域などを、自分では確かめられないことがあります。Rank Mathの告知も、共用サーバーではサーバー会社に相談するよう書いています。

国内では、エックスサーバーがUpdraftPlusの件で注意喚起を出したように、サーバー会社が情報を出している場合があるので、自分の契約しているサーバー会社のお知らせを確かめておきましょう。サーバー会社が提供する自動バックアップから、事件の前の日付を選んで戻せる場合も多いので、保存されている期間を確かめておくと安心です。

有料プラグイン・CLI・npmの部品を使う人が、これからやっておくこと

最後に、今回の事件を踏まえて、普段から何をしておけばいいかを、立場ごとにまとめます。どれも、「公式から届いたものでも汚れていることがある」という前提に立った備えです。

WordPressのサイトを運営している人

WordPress.orgで配られている無料のプラグインと、開発元のサイトから配られる有料のプラグインとでは、更新の届き方が違います。

入れているプラグインのうち、どれがどこから更新を受け取っているのかを把握しておくだけでも、事件が起きたときの判断が速くなります。

自動更新をどうするかは悩ましいところです。Rank Math PROの件では、自動で更新していたサイトほど早く汚れた版を受け取りました。一方で、自動更新を切って放っておけば、既知の脆弱性が残ったままになります。

現実的なのは、重要なサイトでは、プラグインの更新が出てから1日か2日様子を見てから当てる、という運用です。今回のRank Math PROは約11時間、OVHcloudは約1時間半で取り下げられており、短い時間でも「すぐには入れない」ことが効く場面はあります。ただし、深刻な脆弱性の修正版のように、待つほうが危ない更新もあるので、更新の中身を見て判断する必要があります。

遠隔管理の仕組み（UpdraftCentral、ManageWP、MainWP、Jetpackなど）を使っている場合は、それが「すべてのサイトの合鍵を1か所に預けている」状態だということを意識しておきましょう。次の2点を心がけます。

• 使っていない接続は消す
• 使う場合でも、強すぎる権限を持たせないようにする

TeamUpdraftの件は、便利な遠隔管理が、運営元が破られたときには一斉に攻撃される経路になることを示しました。

そして、サイトの外にバックアップを持つことです。Rank Math PROもTeamUpdraftも、公式の推奨は「事件の前のバックアップから戻す」でした。戻せるバックアップがなければ、手作業で裏口を探し続けるしかありません。どのくらい前まで戻れるかを確かめておくことが、こうした事件のときにいちばん効きます。

CLIやバイナリを配布ページから入れる人

GitHubのリリースからCLIのバイナリを落として使っている場合は、次のことを習慣にしておくと、OVHcloudのような事件に気づきやすくなります。

• CIやサーバーの構築の手順では、版の番号だけでなく、ハッシュ値まで固定して確かめる。今回、差し替えに気づけたのはこのやり方でした
• 書き換え不可のリリースを使っているプロジェクトなら、GitHub CLIのgh release verify タグ名でリリースが書き換え不可になっているかを、gh release verify-asset タグ名 ファイルのパスで手元のファイルがリリースのファイルと一致するかを確かめる
• パッケージマネージャー（HomebrewやGoのgo installなど）で入れられるものは、そちらを使う。配布元とは別の仕組みでハッシュ値を記録しているものが多い
• 導入用のスクリプトをcurl ... | shのようにそのまま実行するやり方は、中身の確認を飛ばすことになる。少なくとも一度ファイルに保存して中身を見る

また、OVHcloudの件の根っこは、開発者の私物のパソコンに入ったVS Codeの拡張機能でした。開発者が使う編集ソフトの拡張機能は、パソコンの中のファイルを読む強い権限を持っています。

入れている拡張機能を定期的に見直し、使っていないものは消す、作者や配布元がはっきりしないものは入れない、という基本が、遠回りに見えて大事です。

npmの部品を使う人

npmの部品については、次の設定が今回のような事件への備えになります。

• ロックファイル（package-lock.jsonなど）をリポジトリに入れ、CIではnpm ciでロックファイルどおりに入れる。勝手に新しい版に上がらないようにする
• 出たばかりの版を入れない待ち時間を設ける。npmにはmin-release-ageという設定があり、指定した日数より前に公開された版だけを入れるようにできる（.npmrcにmin-release-age=1のように書く）。pnpmにはminimumReleaseAge（単位は分）があり、pnpm 11からは既定で1,440分（1日）になっている
• インストール時に自動で動く命令を止める。npmのignore-scriptsを有効にすると、package.jsonに書かれたpreinstallやpostinstallが動かなくなる。tensorlakeのようにpreinstallで動く型には効くが、SubQueryのように読み込み時にも動く型には効かない点は覚えておく
• CIの中から外への通信を、必要な相手だけに絞る。今回の多くのプログラムは、盗んだものを外へ送り出そうとしていた

tensorlakeは公開から約11分で見つかっていますが、npmから消えるまでの間に入れてしまった人がいれば被害に遭います。1日の待ち時間があれば、今回の多くの事件は避けられた計算になります。

もちろん、待ち時間は万能ではなく、緊急の修正版を急いで入れたいときには、その部品だけ例外にする設定も用意されています。

GitHubでリポジトリを持っている人

GhostActionの新しい波は、有名なプロジェクトだけでなく、個人のリポジトリやフォークにも広がりました。自分のリポジトリを持っている人は、次のことを確かめておきましょう。

• .github/workflows/の中に、自分で作った覚えのない「security-audit.yml」「github_actions_security.yml」「security-check.yml」などがないか。StepSecurityは、8月31日以降にこうしたファイルが現れていれば、侵害されたものとして扱うよう求めている
• 過去にコミットした鍵がないか。履歴から消したつもりの鍵も、git log -p --allで見つかる。見つかった鍵は、履歴を消すのではなく、鍵そのものを無効にして作り直す
• リリースの書き換え不可の設定を有効にする（リポジトリの「Settings」の「Releases」の項目）。ただし、効くのはこれから公開するリリースだけ
• ワークフローのファイルの変更には、ブランチの保護とレビューを必須にする。外部の協力者からのワークフローの実行には承認を求める
• GitHubのアカウントそのものを、フィッシングに強い二段階認証で守り、使っていない個人用アクセストークンを消す

開発者のアカウントの守り方や、AIのAPIキーの扱い方については、関連記事の「”Black October”の10日間」でも詳しく書いています。あわせて読んでみてください。

もう少し体系的に学びたい人へ：『ソフトウェア透明性』

今回のような事件を、個別のニュースとしてではなく、ソフトウェアのサプライチェーン全体の問題として整理したい人には、翔泳社の『ソフトウェア透明性 攻撃ベクトルを知り、脆弱性と戦うための最新知識』（ISBN 978-4-7981-8796-9、2024年12月刊）があります。

原著は『Software Transparency』で、SBOM（ソフトウェアの部品表）の第一人者として知られるアラン・フリードマン氏らが書き、NRIセキュアテクノロジーズが翻訳しています。

• ソフトウェアのサプライチェーンへの脅威の背景から、政府機関や民間の対応状況までを体系的に扱っている（NRIの書籍紹介より）
• SBOM（部品表）や、今回の記事でも触れた「証明（attestation）」の考え方を章を立てて説明している
• クラウドとコンテナ、制御システム（OT）での透明性の章があり、Webサイトの外の話まで広く押さえられる
• 「供給者向けの実践ガイダンス」と「利用者向けの実践ガイダンス」が別の章になっていて、部品を配る側と使う側のどちらの立場でも読める

ソフトウェア透明性 攻撃ベクトルを知り、脆弱性と戦うための最新知識をAmazonで見る

まとめ

10月5日から19日までの2週間ほどの間に、npmの部品、GitHub Actions、WordPressの有料プラグイン、WordPressの遠隔管理の鍵、クラウドのCLIと、さまざまな「公式の配布物」が汚されました。どの事件も、利用者が怪しいサイトからファイルを落としたのではなく、いつもの場所から、いつもの手順で受け取ったものが原因でした。

WordPressのサイトを運営している人は、まずRank Math PROとUpdraftPlusが入っているかを確かめてください。そのうえで、次の点を確認してください。

• Rank Math PROの3.0.123に当たっていた場合は、3.0.124に更新するだけでは足りず、事件の前のバックアップから戻し、パスワードや鍵をすべて交換するのが公式の推奨です
• UpdraftPlusは、版に関係なく接続キーが残っていないかを確かめ、使っていないキーは消し、1.26.13（Premiumは2.26.13）以降に更新してください
• キーを消しても、すでに入れられたプラグインやアカウントは残るので、一覧を見直すことも忘れないようにしましょう

CLIやnpmの部品を使う開発者は、「同じ場所から届いた値どうしで確かめない」ことを覚えておいてください。OVHcloudの件でchecksums.txtごと差し替えられたように、配布元が乗っ取られれば、そこに置かれた確認用の値も一緒に書き換えられます。

被害に遭う確率を下げるために、次のものを組み合わせます。

• 前もって記録したハッシュ値
• 別の仕組みで残された署名や証明
• 出たばかりの版を入れない待ち時間
• インストール時の命令を止める設定

そして、もし感染していたら、tensorlakeの件のように「トークンを無効にする前に見張り役を取り除く」必要がある場合もあるので、公式や分析を出した会社の手順を、順番どおりに進めてください。

「更新は大事」という基本は、これからも変わりません。ただ、その更新が汚れていることもある、という前提で、戻れるバックアップと、入れたものの棚卸しを用意しておくことが、今回の事件から学べるいちばんの備えです。

出典

• Rank Math：Rank Math PRO 3.0.123 Security Incident: How to Secure Your Website
• Patchstack：WordPress Rank Math SEO PRO Plugin 3.0.123（CVE-2026-111862）
• BleepingComputer：WordPress SEO plugin Rank Math compromised to backdoor websites
• The Hacker News：Rank Math PRO の侵害に関する記事
• TeamUpdraft：Security incident（October 2026）
• Patchstack：UpdraftCentral key compromise used to backdoor WordPress sites
• エックスサーバー：UpdraftPlusに関する注意喚起（2026年10月20日）
• CSO Online：WordPress sites compromised after TeamUpdraft credential exposure
• OVHcloud：GHSA-862f-55f5-vmvw（ovhcloud-cli のセキュリティアドバイザリー）
• GitHub：ovh/ovhcloud-cli issue #300
• IT-Connect：OVHcloud CLI binaries on GitHub were tampered with by an infostealer
• OpenSourceMalware：GlassWorm hacks OVHcloud’s CLI tool
• StepSecurity：@subql/common の侵害に関する分析
• Socket：TensorLake npm SDK Compromised
• Endor Labs：Tensorlake npm package compromised by Shai-Hulud
• Snyk：Embedded Malicious Code in tensorlake
• OX Security：Shai-Hulud: Here We Go Again
• StepSecurity：GhostAction Returns
• Socket：New GhostAction Wave Hits Hundreds of Repos
• Cloud Security Alliance：GhostAction Returns（Research Note）
• GitHub Docs：Immutable releases
• GitHub Docs：Verifying the integrity of a release
• GitHub Docs：Preventing changes to your releases
• npm Docs：config（min-release-age、ignore-scripts）
• pnpm：Dependency resolution settings（minimumReleaseAge）
• 国立国会図書館サーチ：ソフトウェア透明性
• 野村総合研究所：書籍紹介『ソフトウェア透明性』

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。