XZ Utils是一款压缩工具，几乎运行在所有现有的Linux系统上。当你的服务器解压缩软件包，或Docker容器展开镜像层时，都需要某个程序处理压缩逻辑。在大多数Linux设备中，这个程序就是xz。它隐匿运行，无处不在，却常常被我们忽略。

该项目仅由一位芬兰开发者独立维护，他名叫Lasse Collin。2022年，他公开表示自己正遭受心理健康问题的困扰。而一场疑似由国家级情报机构主导的行动，在此前数月便已悄然展开。他们精准地利用了这一信息。

这是开源历史上最复杂的供应链攻击，以及该攻击所针对的那一个人的故事。

2022年6月，Collin在xz-devel邮件列表中发布了一条消息，这条消息本应给整个行业敲响警钟：

一个负责维护几乎遍布所有Linux发行版压缩库、每天在数十亿设备上处理数据的核心人员，公开坦言自己已处于崩溃边缘，几乎无法正常工作，恳请大家的耐心与理解。

然而到来的，却是一场精心策划的施压行动。

我们斥资数十万欧元进行GDPR和ISO 27001合规审计，转头却盲目相信一个自称“快要溺水”的人独自维护的压缩库。

要知道，此时此刻，你的服务器正运行着这段代码。

你是否检查过，那些支撑着你生产系统的库，究竟是谁在维护？

从2022年4月开始，一些从未在互联网任何角落留下过痕迹的账号，突然开始现身于xz-devel邮件列表。调查记者 Brian Krebs证实，这些身份在网络上没有任何其他踪迹，哪怕是在包含数十亿条记录的大型数据泄露库中也找不到，这在现实中几乎是不可能发生的。显然，这些是为了此次行动而专门捏造的虚假身份。

其中一人写道：“除非换人维护，项目休想有进展。”

另一条信息后来被分析为“精心算计的心理战”。这条消息表面上对Collin的心理健康表达了同情，实则暗示他应该认清自己的局限，主动让贤。

试想一下，你正处于抑郁之中，独自一人、无偿地维护着至关重要的软件，每天都挣扎着渡过难关。现在突然冒出几个陌生人，用看似好心的方式告诉你：你该放弃了。

这就好比有人发现你家的门锁坏了，于是派了几个热心邻居敲开你的门，关切地说：“你看上去很累，要不把钥匙交给我们保管一阵子？”实际上，这些所谓的热心邻居其实是外国情报机构安插的特工。

这一连串施压攻势的最终目的只有一个：攻破Collin的心理防线，让他信任那个叫”Jia Tan“的账号。

XZ Utils 社会工程攻击流程

Jia Tan（GitHub用户名：JiaT75）于2021年10月首次向xz-devel提交代码。早期提交的都是合规且高质量的代码，无论是Bug修复还是测试改进，都做得无懈可击。这类贡献让工作繁重的维护者倍感欣慰，终于有人站出来分担了。

我在开源领域摸爬滚打这么多年，深知当一位新贡献者开始为项目做出贡献时，那种感觉有多么令人欣慰。在你独自包揽所有工作数月之后，突然有人出现了：他不仅理解代码库，还能编写简洁的补丁，并能快速响应代码审查。那一刻，你会心生感激，觉得不再孤军奋战。而这，恰恰是这场阴谋所精心设计的诱饵。

资料来源：作者，XZ Utils攻击时间线

在长达两年多的时间里，Jia Tan积累了一份堪称完美的代码提交履历。2022年底，他获得提交权限；2023年，晋升为拥有发布签名权的联合维护者。对于当时已不堪重负的Collin来说，这无疑是雪中送炭，让他得以从繁重的维护工作中解脱出来。

随后，2024年初，Jia Tan植入了payload。第一个恶意代码于一月入库，而5.6.0版本则于2月24日发布。

这个后门（CVE-2024–3094）潜伏在5.6.0 和 5.6.1版本深处。它的攻击目标并非源代码本身，而是构建过程。恶意代码伪装成压缩二进制数据，藏身于看似无害的测试文件中。只有在特定的Linux发行版上进行编译时，它才会被激活，进而篡改liblzma通过systemd与sshd交互的方式。

就像在包装厂投毒而不是在农场一样，原料检测合格，但密封包装却有问题。

结果：任何受影响的SSH服务器均可执行远程代码。SSH是管理员远程登录Linux机器的方式，是每台服务器的入口。CVSS 评分为10.0分（满分10.0），这是最高级别的严重性评分。

如果这次攻击成功进入主流发行版的稳定版本，那么攻击者就相当于拿到了通往全球数百万台Linux服务器前门的万能钥匙：政府系统、银行基础设施、云平台，无一幸免。

