Rustクレート「arrayref」に悪意ある版、ビルド時にマルウェア実行
Malicious Rust Crate Arrayref Runs a Build-Time Payload
人気のRustクレート「arrayref」のバージョン0.3.10が2026年8月20日にcrates.ioで公開されたが、この版はタイポスクワッティングされた「proc-macro1」というクレートに依存しており、そのビルドスクリプトがリモートのバイナリをダウンロードして実行する。ビルド時に実行されるため、影響を受ける版を依存関係に含むプロジェクトをコンパイルするだけで感染する。crates.ioチームは悪意のある版を削除した。arrayrefは累計約2億4500万ダウンロードされ、eguiやicedなどのGUIフレームワークを通じて広く使われている。
「ビルドスクリプトは、プロジェクトのコンパイル中にリモートのバイナリをダウンロードして実行する」
HNでの議論
490- cube00
GitHubはこうしたインシデントの際に、リポジトリを存在しなかったかのように扱うだけでなく、もっと細かい粒度の対応が本当に必要だ。[1]
悪意のあるバージョンのパッケージもcrates.ioから消えてしまったが[2]、yankされたという表示はない。そこにはセキュリティアドバイザリもない。[3]「このクレートに関するアドバイザリは見つかりませんでした」。
crates.ioはこのようなセキュリティインシデントに対して準備ができていなかったと感じる。彼らが対応を管理しているのだから。[4]
[1]: https://web.archive.org/web/20260820145918/https://github.co...
[2]: https://crates.io/crates/arrayref/versions
[3]: https://crates.io/crates/arrayref/security （Waybackリンクも貼ろうと思ったが、それも壊れている https://web.archive.org/web/20260820150747/https://crates.io...）
[4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomm...
- cosmic_cheese
言語とライブラリの設計には、もっと「バッテリー同梱」のアプローチを取るべきだと思う。私たちがこの混乱に陥っている根本的な理由は、標準ライブラリが極端に薄いことを許容し、むしろ好ましいとさえ判断してきたからだ。その結果、基本言語はほぼ使い物にならない状態になっている。
私は、5つ以下のトップレベル依存関係で、高機能で使いやすいAppleプラットフォームアプリを非常に簡単に構築できる。多くの場合、合計0〜2個しか使わない。
これを他の場所でも再現できない理由はない。鍵となるのは、プログラミング言語を十分に堅牢にし、一般的な非UI開発ニーズの少なくとも80%を組み込み、残りの20%とUI部分を、十分にサポートされ、コミュニティに受け入れられ、できればファーストパーティのライブラリ群に組み込むことだ。
そうすれば、圧倒的多数のプロジェクトで外部依存関係を取り込む必要がなくなる。取り込まれるわずかなものも、軽量で検証が容易なシンタックスシュガーか、標的にするにはニッチすぎる目的のライブラリになるだろう。
もちろん、このアプローチも間違う可能性はある。Boostのような怪物になりかねないが、それはプロジェクト管理がクリーープを抑制し、適切なモジュール設計を行うかどうかにかかっている。
- ramimac
メインの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...
- jakubadamw
Cargoにはbuild.rsスクリプト用のサンドボックス化が切実に必要だ。以前試みられたが、あまり進展しなかった¹。
¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
- hbbio
RustはJSエコシステムと同じ欠陥を抱えている。重要なクレートはどれも、数百から数千の依存関係をインポートする。その作者の一人がAI支援攻撃の標的になる可能性は高すぎる。
また、これらの依存関係のほとんどは、最終的なパッケージがおそらく必要としない幅広い機能を提供している。
- fidotron
厳格なコンテナ化の外でのソフトウェア開発は、少なくとも、ますます災害につながりやすくなっているように見える。
確かに、パッケージ管理の文化について議論することはできる（特にnpmについては初日から一部の人がしてきたように）が、それはもう終わったことであり、同僚やAIアシスタントが何でもダウンロードしてビルド・実行しようとするのを信頼することはできない。できるのは、効果的な爆発半径を制限することだけだ。
- tancop
今すぐエフェクトベースの言語が必要だ。ライブラリがコンパイルされる前に、ネットワークなし、ファイルアクセスなし、unsafeコードやFFIなしといったポリシーを保証する唯一の方法だ。Epicの誰かがこれを読んでいるなら、Verseコンパイラのオープンソース化のタイムラインを教えてほしい。
それまでの間、CargoをハックしてすべてのビルドスクリプトをmicroVMで実行することは可能だと思う。爆発半径はバイナリ内の悪意のあるコードに限定され、CIシークレットをすべてアップロードしたりハードドライブ全体を消去したりする代わりになる。
- vatsachak
依存関係を更新しろと言う人たちへ、これが私が更新しない理由だ。怠惰ではなく、否定できない先見の明だ。
- tsimionescu
> arrayrefは4つのマクロからなる小さなクレートです。
なぜこれほど多くの言語がこの恐ろしい慣行に陥るのか？
- tyrchen
数ヶ月前にnpmエコシステムでいくつかのサプライチェーン攻撃が発生したとき、私はSBEを構築しました: https://github.com/tyrchen/sbe。
これは、macOSではSeatbelt / SBPL、LinuxではLandlock LSM + seccomp-bpfを使用して、任意のCLIコマンドにサンドボックス化を提供します。ローカルの依存関係ビルドを保護したり、GitHub Actionsに統合してCIに追加の保護層を追加したりできます。
ぜひ試してみてください。フィードバックをお待ちしています。