Atomic Arch：一場劫持 1,900 個 AUR 套件的信任攻擊

SafeDep 的攻擊活動頁面與社群彙整清單最終列出了 1,937 個受影響的 AUR 套件名稱，充分顯示了這次攻擊的波及範圍之廣 。重要的是，Arch Linux 官方儲存庫（core、extra、community）並未受到影響──這是一起專門針對 AUR 的事件 。

攻擊手法：利用信任機制的工作流程

Atomic Arch 攻擊並非是對 Arch Linux 基礎設施的入侵行動。相反地，攻擊者精準地利用了 AUR 中的孤兒套件認養流程──一個允許任何社群成員認領已遭棄置套件的機制 。

攻擊行動分為兩個明顯的波次展開，攻擊者不斷調整方法以躲避偵測。

第一波攻擊：npm 掛鉤（6 月 11 日）

攻擊者有系統地認養了孤兒套件。一旦取得了維護者權限，他們並非直接修改軟體原始碼本身──此舉可能導致校驗碼（checksums）不符，進而觸發警報。他們改為修改建置腳本 PKGBUILD，在其中注入惡意的 npm 相依套件：atomic-lockfile（v1.4.2） 與 js-digest（v4.2.2） 。這些惡意套件被設定為在執行 makepkg 程序時自動啟動。為了進一步隱藏惡意行為，這段程式碼被嵌入 .install 腳本中，並利用殼層字串分割（shell string splitting）、混合引號（mixed quoting）以及十六進位跳脫（hexadecimal escapes）等技巧來偽裝 。

第二波攻擊：改用 Bun（6 月 12 日）

僅隔一天，第二波攻擊隨即出現。這次，攻擊者將原本使用 npm 的安裝路徑，改為基於 Bun 的安裝流程，並使用了另一個名為 lockfile-js（v1.4.2）的惡意套件 。此舉增加了偵測上的複雜度，因為許多第一波的入侵指標（IoC）都聚焦在 npm 套件庫上，安全工具必須更新才能監控到新的執行環境與相依套件 。

藉由只對建置說明檔（build instructions）下毒，而非軟體本身，攻擊者成功繞過了傳統的完整性檢查機制。上游原始碼看起來乾淨無虞，惡意軟體只在建置期間才被擷取並執行，這使得未手動檢查 PKGBUILD 腳本的使用者根本無法察覺異狀 。

惡意酬載：憑證竊取器與 Rootkit

凡是用於建置受感染套件的機器，都會接收到一個專為間諜活動與持續潛伏設計的雙階段酬載。

• Rust 為基礎的憑證竊取器（Rust-based Credential Stealer）： 一個專注於收割開發者機密資訊的二進位檔，目標包括瀏覽器會話、SSH 金鑰、GitHub 權杖、npm 權杖、Slack/Teams 會話、Vault 權杖、Docker/Podman 憑證以及雲端存取金鑰等 。
• eBPF Rootkit（僅限 root 權限）： 若套件是以 root 權限建置，該惡意軟體便會部署一個 eBPF Rootkit，使其能夠隱藏自身的檔案、執行程序以及網路活動，不被 ps 和 htop 等標準偵測工具發現。該 Rootkit 使用 /sys/fs/bpf/ 作為持續潛伏的機制，使其極難被移除 。

結合了憑證竊取器與核心層級 Rootkit，此攻擊對開發者構成極度嚴重的威脅，尤其開發者的工作站通常儲存著高權限的存取金鑰與敏感資料。

社群與開發者的應對措施

Arch Linux 社群與資安產業迅速動員，但此次攻擊的規模使得應對工作變得相當複雜。

• Arch 團隊的行動： Arch 貢獻者於 6 月 11 日開設了一個集中的 AUR 回報討論串，並開始著手還原惡意提交（commits）、封鎖攻擊者帳號，以及清理孤兒套件池。Arch Linux 亦在隔週一暫停了 AUR 的新帳號註冊功能，以防情況繼續惡化 。Arch 套件打包者 Jonathan Grotelüschen 證實，團隊正努力「還原或刪除所有惡意提交，並封鎖相關責任帳號」。
• 社群內的衝突： 這次攻擊引發了激烈的討論。在像是 PrivacyGuides 論壇等平台上的熱烈爭辯中，有些社群成員呼籲應完全關閉 AUR，他們認為在如此大規模的攻擊下，這種基於信任的模式已從根本上崩壞 。
• 第三方單位的回應： 包括 Sonatype、Corgea、雲端安全聯盟（CSA）以及 TrueSec 等安全機構，紛紛發布了詳細的分析報告、入侵指標（IoC）以及社群偵測腳本（例如 aur-malware-check），以協助使用者稽核自己的系統 。

回應過程中一個主要的摩擦點在於：官方 Arch 團隊並未立即發布一份單一、權威的完整受影響套件清單，導致使用者必須仰賴來自 SafeDep 和 Corgea 等第三方單位整理的清單 。

對 Linux 生態系統的教訓

Atomic Arch 攻擊暴露了仰賴志願者維護、基於信任的社群儲存庫在結構上的弱點。

• 孤兒陷阱是系統性風險： 任何使用者都能在沒有身份驗證或強制性程式碼審查的情況下，立即認養並修改一個遭棄置的套件，這項機制將一個便利的功能變成了高影響力的攻擊途徑 。
• 建置時注入繞過了完整性檢查： 傳統的防禦機制仰賴驗證原始碼壓縮檔的完整性。由於 Atomic Arch 攻擊下毒的是建置腳本而非原始碼，標準的校驗碼程序未能提供任何保護 。
• 跨生態系統的供應鏈成為新戰場： 這次攻擊利用 npm 與 Bun 套件庫，將惡意軟體散佈到 Linux 生態系統中，證明了單一套件庫中一個遭感染的套件，就能對跨平台環境產生連鎖效應 。

受影響的使用者現在該怎麼做

安全研究人員與 Arch 社群給出的指引口徑一致：這不是單純移除單一套件就能了事的情況。

1. 假設主機已全面淪陷： 請將任何在 2026 年 6 月 9 日至 12 日期間，曾建置或更新過 AUR 套件的主機視為已完全受駭 。
2. 從乾淨媒體重新安裝： 單純的惡意軟體掃描並不可靠，因為 eBPF Rootkit 的設計就是為了躲避偵測工具。唯一能保證徹底修復的方法，是使用受信任的安裝媒體重建受影響的系統 。
3. 立即更換所有憑證： 請假設憑證竊取器已將所有機器上可存取的機密資訊都竊取走了：包括 SSH 金鑰、GitHub 與 npm 權杖、Vault 權杖、雲端存取金鑰、瀏覽器會話，以及 Docker/Podman 憑證等 。
4. 稽核 AUR 安裝歷史： 執行

   pacman -Qm

   指令，列出系統上安裝的所有外來套件（foreign packages），並將其與社群公布的惡意套件清單進行交叉比對 。
5. 檢查入侵指標（IoCs）： 在建置快取（build caches）中搜尋 atomic-lockfile、lockfile-js 或 js-digest 的痕跡，以及 /sys/fs/bpf/ 目錄下的可疑項目 。
6. 將此事件視為資安事件回應處理： 組織機構不應將此視為簡單的掃描演練。所有在攻擊期間曾從 AUR 拉取套件的 Arch 開發者工作站或 CI/建置伺服器，都應視為一起需要全面啟動應變措施的資安事件來處理 。