Arch Linux AUR 遭大规模投毒：超 1500 个软件包被植入后门，开发者该如何自救？

本文面向所有 Arch Linux 用户及开发者，详细拆解 2026 年 6 月 AUR 供应链攻击的全过程，并提供可操作的自查与应急清单。

一、事件概述：这不是演习

2026 年 6 月 11 日至 12 日，Arch Linux 的用户软件仓库 AUR 遭遇了一场精心策划的大规模供应链攻击。攻击者通过领养无人维护的"孤儿"软件包，在构建脚本中植入恶意代码。第一波涉及 400 余个 软件包，第二波更是飙升至 1500 余个。安全公司 Sonatype 将此次攻击命名为 "Atomic Arch"（CVSS 8.7）。

值得庆幸的是，Arch Linux 官方仓库未受影响，问题仅出在社区维护的 AUR 中。但 AUR 恰恰是 Arch 用户获取非官方软件的主要渠道，涉及面极广。

二、攻击手法拆解：信任是如何被窃取的

这次攻击的高明之处在于，它并没有利用任何系统漏洞，而是直接攻击了信任模型本身。

2.1 领养孤儿包：继承信任的捷径

AUR 允许社区成员领养被原维护者放弃的"孤儿"软件包。攻击者正是利用了这一机制，通过正常流程获取了这些软件包的控制权。被攻击的软件包保留了原有的名称、历史记录和积累的用户信任，唯一被修改的是构建脚本。

Sonatype 的研究人员一针见血地指出："攻击者并非从零开始建立信任，而是在窃取已经存在的信任。"

2.2 伪造提交者身份

攻击者还伪造了 Git 提交元数据，让恶意修改看起来像是来自知名维护者 "arojas"。事后 Arch Linux 的 Trusted User 确认，该账户从未被入侵。这种身份 spoofing 让普通用户在查看提交历史时很难产生警觉。

2.3 恶意代码注入：一行命令引发的灾难

攻击者在 PKGBUILD 或 .install 脚本中加入了一行看似无害的命令：

npm install atomic-lockfile minimalist chalk

这行命令会在软件包构建时自动执行，拉取名为 atomic-lockfile 的恶意 npm 包。该包的 preinstall 钩子会触发一个名为 deps 的 Linux ELF 可执行文件。

第二波攻击甚至更换了投递方式，改用 bun install js-digest，显示出攻击者在持续迭代策略。

三、恶意软件深度解析：它到底做了什么

独立安全研究员 Whanos 对恶意程序进行了完整的逆向分析。这个用 Rust 编写的二进制文件

SHA-256:6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b是一个高度针对开发者工作站的凭证窃取器，并附带可选的 eBPF Rootkit 功能。

3.1 数据窃取范围

恶意程序会系统性地收集以下敏感信息：

浏览器数据

• Chrome、Edge、Brave、Vivaldi、Opera 等 Chromium 系浏览器的 Cookie、Token 和本地存储
• 涵盖 Flatpak 版本的浏览器

协作工具

• Slack 会话和 Token
• Microsoft Teams 的 skypeToken 和缓存凭证
• Discord 的用户 Token、服务器权限、MFA 状态

开发者凭证

• GitHub Personal Access Token 和 SSH 密钥
• npm 发布凭证
• HashiCorp Vault Token
• OpenAI / ChatGPT API Key
• Docker 和 Podman 的注册表凭证

系统级数据

• SSH 私钥和 known_hosts
• VPN 配置文件（.ovpn）
• Bash / Zsh / Fish 命令历史
• Shell 中包含密码或密钥的命令记录

3.2 数据外泄路径

窃取的数据通过两条路径外传：

1. 文件上传
   ：通过 HTTP POST 上传到 temp.sh 公共文件分享服务
2. 命令控制
   ：通过本地 SOCKS 代理连接 Tor 洋葱服务 olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion，发送加密的心跳和任务请求

3.3 持久化机制

无论是否获取 root 权限，恶意程序都会建立持久化：

