这轮下毒，盯上了写代码的人

2026年7月，有攻击者把一个 Terraform 插件改成了特洛伊木马，往开发者环境里塞进两段恶意载荷；几乎同一时间，Cursor 平台上的 Claude Code 扩展也出了安全问题，而且是同一天爆出两件。这不是巧合。当应用层防御越修越厚，攻击者把枪口转向了最上游——写代码的人。开发者的工作台，正在从生产力的起点，变成整个企业安全的破口。

🎣 一次 terraform init，怎么变成开门揖盗

先还原一个典型场景。

一位 DevOps 工程师早上到工位，拉取团队仓库，照常执行 terraform init。一切正常，资源照常下发。他不知道的是，这个项目引用的 Terraform provider 已经被植入恶意代码——就在这条命令执行的同时，木马落地了。

据 Zscaler ThreatLabz 的分析，这起针对开发者环境的攻击采用双载荷接力：先投放 FLATROOF，负责窃取凭据、建立初始访问；随后部署 ROOFDECK，实现对受害主机的更广泛远程控制。载荷是跨平台的，macOS 和其他主流开发环境都在射程之内。

归属上，报告用了「疑似 TraderTraitor」这个措辞，而且说得很克制：ThreatLabz 在目标选择、工具特征和战术手法上发现了相似性，但缺少唯一的代码匹配、共享基础设施或密码学层面的强证据。换句话说，像，但钉不死。

产业逻辑其实藏在这条攻击链里。Terraform 的 provider 在 terraform init 时会被自动下载执行，而执行环境里往往躺着一整套云厂商的 API 凭据——AWS 密钥、K8s 配置、数据库连接串。对一个攻击者来说，攻陷一个开发者，约等于拿到一份企业的钥匙串。这就是为什么 IaC 插件成了新的下毒载体：它不是浏览器里的可疑链接，它是你每天必须信任的官方工具链。

🤖 Cursor 一天出两事：AI IDE 成了新战场

如果说 Terraform 被投毒是「老工具新麻烦」，那 Cursor 的麻烦则更像「新赛道的胎里病」。

同一天，两起严重的安全问题砸在 Cursor 头上，其中一起直指为 Cursor 定制的 Claude Code 扩展被木马化，开发者直接中招。这在 AI IDE 的原生开发者群体里激起了不小的水花——毕竟 Cursor 的核心卖点就是让开发者把整个工作流（代码、终端、仓库凭据、甚至云密钥）都交到编辑器手里。

把两起事件放在一起看，结构惊人地一致：

这不是孤立的两次「翻车」，而是同一类问题在两个不同生态里的重复发作：分发渠道的信任模型，跟不上代码自动执行的速度。

据多位接近情报团队的研究者私下交流，大家真正担心的不是某一次具体攻击，而是一个结构性事实——AI IDE 的插件和 MCP 扩展生态正在以极快的速度扩张，上架审核的松紧程度远低于传统应用商店。生态越繁荣，伪装成「效率神器」的恶意扩展就越有流量红利。

一句话：AI 编程工具把开发效率抬高了，也把攻击的效率抬高了。

🗺️ 四象限看攻击面：哪里最肥，哪里最难守

攻击者不是无差别撒网，他们也在算 ROI。把主流供应链攻击面放到「技术门槛 × 攻击收益」两个维度上，格局一目了然：

右上象限（重点威胁）是最该盯住的区域：IaC 插件和 CI/CD 插件技术门槛偏高，但一旦得手，收益是整条云管线的凭据。左上象限（高发温床）则是量大管饱的「散户市场」——恶意 npm 包、编辑器扩展，技术含量不高，但量大面广，捡漏就够养活一个团伙。

值得注意的是 AI 插件生态的位置：它正从左上向右上快速漂移。今天它像一个高发的温床，但因为它天然绑定模型 API 密钥、仓库令牌和整套工作流权限，它的「收益天花板」比传统插件高得多。Terraform 这次的案例证明，右上象限的剧本是可复制的——AI 插件只是缺一个成功的样板间。

对防守方来说，这张图的含义很直白：安全预算别只压在边界和终端上，开发者工具链这个曾经被当成「可信区」的地带，需要重新划入威胁模型。

💰 归属存疑没关系：钱在哪，枪口就在哪

回到归属问题。「疑似 TraderTraitor」这个判断，值得多说两句。

ThreatLabz 的方法论很规范：目标选择相似、工具相似、战术相似——三票；但代码唯一匹配、共享基础设施、密码学证据——零票。这种情况下给一个「疑似」，是情报行业该有的克制。历史上太多把「手法像」硬说成「就是他」的案例，最后误导了整个防御方向。

但把归属悬置起来，不等于无所作为。归属的价值在于预测，而预测的第一性原理是利益。 据圈内流传的一种判断：TraderTraitor 一脉的活动长期围绕加密资产行业展开——开发者机器上既有钱包、又有云凭据、还有 npm 发布令牌，是那种「打一个顶三个」的目标。开发者环境，恰好同时踩中了「有钱」和「有权限」两条线。

所以哪怕最终证明这次不是 TraderTraitor，而是另一个团伙「抄作业」，结论也不变：

1. 开发者终端上的凭据密度，是全企业最高的；

2. 工具链自动执行的信任模型，是全企业最脆的；

3. 两者的组合，决定了这类投毒还会继续发生。

多位一线应急响应的工程师也持类似看法：真正的问题从来不是「是谁」，而是「下一个载体是什么」。上次是 npm，这次是 Terraform 和 AI 扩展，下次可能是任何自动执行的插件市场。

🛡️ 防御不是买 EDR 就完了

聊完威胁，说点周一早上就能干的事。

供应链攻击的防守难点在于：恶意代码不是从外网打进来的，它是你「主动请进来」的。传统防火墙和杀软在这个场景里几乎瞎的。据多位在企业侧做安全建设的从业者反馈，能真正压住风险的，是一套组合动作：

四条里最有争议的是最后一条。不少团队觉得给 AI 扩展做安全评审太重，影响开发效率。但看看这次的两个案例就应该明白：你交给 AI IDE 的每一分权限，都会在它被投毒的那一天，原封不动地交给攻击者。

还有一个更根本的视角：供应链安全本质上是采购问题，不是杀毒问题。你引入每一个 provider、每一个扩展，都应该像引入一家供应商那样去问——它从哪来？谁维护的？它要什么权限？坏了怎么回收？这三问回答不了，就别让它在开发者的机器上自动执行。

🧭 小结

Terraform 插件投毒与 Cursor 扩展事件，隔着一个生态，讲的是同一个故事：开发者的信任链，正在被系统性开采。FLATROOF 加 ROOFDECK 的双载荷接力证明攻击工程化已经成熟，而归属证据链的空白则提醒我们，这只是开始。下一个被下毒的，很可能是你今天刚装的那个「AI 效率插件」。防守的起点，从把工具链从「可信区」名单上划掉开始。