作者：韩启明｜OC 政策与安全编辑

据 LWN 报道，Arch Linux 因大量恶意软件包接管和后续提交，暂停了 Arch User Repository，也就是 AUR 中孤儿包的“认领”功能。分析显示，本轮载荷包含通过 Tor 接收命令的远程访问木马，并尝试上传多类用户数据。

一句话结论：攻击者没有攻破 Arch 官方仓库，而是利用 AUR“无人维护的软件包可被新维护者接管”的协作机制，把维护权转移变成供应链入口。

AUR 和 Arch 官方二进制仓库不是一回事。AUR 存放社区提交的 PKGBUILD 等构建脚本，用户或辅助工具根据脚本下载源码、执行构建并安装。AUR 首页一直提醒这些内容由用户产生、风险自负，但在实际使用中，许多人把 yay 或其他辅助工具显示的更新当成普通系统升级，很少逐行检查脚本变化。

孤儿包认领原本是维护机制：旧维护者离开后，新贡献者可以接手，让软件继续更新。攻击者反过来寻找这些低关注、仍有安装量的包，注册账户、获得维护权，再提交带恶意载荷的新版本。代码审查缺口不在某一行漏洞，而在“谁成为维护者”这一步几乎没有信誉积累。

Arch 项目在 6 月已经发布 安全事件通知，暂停新账户注册，并警告用户审查 PKGBUILD 和安装脚本。注册功能在 7 月 13 日恢复并增加限制，但随后恶意接管仍在出现，说明只提高注册门槛不足以保护旧包的控制权。

关闭认领功能可以立刻切断这条路径，代价是无人维护的软件包更难恢复更新。这只是临时控制，不是完整解决方案。更持久的办法可能包括接管冷静期、旧版本与新版本差异提示、维护者信誉、敏感脚本静态检查，以及对突然新增二进制下载和安装阶段网络行为的额外审核。

用户侧也不能只看包名。一个用了多年的熟悉 AUR 包，维护者和构建脚本可能已经变化。更新前检查维护权变更、上游 URL、校验值、prepare() 与 package() 中新增命令，比“这个包以前没出过问题”更有意义。

关键事实

• 受影响范围：AUR 社区软件包，不是 Arch 官方仓库
• 被利用机制：孤儿包可被新账户认领并提交更新
• 已知载荷：可通过 Tor 接收命令并上传用户数据的远程访问木马
• 当前处置：暂停 AUR 软件包认领功能

OC 判断

软件供应链最脆弱的地方经常不是热门项目，而是“还有人用、已经没人看”的长尾包。平台可以声明 AUR 内容不受审核，但当自动更新工具把社区脚本包装成顺滑体验时，也必须给维护权变化和高风险差异更醒目的信号。

为什么重要

• 对开发者：AUR 更新前应查看提交差异，尤其关注维护者变化、外部二进制和安装脚本。
• 对项目维护者：长期无法维护时，明确归档或指定继任者比静默变成孤儿包更安全。
• 对软件仓库：账户风控不能替代接管流程本身的权限设计和审计。

参考来源

• Arch Linux disables AUR package adoption
• Arch Linux: Active AUR malicious packages incident
• Arch User Repository