• Root 权限
  ：在 /var/lib/ 下生成随机名称的目录存放自身，并在/etc/systemd/system/ 创建 systemd 服务，配置 Restart=always 和 RestartSec=30
• 普通用户
  ：在当前用户主目录和 ~/.config/systemd/user/ 下建立类似的持久化机制

这意味着即使你以为删除了软件包，恶意程序依然可能在后台运行。

3.4 eBPF Rootkit：内核级的隐身术

当恶意程序以 root 权限运行时，会加载一个 eBPF 程序。这个 Rootkit 的运作方式极为精巧：

• 挂钩 getdents64 系统调用
  ：拦截所有目录列表请求
• 隐藏进程
  ：通过 /sys/fs/bpf/hidden_pids 映射表，让 ps、top 等工具看不到恶意进程
• 隐藏文件
  ：通过 /sys/fs/bpf/hidden_names 映射表，让 ls、find 看不到相关文件
• 隐藏网络连接
  ：通过 /sys/fs/bpf/hidden_inodes 映射表，让 netstat、ss 看不到恶意套接字
• 反调试
  ：检测到 ptrace 附加尝试时直接终止进程

这意味着在受感染的机器上，标准系统工具可能完全显示不出异常，而系统实际上已经被深度控制。

四、自查清单：你的系统是否中招

如果你曾在 2026 年 6 月 11 日或之后 安装或更新过 AUR 软件包，请立即执行以下检查。

4.1 检查构建日志

# 查看 pacman 日志中 6 月 11 日后的 AUR 安装记录grep -E ”(installed|upgraded)” /var/log/pacman.log | grep ”2026-06-1[1-9]”# 检查 npm 缓存中是否存在恶意包find / -name ”atomic-lockfile” -type d 2>/dev/nullfind / -name ”js-digest” -type d 2>/dev/null# 检查构建缓存中是否有可疑的 deps 文件find ~/.cache/yay ~/.cache/paru /tmp /var/tmp -name ”deps” -type f 2>/dev/null

4.2 检查持久化服务

# 查看系统级 systemd 服务systemctl list-units --type=service --state=running | grep -v ”\.device”# 查看用户级 systemd 服务systemctl --user list-units --type=service --state=running# 检查 /etc/systemd/system/ 和 ~/.config/systemd/user/ 下的陌生服务ls -la /etc/systemd/system/*.service | grep -E ”(Restart|hidden)”ls -la ~/.config/systemd/user/*.service 2>/dev/null

4.3 检查 eBPF 程序

# 列出所有加载的 eBPF 程序sudo bpftool prog list# 检查 /sys/fs/bpf/ 下是否有可疑的映射表sudo ls -la /sys/fs/bpf/# 特别关注以下名称# hidden_pids, hidden_names, hidden_inodes

4.4 检查网络连接

# 查看所有网络连接（Rootkit 可能会隐藏部分结果）sudo ss -tulnpsudo netstat -tulnp# 检查本地回环上的异常监听sudo ss -tulnp | grep ”127.0.0.1”# 查看路由和代理设置cat /etc/environment | grep -i proxycat ~/.bashrc | grep -i proxy

4.5 使用社区检测脚本

社区贡献者 lenucksi 已经发布了自动化检测脚本：

# 克隆检测脚本git clone https://github.com/lenucksi/aur-malware-checkcd aur-malware-check# 运行检测（请仔细阅读脚本内容后再执行）python3 -m aur_check --full

五、应急响应：如果确认中招

5.1 立即隔离

• 断开受感染机器的网络连接
• 如果是 CI/CD 构建服务器，立即停止所有构建任务
• 如果是开发工作站，停止所有与代码仓库、云服务的交互

5.2 凭证全面轮换

假设所有凭证都已泄露，立即轮换以下所有内容：

