TITLE

Rustの定番クレート「arrayref」がサプライチェーン攻撃を受けた——crates.ioは86分で対応

投稿日：2026.08.21

2026年8月20日に何が起きたか——arrayrefを含む3クレートが乗っ取られた

発見したのは Nextron Systems GmbH のリサーチチームで、2026年8月20日07:15 UTC(協定世界時)に proc-macro1 というクレートが悪意あるものだと Rust Security Response Team に報告しました。チームが検証した結果、proc-macro1・proc-macro-en・aovine・arone・aronenao・tinymember の6クレート全バージョンが悪意あるものと確認され、crates.io から削除されています。

これらの悪性クレートを新規依存として追加していたことで巻き添えを受けたのが、arrayref@0.3.10・internment@0.8.7・append-only-vec@0.1.9 の3つの著名クレートです。中でも arrayref は、冒頭で触れた通り極めて広く使われているクレートであり、影響範囲への懸念が大きいクレートでした。egui・eframe・iced といったGUIフレームワーク、winit・blake3、さらにSolana・Ethereum関連のクレートも arrayref に依存しており、間接的な影響が広範囲に及びうる構造でした。

長年同じ形のまま積まれてきた土台のブロックの列に、色違いのレンガが1つ新しく追加され列が伸びているイラスト。既存のブロックは残ったまま末尾に新しいブロックが加わる構図で、広く使われる基盤クレートに新規依存が1つ増えたことを表す。

「たった1つの新規依存」——arrayrefが10年間守ってきた記録が破られた瞬間

arrayref は10年の歴史を持つクレートですが、その間ずっと依存関係はゼロでした。SafeDep の分析によると、proc-macro1 は arrayref がこれまで一度も持ったことのない、初めての依存クレートだったといいます。長期間依存ゼロで安定していたクレートに新しい依存が追加される——この変化そのものが、後から振り返れば予兆でした。

攻撃の4段階を図にまとめました。

arrayref サプライチェーン攻撃の4段フロー図。STEP1侵害(アカウント認証情報の侵害)→STEP2追加(タイポスクワッティングされたproc-macro1が新規依存として追加)→STEP3実行(cargo build時にビルドスクリプトが自動発火)→STEP4検知・除去(公開から86分後にcrates.ioから削除)を1本の背骨に乗せた図。html2png変換済みのHTML=/home/yama/leadeas-blog/arrayref-rust-crate-supply-chain-attack-2026-fig-attack-chain.html

STEP1(侵害)について、Rust公式ブログは、arrayref メンテナ本人が悪意を持って行ったとは考えておらず、著者のアカウントまたは端末の認証情報が侵害されたと推定していると説明しています。該当アカウントは予防的措置としてロックされました。STEP2(追加)で proc-macro1 が新規依存として package の設定に追加され、STEP3(実行)で cargo build 実行時にビルドスクリプトが自動的に発火します。

ビルドスクリプトという「もう一つの実行経路」——狙われた仕組み

SafeDep の分析によると、proc-macro1 のビルドスクリプトは、base64 断片から再構成したサーバーアドレスへ接続し、リモートのバイナリをダウンロードして実行する仕組みを持っていました。ダウンロードされたペイロードの書き込み先は、Unix環境では /tmp/rust-setup、Windows環境では %TEMP% 配下だったと報告されています。BleepingComputer 等の報道によれば、このペイロードはインフォスティーラー(認証情報窃取型マルウェア)として機能するとされています。

cargo build や cargo install は、依存クレートを取得するだけの操作に見えます。しかし依存クレートがビルドスクリプトを持っていれば、そのスクリプトはビルドのたびに自動的に実行されます。arrayref が広く使われる基盤クレートだったからこそ、この経路を経由した被害がGUIフレームワークや暗号資産関連クレートの利用者にまで及びうる構造だったわけです。

86分の攻防——crates.ioチームの対応

crates.io チームの対応は速く、arrayref@0.3.10 は公開から86分後に crates.io から削除されました。internment@0.8.7 は90分後、append-only-vec@0.1.9 は107分後に、それぞれ同様に削除されています。Nextron Systems の発見・報告から Rust Security Response Team の検証を経てここまでの対応が完了しており、公開されてからの経過時間としては短時間の部類に入ります。

一方で、本攻撃が過去のキャンペーンと似た特徴を持つという指摘もあります。Wiz社のブログは、本攻撃と過去のDPRK(北朝鮮)関連キャンペーンとの間に手口の重複があると指摘しています。攻撃者の身元がこの指摘だけで確定するわけではありませんが、この重複が事実であれば、今回のような手口が単発で終わらず今後も形を変えて繰り返される可能性があると受け止める材料になります。

今すぐやるべきこと——ローカルキャッシュの確認

Rust公式ブログが明記している推奨対応は、ローカルの ~/.cargo/registry/cache を確認し、該当するファイルが存在しないかを調査することです。数分で終わる確認で、影響の有無を切り分けられます。該当があれば、次の順で対応します。

自社のプロジェクトが arrayref@0.3.10・internment@0.8.7・append-only-vec@0.1.9 のいずれかに依存していないか、Cargo.lock を検索する
該当があれば、~/.cargo/registry/cache 配下に不審なファイル(proc-macro1 関連)が残っていないか確認する
該当環境で扱っていたクラウド・レジストリ・SSH等の認証情報のローテーションを検討する

恒久対策——新規依存の追加を見張る習慣

今回の起点は、10年間ゼロだったクレートに新しい依存が追加されたという変化そのものでした。この構造は arrayref に限らず、長期間安定して使われてきた基盤クレート全般に当てはまります。Cargo.lock の差分レビューで新規依存クレートの追加を必ず確認する運用を CI に組み込んでおくと、同種の変化を早期に検知しやすくなります。あわせて、ビルドスクリプトを持つ依存クレートを事前に把握しておくことも、影響範囲を素早く切り分ける備えになります。

まとめ

パッケージ名や利用実績への信頼だけでは、今回のような手口は見抜けません。攻撃者は proc-macro1 という不審なパッケージを実際に新しく公開していましたが、開発者がそれを直接インストールすることはまずありません。突破口になったのは、メンテナの認証情報を乗っ取ったうえで、そのパッケージを信頼を積み重ねてきた arrayref の新規依存として静かに追加させたことでした。crates.io が86分で対応したという速さに安心してよいのは、あくまで結果を知った後の話です。その86分の間にビルドを実行した環境では、任意のコードが実際に発火した可能性が残ります。上流の対応を待つだけでなく、依存関係の変化そのものを自分の手元で確認する習慣が、この時間差を埋め合わせます。

次に cargo build を実行する前に、まず自分の ~/.cargo/registry/cache を検索してみてください。