这就好比供应链领域的一场投毒：通过接近水处理厂里那位孤独的工人，从而给整座城市的供水系统下毒。

2024年3月29日，微软工程师Andres Freund在PostgreSQL项目组工作时，注意到了一些奇怪的事情。在他的Debian sid（不稳定版）机器上，SSH登录所需时间比预期长了大约500毫秒。

2024年3月29日，微软工程师、从事PostgreSQL开发的Andres Freund注意到一件怪事：他在Debian sid（不稳定版）机器上的SSH登录耗时比预期多了大约500毫秒。

500毫秒，比一次眨眼的时间（300-400毫秒）稍长一些。

大多数人或许会忽略这一细节，但Freund没有。

他将延迟问题溯源至最新的xz-utils更新，在测试夹具中发现了混淆的代码，并意识到自己面对的是一枚被蓄意植入的后门。Freund随即在oss-security邮件列表中发布了如下消息：

这语气，就像是一个刚在灭火器里发现炸弹的人：冷静、精准，并且明白恐慌于事无补。

几个小时之内，各大发行版撤下了受影响的版本，整个互联网险些酿成大祸。

有人在全世界每栋办公楼的墙壁内都安装了窃听器，而它被发现的唯一原因是，一位电工注意到他的灯开关反应慢了半秒钟。

一位工程师，500毫秒。如果他没有注意到，这个后门程序就会被发布到Debian和Fedora的稳定版中，以及所有基于它们构建的发行版中。

XZ Utils检测和响应流程

你或许会认为，在经历了Linux历史上最引人注目的供应链攻击之后，清理工作会迅速而彻底。但事实并非如此。

截至2025年8月，Binarly发现Docker Hub上的Debian Docker镜像仍然潜伏着带有后门的xz-utils版本。Debian官方却轻描淡写地称之为“历史遗留物”，并拒绝移除。此后未有后续研究发表，因此这些镜像如今是否仍然存在，不得而知。这些历史遗留物，如今就静静地躺在Docker Hub上。而自动化CI/CD流水线往往会直接拉取基础镜像，并不会校验版本锁定。

这就像在厨房里发现了老鼠药，把它从台面上拿走，却因为“有历史意义”就把受污染的罐子继续留在食品储藏室里一样。

与此同时，Lasse Collin仍独自一人审核xz.git代码库。那个曾因心理健康问题被人利用的受害者，如今却要负责收拾残局。

如果你的公司运行的是Linux系统（而它确实如此），那么你的安全防线有多牢固，完全取决于维护这些项目的人员的心理健康状况。想到这一点，你还能安心吗？

xz项目的情况并非个例。哈佛大学和Linux基金会在2024年联合开展的Census III研究显示，在调研的前50个非npm项目中，有40%的项目仅依靠一到两名开发者完成超过80%的代码提交。数百个库与xz同样至关重要，却也同样脆弱不堪。

开源安全基金会 (OpenSSF)警告称，xz攻击“可能并非孤立事件”。研究已发现针对JavaScript生态项目的同类社会工程攻击模式，其套路清晰明了：找到一位心力交瘁的关键基础设施维护者，创建虚假身份，施加压力，安插卧底，潜伏数年，待完全获取信任之后发动攻击。

首先，使用xz-utils的公司（也就是所有运行Linux的公司）必须直接为项目维护提供资金支持。不是通过基金会，而是通过薪水和福利，就像为编写闭源代码的员工支付报酬一样。为关键库的独立维护者提供资金，并非慈善行为，而是国家安全层面的必要举措。xz后门事件证明：一情绪低落丧、超负荷工作的志愿者，就是那些国家级黑客愿意花数年时间，去精心培养的猎物。

其次，关键库的每次提交都需要实行强制多人审查机制。Collin库就是一个单点故障，攻击者正是看准了这一点。任何运行在数十亿台设备上的库都不应该仅一个拥有唯一的提交权限。Linux基金会在内核方面的模式表明这种做法是行之有效的，xz库也应该如此。

第三，对拥有维护者权限的贡献者进行身份核验。Jia Tan使用化名运作了两年多，其真实身份从未得到验证。对于一个嵌入在SSH中的库来说，这本应从一开始就被视为严重风险信号。

此次xz后门攻击的执行成本几乎为零。攻击者耗时两年多，耐心提交伪装代码，在邮件列表中操控傀儡账号发声，而利用的，仅仅是一位身心俱疲、只求有人搭把手的维护者。

我们早就收到过警告，Collin在2022年6月就提醒过，但我们没有听进去。

你们的团队是否核查过：究竟是谁在维护你所依赖的核心基础组件，以及这些人是否真的合格？