世界を動かす技術を、日本語で。

悪意のあるRustクレート「Arrayref」がビルド時にペイロードを実行する

2026年8月20日原文(safedep.io)

概要

  • 2026年8月20日、Rustの人気crate「arrayref」の改ざん版がcrates.ioで発見
  • バージョン0.3.10が「proc-macro1」への依存を追加し、ビルド時に不正バイナリを実行
  • 「arrayref」や「append-only-vec」のメンテナアカウントが侵害され、GitHubリポジトリも削除
  • 依存関係の深さと広範な利用により、多数のプロジェクトへ影響拡大
  • crates.ioチームは悪意あるバージョンを削除し、インシデント対応を実施

Rust crate「arrayref」サプライチェーン攻撃の概要

  • 2026年8月20日、 arrayref 0.3.10 がcrates.ioに不正公開
  • proc-macro1 (typosquattingによる偽クレート)を新規依存として追加
  • proc-macro1のビルドスクリプトが リモートバイナリをダウンロード・実行、単純なビルドだけでマルウェアが動作
  • 「droundy」アカウントが侵害され、 arrayref・append-only-vec 両クレートが被害
  • 関連GitHubリポジトリ(github.com/droundy/arrayref等)は全て404、コード検証不可
  • proc-macro1は「dtolney」名義で公開、 David Tolnay の本物アカウントに酷似
  • authorsやrepositoryメタデータも偽装、本物のproc-macro2をコピーして不審点を隠蔽

悪意ある挙動の詳細

  • proc-macro1 1.0.107のビルドスクリプトに ペイロードの実態
    • base64断片で C2サーバアドレス を難読化
    • デコード結果: hxxps://23[.]254[.]165[.]112:9089/ (ペイロード配布)、 23[.]254[.]165[.]112:443 (C2)
    • OS/アーキテクチャごとに異なるバイナリをダウンロード・実行
  • Unix系
    • /tmp/rust-setup に書き込み、実行権限付与後に非同期実行
  • Windows系
    • %TEMP%\rust-setup.ps1 にPowerShellスクリプト保存
    • VBScriptランチャ 経由でwscript.exeから非同期・非表示実行
    • Cargoのビルド完了後もプロセスが残り続ける仕組み

拡散の仕組みと影響範囲

  • arrayref 0.3.5〜0.3.9を yank (利用不可に)し、開発者に0.3.10へのアップデートを促す
  • arrayrefは tiny-skia, sctk-adwaita, winit 等を経由し、 egui, eframe, iced 等のGUIツールキットを通じて多くのプロジェクトに波及
  • 総ダウンロード数約2.45億回、0.3.9だけで1.5億回超
  • 実際の被害数は不明だが、 影響範囲は非常に広大

侵害の指標(IoC)

  • ネットワーク
    • 23.254.165.112:9089 (ペイロード配布)
    • 23.254.165.112:443 (C2アドレス)
  • ファイル
    • /tmp/rust-setup (Unix)
    • %TEMP%\rust-setup.ps1, %TEMP%\rust-setup-launch.vbs (Windows)
  • SHA256ハッシュ
    • arrayref 0.3.10: 25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae
    • proc-macro1 1.0.107: 61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4
    • proc-macro1 1.0.106: b5c1b5b0763a8809a644a8f92224653f0aca623a98eecc714d27f74b80fbe436

技術的分析:arrayref 0.3.10とproc-macro1 1.0.107

  • arrayref 0.3.10の manifest に1行追加で[dependencies.proc-macro1]を導入
    • 依存宣言のみでCargoが自動的に proc-macro1をビルド・実行
  • proc-macro1は proc-macro2のコピー に依存・ビルドスクリプトを追加
  • 本物のproc-macro2にはない build-dependencies(base64, rustls, ureq) を追加
  • build.rsでbase64難読化・TLS通信・バイナリダウンロード・非同期実行を実装
  • TLS証明書検証を全て通過させる AcceptAll 実装で自己署名証明書も許容
  • OS/アーキテクチャ判定で4種類のバイナリを配布、未対応環境ではビルド中断
  • Unixは/tmp/rust-setup、WindowsはPowerShell+VBScriptで非同期・非表示実行

まとめ・教訓

  • Rustエコシステムでも サプライチェーン攻撃 リスクが現実化
  • アカウント管理・依存関係監査の重要性
  • 不自然な依存追加やyankの動き、typosquattingへの警戒
  • 公式アドバイザリ・インシデント報告の参照推奨

Hackerたちの意見

メインのRustブログの投稿に関するスレッド: https://news.ycombinator.com/item?id=49372853 直接の投稿リンク: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... 初期レポート: https://github.com/rustsec/advisory-db/issues/3161 他のベンダーの投稿: * https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-... * https://research.jfrog.com/post/arrayref-proc-macro1-crates-... * https://www.aikido.dev/blog/two-popular-rust-crates-arrayref...

依存関係を更新しろって言ってる人たち、これがその理由だよ。怠けてるわけじゃなくて、先見の明があるんだよね。

あなたのバージョンにセキュリティの問題がなければいいけど…

“否定できない”って、ここではどんな意味があるの?これは誇張に傾いてると思うけど、“先見の明がある”って言った方がずっとシンプルで強いよね。人それぞれかもしれないけど。

うん、依存関係は更新してね。でも、リリースされてから最初のペンギンたちが海に飛び込むのをテストした後、1週間くらい待ってからがいいと思う。

厳格なコンテナ化をしないソフトウェア開発は、ますます災害に見舞われやすくなってる気がする。パッケージ管理の文化について議論することもできるけど(特にnpmについては初日からそうだったし)、もう終わったことだから。あなたの同僚やAIのサイドキックを信じて、何でもダウンロードしてビルドして実行しないとは言えないからね。できることは、効果的な爆風半径を制限することだけだよ。

最低リリース年齢

OSレベルでのサンドボックスの適切で使いやすいサポート、あるいはそれよりも能力ベースの方が、長期的な解決策の唯一のように思える。私が実行する多くのものは、1つのディレクトリの読み書きに制限したいし、ネットワークコールをするためには許可を求めたいんだ。

Cargoはbuild.rsスクリプトのサンドボックス化が絶対に必要だよ。以前にも試みられたけど、あまり進展しなかったね¹。 ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...

ビルドスクリプトのサンドボックス化はうまくいかないことが多いよ。サンドボックスを厳しくしすぎると、必要なことができなくなるし、逆に緩すぎると実用的な価値がなくなっちゃう。

https://news.ycombinator.com/item?id=49374811 (あ、ちなみにprocマクロも任意のコードを実行するよ。)

build.rsだけをサンドボックス化するのは、攻撃者にとってはちょっとした不便だけど、本当にビルドスクリプトが必要な人には大きな痛手になるよ。

Hacker Newsで議論の続きを見る