Rust crates.ioでサプライチェーン攻撃、arrayrefなど3クレートが侵害 Wizは北朝鮮系キャンペーンとのインフラ重複を指摘|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年08月25日更新日時: 2026年08月25日

Rustの公式パッケージレジストリ「crates.io」で2026年8月20日、正規のRustクレートに悪意ある依存関係が追加され、ビルド時に外部ペイロードを実行するサプライチェーン攻撃が発生しました。Rust Security Response Teamは、arrayref 0.3.10、internment 0.8.7、append-only-vec 0.1.9を削除し、正規メンテナーのアカウントをロックしました。

セキュリティ企業Wizは、今回使われたC2通信やホスティングインフラについて、Microsoftが北朝鮮系の「Sapphire Sleet」に帰属したMastra npm攻撃や、Google Threat Intelligence Group（GTIG）が北朝鮮系の「UNC1069」に帰属したAxios npm攻撃との重複を指摘しています。ただし、Rustプロジェクトや政府機関が今回の攻撃を北朝鮮系アクターに帰属したわけではありません。

Rust crates.ioサプライチェーン攻撃のサマリー

確認済み：2026年8月20日、Rust Security Response Teamはproc-macro1クレートに悪意あるビルドスクリプトが含まれ、外部からペイロードを取得していたことを確認しました。
確認済み：正規メンテナーが管理するarrayref 0.3.10、internment 0.8.7、append-only-vec 0.1.9に、悪意ある依存関係が追加されていました。
確認済み：Rust Security Response Teamは、正規メンテナー本人が悪意を持っていたとは考えておらず、端末または認証情報が侵害された可能性が高いとしています。
確認済み：arrayref 0.3.10は約86分、internment 0.8.7は約90分、append-only-vec 0.1.9は約107分、crates.io上で公開されていました。
確認済み：RustSecによるとarrayref 0.3.10は削除までに2,285回ダウンロードされました。ただし、ダウンロードされた環境すべてでビルドや悪性コード実行が行われたことを意味しません。
確認済み：3つの侵害された正規クレートには、それぞれCVE-2026-77651、CVE-2026-77649、CVE-2026-77650が割り当てられ、CVSS 9.8と評価されています。
確認済み：悪意ある依存クレートのビルドスクリプトは、Rustのビルド処理時に自動実行される仕組みを悪用しており、影響バージョンをビルドした開発端末やCI環境では二次ペイロードが実行された可能性があります。
確認済み：Wizは二次ペイロードについて、Windows、macOS、Linuxに対応し、端末情報収集、永続化、追加スクリプト実行などのバックドア機能を備えていたと分析しています。
確認済み：WizはChrome、Brave、Edgeの保存済みログイン情報を列挙する処理を確認しましたが、暗号化されたブラウザ認証情報そのものを取得していたとの初期説明は後に訂正しています。
関連指摘：Wizは、今回のC2通信パターンやインフラが、北朝鮮系アクターに帰属された過去のMastra、Axiosサプライチェーン攻撃と大きく重複するとしています。
未確認：今回の攻撃主体がSapphire Sleet、UNC1069、その他の北朝鮮系アクターであることは公式には確認されていません。
未確認：実際に悪性コードが実行された開発端末・CI環境の件数や、そこから認証情報窃取・二次侵害に至った組織数は公表されていません。

項目	内容
確認日	2026年8月20日
対象	Rustのcrates.ioエコシステム
インシデント	正規メンテナーアカウントを利用した悪意あるクレート公開、ビルド時のコード実行
侵害された正規クレート	`arrayref 0.3.10`、`internment 0.8.7`、`append-only-vec 0.1.9`
悪意ある依存関係	`proc-macro1`など
CVE	CVE-2026-77651、CVE-2026-77649、CVE-2026-77650
CVSS	いずれも9.8（Critical）
実行条件	影響バージョンを依存関係として解決し、Cargoでビルド等を実行した場合
公開時間	arrayref：約86分、internment：約90分、append-only-vec：約107分
arrayref 0.3.10のダウンロード	2,285回
実際の侵害件数	確認できませんでした
攻撃者	特定されていません。Wizが北朝鮮系キャンペーンとのインフラ重複を指摘
対応状況	悪性バージョン削除、正規版のyank解除、関連アカウントのロック
CISA KEV	2026年8月24日時点でCVE-2026-77651の掲載を確認できませんでした

arrayrefなど正規3クレートに悪意ある依存関係

