Rust 專案已從 crates.io 中刪除了三個廣泛使用的 Rust 套件的惡意版本。這些套件的維護者帳號遭到入侵，發布了帶有拼寫錯誤依賴項的版本，該依賴項的建構腳本會在編譯期間下載並執行遠端載荷。

受影響的版本是 arrayref 0.3.10、internment 0.8.7 和 append-only-vec 0.1.9，均於 2026 年 8 月 20 日由同一擁有者帳號發布，並在 86 至 107 分鐘內被移除。

由於惡意程式碼位於注入依賴項的建構腳本中，因此建構一個解析到該依賴項的專案就足以執行載荷，而無需呼叫套件本身的任何內容。

開發者應搜尋 ~/.cargo/registry/cache 以查找已刪除的套件檔案，並將 arrayref 固定在 0.3.9 或更早版本，因為 Rust 安全響應團隊在回應期間已撤銷了惡意撤銷的版本。

目前沒有修補版本，尚未分配 CVE 識別符，並且所有三個套件的 RustSec 建議均未記錄任何惡意版本被使用的證據。

「arrayref 套件的新版本已發布，直接依賴於 proc-macro1，這將執行惡意建構腳本。此受入侵的版本於 2026-08-20 發布，約 86 分鐘後被移除，沒有實際使用的證據，」RUSTSEC-2026-0260 指出。

The Hacker News 已聯繫 Rust 安全響應團隊，以了解其發現的基礎以及被刪除版本的下載次數，但在撰寫本文時尚未收到回覆。

Rust 安全響應團隊表示，他們於 8 月 20 日 07:15 UTC 接獲 proc-macro1 套件惡意的報告，並證實該套件帶有一個下載惡意載荷的建構腳本。此發現歸功於 Nextron Systems GmbH 的研究團隊最初發現並報告了此問題。

「我們不認為 arrayref 的作者有惡意行為，但他們的電腦或憑證很可能已被入侵，我們正試圖聯繫他們，」Rust 安全響應團隊表示。

The Hacker News 於 8 月 21 日透過 crates.io API 確認，arrayref 的唯一列名擁有者是使用者 2402，David Roundy，於 2009 年 10 月註冊。

帳號如何被入侵尚未披露。

Rust 安全響應團隊列出了其刪除的惡意版本及其上線時間。

每個受入侵的版本在其資訊清單中都增加了一行，即對 proc-macro1 的依賴，這是無處不在的 proc-macro2 套件的拼寫錯誤。proc-macro1 的程式庫原始碼是 proc-macro2 的真實副本，因此建構過程正常完成。

建構腳本在建構時會從 base64 片段重新組裝其載荷主機和命令與控制 (C2) 位址。然後，它會安裝一個自訂憑證驗證器，其三個驗證方法無條件返回成功，從而禁用 TLS 驗證。它會根據作業系統和 CPU 架構選擇四種載荷之一。

在 Unix 和 macOS 上，它將位元組寫入 /tmp/rust-setup，將檔案標記為可執行，並將其以分離模式啟動，將 C2 位址作為第一個參數。在 Windows 上，它將一個 PowerShell 腳本寫入 %TEMP% 並透過 wscript.exe 下的 VBScript 啟動器隱藏啟動，然後放棄子進程，此步驟在原始碼中被註解為逃避 Cargo 的作業物件，以便建構不會等待它。

根據提交給 RustSec 建議資料庫的研究人員報告，傳遞依賴於擁有者帳號在同一分鐘內撤銷 arrayref 0.3.5 至 0.3.9，使得受入侵的版本成為 Cargo 不會警告的唯一版本。

「傳遞：0.3.5-0.3.9 均由擁有者帳號撤銷，因此 cargo 的『考慮更新到未撤銷版本』的警告是誘餌。這就是我如何中招的，」報告者 GitHub 使用者 jhobern 表示。

The Hacker News 於 8 月 21 日透過 crates.io API 發現，arrayref 的總下載次數為 245,385,500 次，在截至 8 月 20 日的 90 天內為 53,905,601 次，並且 crates.io 上有 403 個不同的套件依賴於它。我們還於 8 月 21 日透過 crates.io 索引驗證了報告中命名的依賴鏈的每個環節：winit 需要 sctk-adwaita ^0.10.1，它需要 tiny-skia ^0.11，它需要 arrayref ^0.3.6。

該鏈中的每個需求都是 0.3.x 的 caret 範圍，而 0.3.x 的 caret 範圍接受 0.3.10。相同的檢查發現 blake3 在版本 1.8.6 中聲明 arrayref 作為依賴項，但在 8 月 20 日 09:09 UTC 發布的 1.8.7 版本中不再聲明，而 blake2b_simd 和 blake2s_simd 在當天早上 09:25 和 09:26 UTC 發布的版本中也移除了相同的依賴項。

根據 Wiz 的說法，第二階段植入程式透過 HTTPS POST 到路徑 /49890878 進行信標傳輸，透過 Windows 的 Registry Run 金鑰、macOS 的 LaunchAgent 和 Linux 的 systemd 使用者服務進行持久化，並支援四種命令，涵蓋終止、C2 重組態、持久化安裝以及下載和執行進一步的腳本。Wiz 表示，它透過查詢 SQLite 登入資料庫來竊取 Chrome、Brave 和 Edge 的瀏覽器憑證。

Nextron 研究人員的分析稱，分析的 Windows 階段僅查詢 origin_url 和 username_value 列，而不直接提取 password_value，但該分析僅涵蓋了 Windows 載荷，Linux 和 macOS 載荷已進行雜湊處理但未分析。相同的分析指出，該套件可能由 cargo build、cargo check 和 cargo test 觸發。

StepSecurity 分享了以下入侵指標 (IoCs)。

Wiz 表示，該基礎設施與近期北韓的供應鏈攻擊有顯著重疊，點名了 Mastra npm 攻擊和 axios 攻擊。

微軟高度確信 Mastra 活動可歸因於 Sapphire Sleet，而 Google Threat Intelligence Group (GTIG) 將 axios 攻擊歸因於一個它現在追蹤為 MIDNIGHT NEPTUNE（前身為 UNC1069）的演員。沒有供應商將 crates.io 事件歸因於任何已命名的演員。

「儘管 axios 的惡意版本在發布後三小時內已從 npm 註冊表中移除，但由於該套件每週下載量超過 1 億次，因此損害範圍估計很廣，」GTIG 和 Mandiant 在 7 月 30 日的報告中建議對新發布的第三方資產實施冷卻期。

Cargo 沒有內建的對應功能。一個穩定全局最小發布年齡設定的拉取請求，該設定將延遲發布年輕於設定年齡的依賴項，於 8 月 18 日進入最後評論期，即攻擊前兩天，截至 8 月 21 日仍保持開啟狀態且未合併。GitHub 於 7 月為 Dependabot 發布了類似的冷卻預設值。

在 2025 年 9 月的一個案例中，兩個冒充日誌庫的惡意套件僅在運行時執行，這是 crates.io 當時區分的差異。