人気Rustクレートarrayrefが乗っ取られ、ビルド時にマルウェアを実行していた──245百万DLの依存先で何が起きたか

2026年8月20日、Rustのパッケージレジストリcrates.ioで、人気クレート「arrayref」の新版0.3.10がビルド時にマルウェアを実行する状態で公開されていたことを、セキュリティ企業SafeDepがブログで報告した。ブログ本文を確認すると、この事件はタイポスクワッティング（既存の信頼されたクレート名に酷似した偽クレートを作る手口）とアカウント乗っ取りを組み合わせた、Rustエコシステムのサプライチェーン攻撃だった。

3行まとめ

• 245百万DL超のarrayref 0.3.10が、偽クレートproc-macro1（Rustの著名開発者dtolnayになりすまし）を経由してビルド時にリモートバイナリを実行するよう改ざんされていた
• 手口は、正規の0.3.5〜0.3.9をyank（非推奨化）して警告を出し、非yankの0.3.10（マルウェア入り）へ開発者を誘導するというもの
• crates.ioチームが該当バージョンを削除済み。SafeDepはC2アドレス・ファイルパス・ハッシュ値をIoCとして公開している

何が起きたか——SafeDepブログの要約

SafeDepのブログはこう始まる。

On August 20, 2026, a compromised release of the popular Rust crate arrayref appeared on crates.io. Version 0.3.10 added a dependency on a typosquatted crate called proc-macro1, whose build script downloads and runs a remote binary while a project compiles.

（2026年8月20日、人気のRustクレートarrayrefの侵害されたリリースがcrates.ioに現れた。バージョン0.3.10は、proc-macro1というタイポスクワッティングされたクレートへの依存を追加しており、そのビルドスクリプトはプロジェクトのコンパイル中にリモートバイナリをダウンロードして実行する）

重要なのは、この仕組みがビルド時に発動する点だ。ブログは「The code runs at build time, so simply compiling a project that pulled the bad versions is enough to trigger it（コードはビルド時に実行されるため、悪意あるバージョンを引き込んだプロジェクトをコンパイルするだけで発動する）」と説明している。crates.ioチームはすでに該当バージョンを削除済みだという。

侵入経路——本物のarrayrefメンテナーのアカウントが乗っ取られた

ブログによれば、arrayrefと関連クレートappend-only-vecの正規メンテナーはdroundyというアカウントだが、このアカウントは侵害されたとみられる。対応するGitHubリポジトリ（github.com/droundy/arrayref、github.com/droundy/append-only-vec）とアカウント自体が、ブログ確認時点ではすべて404になっていたという。

一方で、悪意あるproc-macro1を公開したのはdtolneyという別アカウントだった。

The username closely resembles David Tolnay's real dtolnay account. Its metadata forges authors = ["David Tolnay "] and points repository at a dtolnay/proc-macro1 path that returns 404.

（このユーザー名は、David Tolnay氏の本物のアカウントdtolnayに酷似している。メタデータはauthors = ["David Tolnay <email>"]を偽装し、repositoryは404を返すdtolnay/proc-macro1というパスを指している）

David Tolnay氏はRustコミュニティで著名な開発者で、proc-macro2をはじめ広く使われるクレート群のメンテナーとして知られる。ブログはこの点を明示的に注意している。

Note that proc-macro1 is not proc-macro2. The real crate that macro authors depend on is proc-macro2. The src/ of the malicious proc-macro1 is a genuine copy of proc-macro2, so builds kept working while the build script ran.

（proc-macro1はproc-macro2ではないことに注意してほしい。マクロ開発者が実際に依存する本物のクレートはproc-macro2だ。悪意あるproc-macro1のsrc/は本物のproc-macro2のコピーであり、そのためビルドスクリプトが実行される間もビルド自体は正常に通り続けた）

yankを使った誘導手口

ブログが指摘するもう1つの手口が、正規版のyank（登録解除に近い操作）を使った誘導だ。

The owner account yanked the older arrayref releases 0.3.5 through 0.3.9. Yanking a crate makes Cargo print a "consider updating to a version that is not yanked" warning, which nudges developers toward the only non-yanked release, the malicious 0.3.10.

（乗っ取られたアカウントは、旧版のarrayref 0.3.5から0.3.9までをyankした。クレートをyankすると、Cargoは「yankされていないバージョンへの更新を検討してください」という警告を出すため、これが開発者を、yankされていない唯一のリリースである悪意ある0.3.10へと誘導する）

RustSecへの報告者自身が、この警告に従って0.3.10を引いてしまったことで問題を発見したとブログは述べている。

影響範囲——GUI系クレートの深い依存先に潜んでいた