Rust Security Response Teamによると、2026年8月20日7時15分（UTC）、proc-macro1が悪意あるクレートであるとの報告を受けました。調査の結果、同クレートのビルドスクリプトが外部から悪意あるペイロードを取得することを確認しました。

さらに、広く利用されている正規クレートarrayrefの新バージョンがproc-macro1に依存するよう変更されていたことが判明しました。同じメンテナーが管理していたinternmentとappend-only-vecにも同様の影響が確認されています。

影響を受けた正規バージョンは以下です。

クレート	悪性バージョン	直前の影響を受けないバージョン	公開時間
arrayref	0.3.10	0.3.9以前	約86分
internment	0.8.7	0.8.6以前	約90分
append-only-vec	0.1.9	0.1.8以前	約107分

Rust Security Response Teamは悪性バージョンを削除し、攻撃者によってyankされていた正規バージョンを復旧しました。正規メンテナーのアカウントについては予防措置としてロックしています。

Rust側は、arrayrefの作者が悪意を持って今回の変更を行ったとは考えておらず、「コンピューターまたは認証情報が侵害された可能性が高い」としています。どのような経路でメンテナーアカウントが侵害されたのかは明らかになっていません。

ビルドしただけで悪性コードが実行される仕組み

今回の攻撃では、arrayrefなどの正規クレート本体に大規模な悪性コードを直接埋め込むのではなく、悪意あるproc-macro1を依存関係として追加する手法が使われました。

proc-macro1は正規のRustクレートproc-macro2と名称が似たタイポスクワッティング型のパッケージです。内部のビルドスクリプトには、外部からOS別の二次ペイロードを取得し、実行する処理が含まれていました。

Rustのbuild.rsはCargoによるビルド処理の途中で実行されます。そのため、開発者がarrayrefの機能をアプリケーションから明示的に呼び出していなくても、依存関係として悪性バージョンが解決され、その状態でビルドや関連処理が行われれば、ペイロードが実行される可能性があります。

影響対象は完成したアプリケーションの実行環境だけではありません。開発者端末、CI/CDランナー、ビルドサーバーなど、依存関係を取得してコンパイルする環境が直接の侵害対象になります。

arrayref 0.3.10は2,285回ダウンロード、実行件数とは別

arrayrefは長期間利用されているRustクレートで、全バージョンを合計した累積ダウンロード数は約2億4,500万回規模に達します。Wizの観測環境では、Rustを利用する環境の約4分の3で何らかのバージョンのarrayrefが確認されたとしています。

ただし、この数字を今回の被害件数として扱うことはできません。

RustSecによると、実際に悪性だったarrayref 0.3.10は削除までに2,285回ダウンロードされました。これは当該時間帯の全arrayrefダウンロードの10％未満で、多くの利用者は既存のロックファイルによって以前のバージョンを利用していました。

さらに、2,285回という数字も「侵害された端末数」ではありません。パッケージがキャッシュやレジストリミラーへ取得されただけの場合もあり、実際にビルドされ、二次ペイロードが取得・実行された件数は確認されていません。

したがって、「2,285台が感染」「2億4,500万件に影響」といった表現は現時点の一次情報では裏付けられません。

3つの正規クレートにCVE、CVSSはいずれも9.8

侵害された3つの正規クレートにはそれぞれCVEが割り当てられています。

CVE	クレート	バージョン	内容
CVE-2026-77651	arrayref	0.3.10	悪意ある依存関係を介したビルド時の任意コード実行
CVE-2026-77649	internment	0.8.7	悪意ある依存関係を介したビルド時の任意コード実行
CVE-2026-77650	append-only-vec	0.1.9	悪意ある依存関係を介したビルド時の任意コード実行

いずれもCWE-506「Embedded Malicious Code」に分類され、CNAによるCVSS v3.1基本値は9.8です。

通常のソフトウェア脆弱性とは異なり、今回はプログラム上の欠陥を第三者が悪用する問題ではなく、公開された特定バージョン自体がサプライチェーン攻撃によって汚染された事案です。そのため、影響バージョンを修正して継続利用するのではなく、悪性バージョンを依存関係から排除し、ビルドした環境自体を調査する必要があります。

2026年8月24日時点で、CISAのKnown Exploited Vulnerabilities（KEV）カタログにCVE-2026-77651が掲載されていることは確認できませんでした。今回のような悪意あるパッケージは、KEV掲載の有無とは別に侵害対応の対象として扱う必要があります。

