crates.ioで人気Rustクレートが悪意ある更新、ビルド時に不正コードを実行するサプライチェーン攻撃が発覚

要点

• Rustの公式パッケージリポジトリ「crates.io」において、正規メンテナーのアカウント侵害により悪意ある3つのクレートが公開された。
• 累計2億4500万回以上のダウンロード実績を持つ『arrayref』などが対象となり、公開から約86〜107分でRustプロジェクトにより削除された。
• 広く使われる有名クレートに偽装した依存関係のビルドスクリプトを通じて、コンパイル時にOSごとの不正なペイロードがダウンロード・実行される仕組みだった。
• 攻撃者は過去の正常なバージョンを一斉に非推奨化（ヤンク）することで、開発者を不正な新バージョンへ誘導していた。
• 現時点で実際に悪用された証拠は確認されていないものの、開発者にはローカルキャッシュの確認やバージョンの固定が推奨されている。

リード文

Rustの公式パッケージリポジトリ「crates.io」において、侵害されたメンテナーのアカウントから不正なコードを含むクレート（Rustのライブラリやパッケージの単位）が公開されていたことが、2026年8月20日に明らかになった。報告を受けたRust Security Response Teamは即座に調査を行い、公開から約86〜107分以内に該当する悪意あるバージョンをすべて削除した。影響を受けたクレートには累計2億4500万回以上のダウンロード数を誇る『arrayref』などが含まれていたが、現時点で実際の被害が確認された痕跡はないと説明されている。

アカウント侵害と悪意あるバージョンの削除

Rust Security Response Teamの発表によると、2026年8月20日07:15（UTC）にNextron Systems GmbHのリサーチチームから、不審なクレートに関する報告を受領したという。調査の結果、同一のメンテナーアカウントから以下の悪意あるバージョンが相次いで公開されていたことが確認され、Rustプロジェクトによって削除された。

• arrayref 0.3.10：07:15公開、08:41削除（公開時間：86分間）
• internment 0.8.7：07:34公開、09:04削除（公開時間：90分間）
• append-only-vec 0.1.9：07:37公開、09:25削除（公開時間：107分間）

あわせて、関連する proc-macro1、proc-macro-en、aovine、arone、aronenao、tinymember の全バージョンも削除対象となった。

crates.ioの登録情報によると、arrayref の単独オーナーは2009年10月に登録されたアカウント（David Roundy氏）となっている。Rust Security Response Teamは「作者本人が悪意を持って行動したとは考えておらず、コンピュータまたは認証情報が侵害された可能性が高い」としており、連絡を試みていると述べた。なお、アカウントが侵害された具体的な経路は公表されていない。

ビルドスクリプトを悪用した攻撃の仕組み

今回の攻撃では、侵害された各クレートの設定ファイル（マニフェスト）に、proc-macro1 への依存関係が1行追加されていた。これは広く利用されている標準的なクレート proc-macro2 に酷似させたタイポスクワッティング（打ち間違いや誤認を狙った名前付け手法）である。proc-macro1 のライブラリ本体コードは本物の proc-macro2 をそのまま複製したものであったため、通常のビルド処理自体はエラーを出さずに完了する設計になっていた。

しかし、proc-macro1 に含まれるビルドスクリプト（ソースコードのコンパイル準備段階で自動実行されるスクリプト）に不正な処理が組み込まれていた。Rustの仕様上、依存関係として解決されたクレートのビルドスクリプトはコンパイル時に自動実行されるため、プロジェクト側でクレートの機能を明示的に呼び出していなくても、ビルドを実行しただけで不正コードが動作する状態となっていた。

解析によると、このビルドスクリプトは以下のような処理を行っていたとされる。

• Base64形式の断片から、C2サーバー（感染端末を遠隔制御する攻撃者のサーバー）のアドレスやホスト情報を動的に復元する。
• 3つの検証メソッドが無条件で成功を返す独自の証明書検証機能を組み込み、TLS通信の正当性検証を無効化する。
• 実行環境のOSやCPUアーキテクチャを判定し、4種類のペイロードから適合するものを選択して外部からダウンロードする。
• UnixおよびmacOS環境では、バイナリを /tmp/rust-setup に書き出して実行権限を付与し、C2アドレスを引数に渡してバックグラウンドで起動する。
• Windows環境では、%TEMP% にPowerShellスクリプトを書き込み、wscript.exe 経由でVBScriptランチャーから非表示で実行する。この処理には、Cargo（Rustのビルドツール）のプロセス監視（ジョブオブジェクト）から離脱し、ビルド処理の完了を待たずにバックグラウンドで動作し続けるための細工が施されていた。
• ダウンロードされる第2段階のインプラントは、HTTPS POST通信を通じて /49890878 パスへ定期通信（ビーコン）を行い、レジストリのRunキーに登録して端末への永続化を図る仕組みとなっていた。

過去バージョンをヤンクして不正版へ誘導する手口

攻撃者は不正なバージョンを配布するために、心理的な誘導手口を組み合わせていた。悪意ある arrayref 0.3.10 が公開されたのと同一分内に、同じメンテナーアカウントを使って過去の正常なバージョン（0.3.5から0.3.9）が一斉にヤンク（新規ダウンロードを制限し非推奨とする操作）された。

これにより、Cargoを利用する開発者の環境では「ヤンクされていないバージョンへの更新を検討してください」という警告メッセージが表示されるようになった。その結果、開発者は警告を解消しようとして、唯一ヤンクされていない最新バージョンとして提示された不正な0.3.10へとアップデートするように仕向けられていたという。RustSecに報告を寄せたリサーチャーも、この警告表示がきっかけで不正バージョンを取り込むことになったと証言している。

広範な依存関係とエコシステムの対応

crates.ioのデータによると、arrayref は累計で2億4538万5500回、直近90日間だけでも約5390万回のダウンロード実績を持ち、crates.io上の403個のクレートから直接依存されている主要クレートである。

依存関係の連鎖の一例として、GUI関連の有名クレート winit は sctk-adwaita（^0.10.1）に依存し、それが tiny-skia（^0.11）を要求し、さらにそれが arrayref（^0.3.6）を要求するという多層構造が存在していた。Cargoのバージョン指定規則（^0.3.x）では0.3系の最新版が自動的に解決されるため、arrayref 0.3.10 が公開されていた時間帯には、広範なプロジェクトで意図せず不正バージョンが取り込まれるリスクが存在していた。

この事態を受け、暗号化ライブラリの blake3 は同日09:09（UTC）に公開したバージョン1.8.7で arrayref への依存を削除した。続いて blake2b_simd（09:25 UTC）や blake2s_simd（09:26 UTC）も、相次いで arrayref の依存関係を排除した新バージョンをリリースしている。

被害状況と開発者向けの推奨対応

今回の問題についてパッチ版は提供されておらず、CVE識別番号も割り当てられていない。RustSecが公開したアドバイザリ（RUSTSEC-2026-0260など）によると、悪意あるバージョンが実際に利用された証拠は記録されていないとされている。なお、The Hacker NewsがRust Security Response Teamに対して削除バージョンのダウンロード数や判断の根拠について取材を行ったものの、記事執筆時点では回答は得られていないという。

Rust Security Response Teamは対応の一環として、攻撃者によって不正にヤンクされていた過去の正常バージョン（0.3.5〜0.3.9）のヤンク状態を解除した。開発者に対しては、ローカル環境のキャッシュディレクトリ（~/.cargo/registry/cache）内に削除されたクレートファイルが存在しないか確認すること、および arrayref のバージョンを明示的に 0.3.9 またはそれ以前に固定（ピン留め）することが推奨されている。