2026年6月11日，安全研究人员和 Arch Linux 社区披露了对 Arch 用户仓库（AUR）的大规模供应链攻击。攻击者劫持了400多个社区软件包，将其转变为恶意软件传播网络。虽然直接影响范围仅限于 Arch Linux 系统，但该活动是教科书级别的案例，展示了现代攻击者如何通过滥用开源生态系统中的信任来入侵开发者和 CI 基础设施。
2026年6月11日，安全研究人员和 Arch Linux 社区披露了对 Arch 用户仓库（AUR）的大规模供应链攻击。攻击者劫持了超过 400个社区软件包，将其转变为恶意软件传播网络。虽然直接影响范围仅限于 Arch Linux 系统，但该活动是教科书级别的案例，展示了现代攻击者如何通过滥用开源生态系统中的信任来入侵开发者和 CI 基础设施。
本文将深入分析事件始末、恶意软件的工作原理，以及这对运行 CI/CD 和自托管运行器的团队、以及使用 MacOS/Windows/Linux 的开发者机器意味着什么。
什么是 Arch 用户仓库（AUR）？
AUR 是一个由社区驱动的仓库，Arch Linux 用户在此分享官方仓库中没有的软件的构建脚本（PKGBUILD）。用户或 AUR 辅助工具克隆这些 PKGBUILD 并在本地构建原生软件包，这意味着这些脚本中的任何恶意逻辑都会在构建或安装过程中直接在开发者的机器上执行。
AUR 的一个关键特性是所有权转移：如果维护者放弃了某个软件包，另一个用户可以申请接管它，继承该软件包的名称和声誉。这一机制使有用的软件得以延续，但也为攻击者悄悄接管受信任的软件包创造了强有力的途径。
"Atomic Arch"供应链攻击活动
Sonatype 研究人员将2026年6月的这起事件命名为"Atomic Arch"。他们在发现攻击者系统性地接管了孤立的 AUR 软件包并注入恶意构建逻辑后，进行了命名。后续的社区分析表明，影响范围比最初报告的要大得多：超过400个软件包被修改为执行攻击者控制的代码。
攻击模式看似简单，实则暗藏玄机：
1. 接管孤立的软件包。 攻击者针对的是已有用户基础和合法使用历史的软件包。
2. 注入恶意依赖。 他们修改 PKGBUILD 或安装钩子以运行 npm install atomic-lockfile（及其变体如 js-digest），拉取恶意 Node 软件包。
3. 静默执行。 当用户安装或更新 AUR 软件包时，它会静默地获取并执行恶意依赖。
这些并非明显可疑的软件包。它们是随着时间积累信任的普通工具，攻击者仅通过添加一个依赖就将它们转变为恶意软件分发渠道。
恶意软件的实际功能
伪装成 atomic-lockfile 的恶意 npm 软件包包含用 Rust 编写的凭据窃取有效载荷，在获得 root 权限的系统上还具备类似 rootkit 的功能。
该窃取程序针对开发者和 CI 主机上的高价值资产：
• 浏览器 cookie 和会话令牌（用于 SSO、云控制台、SaaS 应用）
• SSH 密钥和 known_hosts
• GitHub、npm 及其他开发者令牌
• Slack、Discord 和 Teams 会话
• Docker/Podman 凭据和云访问密钥
在具有提升权限的系统上，恶意软件还尝试基于 eBPF 实现持久化，以隐藏进程和文件活动，使检测和清理变得更加困难。被入侵的主机应被视为完全不可信：需要从干净介质重新构建并轮换所有暴露的凭据。仅进行一次恶意软件扫描是不够的。
谁受影响、谁不受影响
AUR 是 Arch Linux 特有的生态系统。
直接受影响：
- 使用 AUR 安装软件包的 Arch Linux 及基于 Arch 的发行版（EndeavourOS、在使用 AUR 时的 Manjaro）。
- 在 bootstrap 或作业步骤中安装 AUR 软件包的自托管 CI 运行器或构建代理。
- 在 WSL2 中运行 Arch 并在该环境中安装 AUR 软件包的 Windows 开发者——这是希望 在 Windows 上使用 Linux 工具链的开发者常用的配置。
不会直接受到此向量影响：
- GitHub 托管的运行器（Ubuntu、Windows、macOS 镜像），它们不使用 AUR。
- 在 RHEL/Rocky、Debian/Ubuntu 或 Windows 上的自托管运行器，除非通过嵌套虚拟化或类似设置拉取 Arch/AUR。
- macOS 和 Windows 开发者机器——不过 macOS 面临结构上类似的风险，因为 Homebrew 具有相同的软件包所有权转移模式。针对被遗弃的 Homebrew 公式或第三方 taps 的劫持活动会以完全相同的方式影响 macOS 开发者机器。
然而，恶意软件的目标——开发者凭据、GitHub 令牌、云密钥——是驱动 CI/CD 管道和访问生产环境的核心资产。攻击者只要入侵一台基于 Arch 的开发者笔记本电脑，就能转向为非 Arch 生产系统提供支持的 GitHub、npm 或云账户。
为什么这超出 Arch 社区的范围
"Atomic Arch"活动对认真对待供应链安全的任何团队都有更广泛的影响。
劫持所有权优于域名仿冒攻击。 攻击者不是发布看起来相似的软件包，而是针对被遗弃但受信任的软件包，一举继承用户和声誉。这一模式在 npm、PyPI 和 GitHub Actions 中越来越常见，维护者被社交工程或Inactive 项目被悄悄接管。
构建脚本是一个执行环境。 PKGBUILD、postinstall 钩子、GitHub Actions 工作流和 Dockerfile 都以强大的权限运行，但通常只是草率审查（如果有的话）。"Atomic Arch"再次提醒我们，安装时逻辑是一级攻击面。
有效载荷针对开发者和 CI 进行了调优。 恶意软件不攻击随机消费者数据，而是攻击解锁整个组织的密钥、令牌和会话。这与其他最近的活动一致，恶意 npm 软件包或 GitHub Actions 以大规模方式泄露 CI 密钥。
即使你从未接触过 Arch，这个事件也是另一个数据点，展示了攻击者的目标方向以及他们需要改动多少代码就能抵达你的管道。
立即响应：现在该怎么做
如果你的组织在任何开发者工作站或自托管运行器上使用 Arch，请将这视为事件响应时刻，而不仅仅是值得关注新闻。
1. 识别可能受影响的主机。 枚举你环境中的 Arch 及基于 Arch 的系统（笔记本电脑、实验机器、自托管 CI 运行器）。审查自2026年6月初以来的 AUR 安装和升级历史，并与已知恶意软件包列表进行交叉检查。
2. 如果恶意软件包已运行，假定凭据已泄露。 轮换 SSH 密钥、GitHub 令牌、npm 令牌、云 API 密钥、保险库令牌以及在受影响机器上存储或使用的其他任何密钥。使浏览器会话失效，并在可能的情况下重新生成 passkey，特别是对于管理员和 SSO 账户。
3. 重建高度可信的系统。 对于恶意有效载荷可能以 root 身份运行的任何主机，将其视为已被入侵。从可信介质重新构建。只有在重新安装并使用新凭据重新配置后，才能将其重新加入 CI 或基础设施。
4. 添加行为监控。 监控构建主机和运行器上的异常软件包管理器调用、构建步骤期间的网络出口以及可疑 systemd 单元或 eBPF 对象的创建。警惕与粘贴站点、文件共享服务或 Tor 的异常出站连接。
StepSecurity 如何提供帮助
在 StepSecurity，我们构建专门用于在最关键的地方检测这类威胁的工具——无论是在你的 CI 管道还是开发者机器上。
Harden-Runner 在运行时监控 GitHub Actions、GitLab CI 和 Azure DevOps 管道步骤，检测意外的网络出口、未授权的进程生成和异常的包管理器活动——这正是"Atomic Arch"恶意软件在构建主机上运行时表现出的行为。
Dev Machine Guard 针对攻击面的另一半：开发者工作站。由于"Atomic Arch"首先针对笔记本电脑和本地环境，窃取 SSH 密钥、GitHub 令牌和浏览器会话后才转向生产环境，Dev Machine Guard 在开发者机器上提供可见性，在可疑活动发生时立即发出警报。
供应链攻击不会放缓。最佳防御是能够看到你的构建环境和开发者机器实际运行的情况，以及在密钥离开设备之前检测异常行为的能力。