二次ペイロードはWindows、macOS、Linuxに対応

Wiz Researchは、悪意あるRustクレートから取得される二次ペイロードを分析しました。同社によると、攻撃コードはWindows、macOS、Linuxの複数アーキテクチャに対応していました。

確認された機能には、端末名やユーザー名、OSなどのシステム情報収集、永続化、C2から指定された追加スクリプトの実行などがあります。C2へ接続できない場合に備えた代替通信先生成の仕組みも確認されています。

ブラウザ情報の扱いについては注意が必要です。Wizは当初、Chrome、Brave、Edgeからブラウザ認証情報を窃取すると説明していましたが、その後記事を訂正しています。現在の分析では、保存済みログイン情報や拡張機能設定を列挙する処理は確認されたものの、ブラウザに保存された暗号化済みの認証情報そのものを取得していたことは確認していません。

したがって、「ブラウザパスワードが確実に窃取された」と断定することはできません。

Wizが北朝鮮系キャンペーンとのインフラ重複を指摘

SecurityWeekは今回の攻撃について、北朝鮮系の脅威アクターSapphire Sleetが関与した可能性があると報じています。その根拠となっているのがWiz Researchの分析です。

Wizは、今回のarrayref攻撃で使われたインフラについて、過去に北朝鮮系アクターへ帰属された2つのサプライチェーン攻撃との重複を確認しています。

1つはMastra npmサプライチェーン攻撃です。Microsoftはこの攻撃を北朝鮮系のSapphire Sleetに帰属しており、今回のRust攻撃では、Mastraキャンペーンと同じC2通信パスのパターンや、関連するTLS証明書情報の重複が確認されたとWizは説明しています。

もう1つはAxios npmサプライチェーン攻撃です。Google Threat Intelligence GroupはAxiosへの攻撃を、金銭目的の北朝鮮系アクター「UNC1069」に帰属しています。Wizは、今回のRust攻撃とAxios攻撃で利用されたIPアドレス帯やホスティング事業者にも重複があるとしています。

ただし、これらはインフラや通信パターンの重複に基づく関連付けです。Rust Security Response Teamは攻撃者を特定しておらず、Wizの公開分析も「DPRKのサプライチェーン攻撃との大きな重複」と表現しています。

このため、本件を「北朝鮮政府による攻撃」「Sapphire Sleetの犯行」と断定するのは現時点では適切ではありません。

セキュリティ対策Labでは、関連するMastra攻撃について「北朝鮮ハッカーグループがMastra AIのnpmへサプライチェーン攻撃」、Axios攻撃について「Axiosへのサプライチェーンサイバー攻撃はどう起きたのか」でも解説しています。

情報システム部門・開発部門への示唆

Rustを利用している組織では、まずCargo.lockやローカルキャッシュ、CI/CDの依存関係履歴を確認し、arrayref 0.3.10、internment 0.8.7、append-only-vec 0.1.9、およびRust Security Response Teamが削除した関連クレートが取得されていないかを調査する必要があります。

重要なのは、「依存関係に存在した」環境と「悪性コードが実際に実行された」環境を分けることです。

影響バージョンを取得しただけでビルドしていない場合と、開発端末やCIランナー上でCargoによるビルド等が行われた場合では、対応レベルが異なります。Wizは、影響バージョンをビルドしたホストについては侵害を前提に扱い、その端末やCI環境からアクセス可能だった認証情報、APIトークン、CIシークレット、署名鍵などのローテーションを推奨しています。

また、侵害されたCI/CD環境から生成された成果物についても、信頼できるクリーンな環境から再ビルドし、整合性を確認する必要があります。開発端末だけを初期化して終了すると、汚染された成果物や盗まれた認証情報が残る可能性があります。

今回の攻撃では、正規クレートの過去バージョンが一斉にyankされ、利用者に新しいバージョンへの更新を促す状況が作られていました。長期間安定していた依存パッケージで複数バージョンが突然yankされた場合、警告を解消するために機械的に最新版へ更新するのではなく、メンテナーの告知や差分、追加された依存関係を確認する運用が必要です。

OSSのメンテナーアカウントは、ソースコードそのものと同等のサプライチェーン資産です。組織内で公開権限を持つアカウントについては、多要素認証、フィッシング耐性の高い認証方式、最小権限、リリース承認、短命な公開トークンなどを組み合わせ、単一アカウントの侵害で即座にパッケージ公開へ至らない仕組みを検討する必要があります。