• SSH 密钥：重新生成密钥对，更新所有服务器的 authorized_keys
• GitHub Token：撤销所有 Personal Access Token 和 Deploy Key
• npm 凭证：重置 npm 账户密码和双因素认证
• Vault Token：重新签发所有 HashiCorp Vault Token
• 云服务凭证：轮换 AWS/GCP/Azure 的 Access Key
• 协作工具：重新登录 Slack、Discord、Teams，撤销所有会话
• 浏览器数据：清除所有保存的密码，重新登录关键服务
• API Key：重置 OpenAI、ChatGPT 及其他服务的 API Key

5.3 系统处置建议

• 如果构建时使用了 root 权限
  ：由于 eBPF Rootkit 运行在内核层，常规清理无法保证系统干净。建议从可信介质重新安装 Arch Linux。
• 如果只是普通用户构建
  ：删除可疑的 systemd 服务、清理 /sys/fs/bpf/ 下的异常映射表、删除 /var/lib/ 和主目录下的可疑文件。但鉴于 Rootkit 的隐蔽性，重新安装仍然是最安全的选择。

5.4 通知相关方

• 如果受感染机器有访问公司代码仓库的权限，立即通知安全团队
• 检查 GitHub/GitLab 的审计日志，确认是否有异常操作
• 如果使用了共享的 CI/CD 环境，通知所有相关项目维护者

六、长期防御：如何避免再次中招

6.1 安装前审查 PKGBUILD

# 使用 yay 时先查看 PKGBUILDyay -Gp <package-name># 手动检查构建脚本内容cat PKGBUILD | grep -E ”(npm install|bun install|curl|wget)”

6.2 关注软件包维护状态

• 在 AUR 页面查看软件包的"领养"历史
• 警惕近期突然被领养且之前长期无人维护的软件包
• 优先选择有活跃维护者和频繁更新的软件包

6.3 使用沙箱构建

# 在容器或虚拟机中构建 AUR 软件包# 避免直接在主系统上执行未知的构建脚本

6.4 安装 npm 包时禁用生命周期脚本

# 如果必须安装来源不明的 npm 包npm install --ignore-scripts <package># 推荐V2ex站长的一个npm设置，可以大幅度减少npm包感染的风险# 在npmrc中设置 min-release-age=7；

6.5 定期审计已安装软件

# 列出所有非官方仓库安装的软件包pacman -Qm# 定期检查这些软件包的维护状态

七、事件时间线

八、关键指标汇总（IOC）

恶意文件哈希

• SHA-256:6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
• MD5: 42b59fdbe1b72895b2951412222ebf40

恶意 npm 包

• atomic-lockfile@1.4.2
• js-digest
  （第二波）

C2 地址

• olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

外泄服务

• temp.sh

持久化特征

• systemd 服务配置包含 Restart=always 和 RestartSec=30
• eBPF 映射表名称：hidden_pids、hidden_names、hidden_inodes

九、写在最后

这次 AUR 投毒事件给整个开源社区敲响了警钟。它告诉我们：

• 供应链安全不是抽象概念
  ，它直接关系到每一位开发者的凭证安全和代码安全
• 社区仓库的信任模型需要重新审视
  ，孤儿包的领养机制虽然降低了维护门槛，但也引入了系统性风险
• eBPF 技术被武器化
   是一个值得警惕的趋势，内核级的 Rootkit 让传统的检测手段变得不再可靠
• 最小权限原则
   依然是最有效的防御手段之一——如果构建软件包时不用 root，至少可以避免最危险的 eBPF Rootkit 组件被激活

对于 Arch Linux 用户来说，AUR 依然是不可替代的软件宝库。但在享受便利的同时，也请保持必要的警惕。毕竟，自由软件社区的安全，最终要靠社区中的每一个人来守护。

免责声明：本文内容基于公开的安全研究报告和新闻报道整理，仅供信息分享和安全教育用途。具体处置决策请结合实际情况，并参考 Arch Linux 官方安全公告。如涉及生产环境，建议咨询专业安全团队。

参考资料：

• Sonatype Atomic Arch 分析报告
• Whanos 逆向分析报告（ioctl.fail）
• BleepingComputer 新闻报道
• Arch Linux 官方邮件列表（aur-general）
• PrivacyGuides 受影响软件包统计