两起事件，同一工具链
10 月 19 日，围绕 AI 编程智能体工具 OpenCode 的两起安全事件被集中披露，共同指向一个被长期低估的攻击面：开发者每天都在用的智能体编码工具，本身就握着通往多家模型提供方的密钥，又会在本地运行来自第三方的插件与协议。一旦这条工具链出现缺口，受害者不只是单个应用，而是一整支研发团队的工作环境。
两起事件性质不同，却暴露同一类症结——开发工具既承载高敏感凭据，又默认信任外部扩展，于是成为比模型本身更肥、也更易被忽视的入口。这与近期智能体工具链的其他安全失败（如某协调平台被用于批量入侵上百站点）属于同一脉络。
RCE：恶意 MCP 服务器借 OAuth 静默执行代码
Pillar Security 披露，OpenCode 在 1.0.137 至 1.18.32 版本存在一个 CVSS 9.8 的关键远程代码执行漏洞：攻击者控制的恶意 MCP 服务器，可利用 OpenCode 的 OAuth 认证流程，在开发者的 Windows 或 WSL 机器上未经同意执行任意代码。漏洞由研究员 Eilon Cohen 于 8 月私下报告，维护者 Anomaly 在 9 月 28 日的 1.18.33 版本中修复。
危险之处不在修复动作，而在修复方式：维护者没有发布 CVE，也没有安全公告。这意味着在此后约三周里，依赖漏洞扫描器的团队完全无法得知自己处于风险中，直到本周公开披露，扫描器才识别受影响安装。
无声修复的隐患：没发 CVE，扫描器认不出
「悄悄修掉但不发公告」在工程界并不罕见，但当漏洞评分高达 9.8、且影响开发者的本地执行环境时，沉默会带来真实的暴露窗口。受影响的开发者可能长期运行未升级版本，而他们的 CI、密钥与代码全在同一台机器上。
对使用 OpenCode 的团队，当务之急是把版本升到 1.18.33 及以上，并审计本地是否曾接入不可信的 MCP 服务器。更长期的动作是：把开发工具对外部插件的信任降到最低，对 OAuth 授权范围做最小化，并在隔离环境里运行不可信协议。
Console 密钥泄露：1.4% 用户被用于蒸馏攻击
第二起事件来自 Rescana 的报告：OpenCode Console 平台的一个旧系统在退役中途发生泄露，约 1.4% 用户的提供方 API 密钥（覆盖 OpenAI、Anthropic 与 Google）被窃取。攻击者用这些密钥对底层模型发起大规模自动化查询——一种旨在训练更便宜仿制模型的「蒸馏攻击」。
直到提供方吊销密钥前，个别用户被追缴了从数百美元到 1700 美元以上的未授权费用。这类泄露的隐蔽性在于：密钥仍「有效」，异常流量混在正常的开发者调用里，受害者往往从账单而非告警中发现问题。
为什么 AI 编程工具成了高价值目标
AI 编程工具处在研发链路的「前方」：它们集中持有各家模型的密钥、代码与运行环境，是比单个应用更肥的攻击面。拿下开发工具，攻击者拿到的不是某一个密钥，而是一整支团队的密钥全景，以及可直接用于蒸馏、仿制模型的能力。
过去围绕 AI 工具链的供应链攻击明显增多，从包管理器的依赖投毒到各类 SDK 被污染，逻辑一致：攻击者不再硬碰模型，而是去污染模型被集成进生产的方式。开发工具正是这条集成链上最薄弱、也最值得加固的一环。
冷静看：开发工具链的供应风险
把两起事件并排看，结论很清楚：智能体开发工具的安全水位，不能只靠厂商自觉。对使用这类工具的团队，几条可落地的动作包括——把工具与插件版本纳入资产与漏洞台账、对提供方密钥做隔离与短时效轮换、在隔离环境运行不可信 MCP 服务器、并为 API 账单设置异常阈值告警。
更宏观的启示是：当「模型之下的工具层」成为攻击焦点，安全投入应当从模型本身前移到整个开发链路。否则，即便模型再强，承载它的工具链一旦失守，护城河也会从内部被掏空。