ブログによれば、arrayrefはtiny-skia・sctk-adwaita・winitといったクレートから間接的に依存されており、egui・eframe・icedといったRust製GUIフレームワークを使うプロジェクトの多くがこの依存グラフの下流に位置する。数字としては、arrayrefの累計ダウンロード数が約2億4,499万件（確認時点で244,989,384件）、そのうちクリーンな0.3.9が約1億5,200万件を占めるという。ブログはこの数字について「Those numbers measure how widely the crate is used rather than a count of affected builds（これらの数字はクレートがどれだけ広く使われているかを示すものであり、影響を受けたビルドの件数ではない）」と釘を刺している。

技術的な仕込み方——Cargo.tomlに1行、ペイロードはbase64分割

ブログの技術分析セクションによると、arrayref 0.3.10自体のコードに変更はなく、Cargo.tomlに依存関係が1つ加わっただけだった。

[package]
name = "arrayref"
version = "0.3.10"
build = false

[dependencies.proc-macro1]
version = "1.0.107"

proc-macro1はブログ確認時点で1.0.106と1.0.107の2バージョンのみが公開されており、キャレット指定1.0.107は自動的に悪意あるバージョンに解決される。ペイロード配布元のアドレスは、proc-macro1のビルドスクリプト内でbase64エンコードされた断片として分割定義されており、ブログはRustSecのアドバイザリ（rustsec/advisory-db#3161）から引用する形でこう示している。

// proc-macro1-1.0.107/build.rs (quoted in rustsec/advisory-db#3161) const SRC_URL_PARTS: &[&str] = &["aHR0cHM6Ly8=", "MjMuMjU0Lg==", "MTY1Lg==", "MTEyOg==", "OTA4OS8="];

デコードするとペイロード配布元はhttps://23.254.165.112:9089/、C2（コマンド&コントロール）は23.254.165.112:443になる。ブログによれば、この通信はTLSで証明書検証を行わずに接続し、アーキテクチャ別のバイナリを取得。Unix系では/tmp/rust-setupとして実行し、Windowsでは%TEMP%配下にPowerShellスクリプトとVBScriptランチャーを書き出して非表示で起動、コンパイラがその子プロセスを待たないよう切り離すという。

侵害指標（IoC）

ブログが公開しているIoCは次の通り。

arrayref 0.3.10のSHA256は25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae、proc-macro1 1.0.107のSHA256は61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4とブログに記載されている（いずれもブログ本文からの転記で、自分の手元でハッシュを再計算した検証は行っていない）。

発覚まで39分、crates.ioのAPIで現在の状態を確認した

RustSecアドバイザリDBのIssue #3161(発見者jhobern氏の投稿、GitHub APIで取得)には、投稿日時が2026-08-20T07:54:11Zと記録されている。crates.io APIで取得したarrayrefのメタデータでは、updated_atが2026-08-20T07:15:00Zとなっており、これが悪意ある0.3.10の公開時刻とみられる。両者を突き合わせると、汚染バージョンの公開から報告まで、約39分しかかかっていない計算になる。

crates.io APIを直接叩いて、本記事執筆時点(2026年8月末)の現状も確認した。

つまり、SafeDepブログが確認した時点では404だったdroundyアカウントとリポジトリは、その後アカウントの制御を取り戻したメンテナー本人によって復旧しており、悪意あるproc-macro1クレート自体はcrates.io上から完全に抹消されている。悪意ある0.3.10も、単にyankされているのではなく、バージョン一覧そのものから消えている(yankされたクレートは通常APIレスポンスにyanked: trueとして残るため、これは削除に近い扱いだとみられる)。

リポジトリは404、ハッシュの再計算はしていない

当初この記事はSafeDepブログ1本のみを一次ソースにしており、arrayref本体のGitHubリポジトリはブログ確認時点ですでに404となっていたため、乗っ取られたアカウントの正規コードそのものを自分で確認することはできなかった。今回、crates.io APIとGitHub APIを直接叩いて現状を再確認し、droundyアカウント・リポジトリが復旧していること、悪意あるバージョンとproc-macro1クレートがcrates.io上から消えていることは確認できたが、これはあくまで「現時点でAPIが返す状態」であり、SafeDepが報告した侵害の技術的詳細(ペイロードのバイナリ自体の解析など)を自分で再現したわけではない。Hacker Newsで552ポイント・509コメントという大きな反響を呼んだとされるが、コメント欄で指摘された追加の分析や異論は本記事の検証範囲に含めていない。

この記事を書いている自分自身はRustの実務開発者ではなく、arrayrefやproc-macro2を使ったプロジェクトを保守した経験もない。ハッシュ値やIoCの妥当性を独自に再現検証したわけではなく、ブログ本文の記述をそのまま紹介するにとどまる。ダウンロードされたバイナリ・PowerShellスクリプト・VBScriptランチャーの実物を自分の手元で入手・解析してはいない。

関連記事: AI検出ツールは「両方向に壊れている」 / AIコーディングアシスタント比較

感想・指摘はコメント欄へ。