要注意：Rustのライブラリ「Arrayref」でビルド時に悪意あるコードが実行されるサプライチェーン攻撃が発覚

Rustエコシステムを狙った新たなサプライチェーン攻撃が確認されました。人気のRustクレート「Arrayref」において、ビルド時にペイロードを実行する悪意あるコードが混入していたようです。詳細については以下の公式ブログおよびアドバイザリ情報を必ず確認してください。公式ブログ: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/ RustSecアドバイザリデータベース: https://github.com/rustsec/advisory-db/issues/3161

Rustの公式ブログへの投稿に関するスレッドはこちら：https://news.ycombinator.com/item?id=49372853 (https://news.ycombinator.com/item?id=49372853)

直接の投稿リンク：https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... (https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/)

初期報告：https://github.com/rustsec/advisory-db/issues/3161 (https://github.com/rustsec/advisory-db/issues/3161)

その他ベンダーによる投稿：

• https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-... (https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack)

• https://research.jfrog.com/post/arrayref-proc-macro1-crates-... (https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/)

• https://www.aikido.dev/blog/two-popular-rust-crates-arrayref... (https://www.aikido.dev/blog/two-popular-rust-crates-arrayref-and-append-only-vec-compromised-in-supply-chain-attack)

厳格なコンテナ化を行わずにソフトウェア開発をするのは、少なくとも、ますます大惨事を招きやすくなっているように見える。

パッケージ管理の文化については議論できるけど（npmの初期から散々議論されてきたように）、もう起きてしまったことだ。同僚やAIのサイドキックが、何でもダウンロードしてビルド・実行してしまうのを防ぐことはできない。今できるのは、被害の範囲を最小限に抑えることだけだよ。

Cargoにはbuild.rsスクリプトのサンドボックス化がどうしても必要だ。以前にも試みられたけど、あまり進展しなかったんだよね¹。

¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr... (https://rust-lang.github.io/goals/2024h2/sandboxed-build-script.html)

今こそエフェクトベースの言語が必要だ。ライブラリがコンパイルされる前に、ネットワークアクセス不可、ファイルアクセス不可、unsafeコードやFFI禁止といったポリシーを保証できる唯一の方法だから。もしEpicの関係者が見ていたら、Verseコンパイラのオープンソース化のスケジュールを教えてくれ。

とりあえず、CargoをハックしてすべてのビルドスクリプトをマイクロVMで実行するのは可能だと思う。そうすれば、CIのシークレットを全て盗まれてハードドライブを削除されるような事態にならず、被害の範囲をバイナリ内の悪意あるコードだけに限定できる。

言語やライブラリ設計において、もっと「バッテリー同梱（標準機能充実）」的なアプローチを取るべきだと思う。現在のこの状況に陥っている理由は、標準ライブラリを極限まで薄くしても構わない、あるいはその方が好ましいと決めてしまった結果、ベースとなる言語が使い物にならなくなっているからだ。

Appleプラットフォームのアプリなら、トップレベルの依存関係が5個以下でも機能豊富で快適なものが簡単に作れる。多くの場合、0〜2個で済むことだってある。

これが他の場所で再現できない理由はない。鍵となるのは、プログラミング言語をある程度堅牢にして、一般的な非UI開発に必要な機能の80%を標準で組み込み、残りの20%とUI部分はサポートの行き届いた、コミュニティに受け入れられている小さなライブラリ群に任せることだ。

そうすれば、プロジェクトの大半で外部の依存関係を引っ張ってくる必要がなくなる。引っ張ってきたとしても、簡単に検証可能な糖衣構文や、ニッチな目的の軽量なライブラリだけになるはず。

もちろんこのアプローチも失敗しうる。Boostみたいなモンスターを生み出してしまう可能性もあるけど、それはプロジェクト管理が肥大化を抑制できるか、適切なモジュール設計ができるかという話に帰結する。

RustはJSエコシステムと同じ欠点を抱えている。重要なクレートであれば、何百、何千という依存関係をインポートしてしまう。作者の誰かがAI支援による攻撃の標的になる確率は高すぎるよ。

それに、そうした依存関係のほとんどは、最終的なパッケージには必要のない広範な機能を提供しているしね。

GitHubは、こうしたインシデントの際にリポジトリが存在しなかったかのように振る舞うだけでなく、もっと細やかな対応が必要だよ。1

悪意のあるパッケージバージョンもcrates.ioから突然消えてしまった2し、取り下げられた旨の表示もない。セキュリティアドバイザリも「このクレートのアドバイザリは見つかりませんでした」となっている3。

crates.ioは対応を主導している割に、今回のようなセキュリティインシデントへの備えができていなかったように感じる。4

記事によると、「（Windowsの被害者において、）悪意のあるビルドスクリプトは（攻撃者のリモートペイロードを取得し、）%TEMP%\rust-setup.ps1 に書き込んでから、VBScriptランチャー経由で wscript.exe として実行する。ソース内のコメントにはその理由が書かれている：」

そして、そのコメントというのがこれ：

    // ShellExecute via WScript escapes Cargo's job object; spawned children otherwise
    // keep the build script (and `cargo build`) waiting until they exit.

なんと、悪意のあるビルドスクリプトに親切なコメント（？？？）が付いている。しかも、よくある「動詞を名詞化したような簡潔なスタイル（！！！）」で書かれている。

憶測を言うのは野暮かな？たぶんスクリプトキディがFableを言いくるめてセーフガードを外させたのか、あるいはAnthropicがFable 5.1の学習を行っていて、エアギャップが機能していなかったのかもね。

せめてもの救いは、そのエクスプロイトがメモリセーフだということだね。

Safe Rustといえども、パッケージマネージャーのせいで実はそれほど安全ではないのかもね？