OpenCode 被黑之后：coding agent 为什么成了凭据聚集点

10 月 18 日凌晨，开源 coding agent OpenCode 的官方账号发了一条说明：前一晚出了一起安全事件，和一场「大规模蒸馏攻击」有关，影响了 1.4% 的 OpenCode Console 用户，受影响的人已经收到邮件，团队正在和 Anthropic、OpenAI、Google 一起处理。^[1] 在那之前几个小时，已经有用户发现自己的 OpenAI 和 Anthropic key 半夜被人刷了几百美元。^[3] Hacker News 上那条「OpenCode Hacked: User credentials leaked」到当天下午拿了 854 分、159 条评论。^[6]

先把范围说清楚。出事的是 OpenCode Console，一个托管服务，而不是大多数人装在终端里的 OpenCode 本体。OpenCode 的开发者 dax 在回复 Anthropic 的 Lydia Hallie 时专门强调过，本地 OpenCode 用的 key 从来不经过他们的服务器。^[5] 所以这不是一起「装了 OpenCode 就得换 key」的事件。

可是读到这里就放下，会错过更要紧的东西。这次被偷的是一种很特别的凭据：拿到就能直接花钱的模型 API key，而且一个托管网关里存着很多客户、好几家厂商的 key。把视线从 Console 挪回本地，coding agent 自己也在做同一件事，它把模型 key、MCP 令牌、项目 .env、git 和云 CLI 的凭据，全都摆在一个以你的身份运行、能执行 shell、还会自动加载外部代码的进程旁边。过去一年里的 npm 投毒、扩展被植入提示词、幻觉包名抢注，打的都是这个位置。下面先把事件里能确认的部分理一遍，再讲这些凭据是怎么聚到一起的，最后给一个可以照着查的框架。

先说结论

• 这次外泄风险落在 Console workspace 里保存的第三方 provider key 上。只在本机用自己 key 的 OpenCode 用户，目前没有证据显示受影响。入口在哪、key 怎么存、和「蒸馏攻击」到底什么关系，官方都还没说。
• 被盗的模型 key 极容易变现。实验室对新注册账号和假身份账号越管越严，一把挂在真实老客户名下的 key 反而更值钱。这是我对「蒸馏」和这次被盗之间关系的推测，官方没有证实。
• coding agent 天然是凭据聚集点：它要同时接好几家模型，要调你的工具链，要启动 MCP 子进程，还要加载会自动更新的 skill 和插件。文件权限挡得住同机的其他用户，挡不住以你身份运行的代码。
• 能做的事大多很朴素：按工具和项目分 key，在 provider 侧设消费上限，出事时去 provider 后台吊销而不是只在网关里换掉，让 agent 从干净的环境启动，跑不受信的代码时进容器、只给一把作用域受限的小额度 key。

时间线：能确认的部分

以下时间均为北京时间。

10 月 17 日 21:36，开发者 Colin Parsons 在 X 上问 OpenCode 团队是不是被黑了。他说自己的 OpenAI key 从美东凌晨 2 点（北京时间 14:00）开始被刷了 281 美元，Anthropic key 同一时段被刷了 168 美元，而这两把 key 只在 OpenCode 里用过。^[3]

截图：官方说明发出前约 4 个半小时，Colin Parsons 公开询问是否被黑（X 公开嵌入页，2026-10-18 截取）^[3]

23:18，安全作者 Matt Johansen 说有 OpenCode 用户私信他，称收到了泄露通知，自己的 API key 正在产生费用。12 分钟后他贴出一封通知邮件的截图，图源是 r/opencode 上的一个帖子，邮件标题是「Action Required: Potential provider key breach」。^[2] 邮件说他们发现有人未经授权访问了一个正在下线的遗留系统，保存在 workspace 里的第三方 provider key（例如 OpenAI、Anthropic）可能已经暴露，请用户到各家 provider 的后台吊销并替换这些 key，更新用到它们的应用，并检查近期有没有异常用量。

截图：Matt Johansen 转贴的通知邮件，提到遗留系统和 workspace 里保存的 provider key（X 公开嵌入页，2026-10-18 截取）^[2]

10 月 18 日 01:56，@opencode 发出正式说明，12 分钟后编辑了一次，补上一句「没收到邮件就没受影响，受影响的是连接了外部 provider 的一部分用户」。^[1] 帖子用的词是「security breach」和「large scale distillation attack」，影响比例是 1.4% 的 Console 用户，没有给绝对人数。

截图：OpenCode 官方说明的编辑后版本，显示「Last edited 2:08 AM · Oct 18, 2026」（X 公开嵌入页，2026-10-18 截取）^[1]

02:01，这条说明被转到 Hacker News。^[6] 讨论里很快出现两种声音，一种翻出 OpenCode 过去在隐私和遥测上的争议，另一种反复要求把标题改成「OpenCode Console」，理由是 Console 和终端里的 coding agent 根本是两个东西。排在最前面的一条评论直说 OpenCode 团队没把这个区别讲清楚，官方说明里也没有点明。

截图：HN 讨论帖，排在最前的评论在解释 Console 和 coding agent 的区别（Hacker News 原帖，2026-10-18 截取）^[6]

02:41，dax 发帖说他的个人账号也正在被攻击。^[5] 05:04，Anthropic 的 Lydia Hallie 说他们一直在和 OpenCode 一起处理，已经吊销了认为受影响的 Claude API key，在 OpenCode 里存过 key 的人想更稳妥的话，可以新建一把。^[4] 34 分钟后 dax 回复她：这是 OpenCode Console，不是 OpenCode 本身，那些 key 从来不会到我们手里。^[5] 当天早上他在另一条回复里说，受影响的人都已经联系过，退款已经在办。^[5]

截图：Lydia Hallie 的说明和 dax 的回复（X 公开嵌入页，2026-10-18 截取）^[4][5]

同一天，The Latent 汇总了更多用户自报的损失：有人说损失 1,700 美元，有人说拔掉 key 之前 OpenAI 用量已经超过 700，还有人说除了额度被盗，OpenAI 账号也被暂停了，这些数字 The Latent 说它没能独立核实。^[7]

还不知道的事比知道的多。ThreatWire 和 TSN 都列过一张清单：受影响的绝对人数，攻击者怎么进来的，key 是怎么存的，这次入侵和「蒸馏攻击」到底是什么关系，会不会全额赔付，除了 provider key 还有没有别的数据被碰过。^[8][10] 到我写这篇时，这些都还没有答案。

Console 和本地 CLI 是两条路

要理解为什么只有一部分人中招，得先看 Console 是干什么的。OpenCode 的文档写得很直白：团队可以把已经在付费的 provider 账户（Anthropic、OpenAI、AWS Bedrock 等）连到 Console，在 Providers 页面填入那家的 API key；Console 保存这把凭据，通过自己的网关转发请求，成员用模型时看不到 key；同一个网关还开放给你自己的工具调用。^[11] 计费上，token 费由 provider 直接向你收，Console 只记账。

换句话说，Console 同时做了两件事：替你保管一把长期有效的 key，以及替你把请求发出去。管理员图的是省事，一把公司 key 给全组用，不必每人申请一把。代价是这把 key 的全部消费权限交给了第三方，而 provider 那边只认 key，不认是谁在用。

本地 CLI 是另一条路。用 /connect 或 opencode auth login 添加的 key，文档说存在 ~/.local/share/opencode/auth.json，OpenCode 启动时还会读取环境变量和项目里 .env 文件中的 key。^[12] 开发分支的代码已经改成把这个文件导入本地数据库，数据库文件权限收紧为 0600，只有属主能读写。^[14] 这些 key 留在你自己的机器上，dax 说的「从来不会到我们手里」就是这个意思。

麻烦在于两条路会交叉。Noma Security 提醒，CLI 也可以在 /connect 里选一个 Console workspace，直接用 workspace 托管的 provider。^[9] 所以「我只用终端」回答不了你有没有暴露，要看的是这把 provider key 当初是填在本机，还是填进了 Console。

被偷的 key 为什么这么好卖

模型 API key 是 bearer 凭据，谁拿着谁就能用，费用记在主人头上。它和数据库密码不一样：拿到以后既不用横向移动，也不用费心找数据外传的出口，发 HTTPS 请求就能直接换成算力。一个托管网关里存着几家厂商、很多客户的 key，攻破一次的产出就是这几项相乘。

OpenCode 把事件和「大规模蒸馏攻击」联系在一起，却没解释怎么联系。HN 上也有人猜，这些 key 更可能是被拿去黑市转卖算力。^[6] 我倾向于认为两种说法并不冲突，而且指向同一个经济逻辑。Anthropic 10 月 12 日的文章写到，蒸馏攻击通常靠大批欺诈账号进行，他们见过控制数十万个欺诈账号的代理网络，这些网络还用假身份和盗来的支付方式开户；新的防御包括 preserved thinking，即不允许 2026 年 8 月 31 日及以后新建的 API 账号编辑 Claude 先前的上下文，用两级分类器拦截套取推理过程的请求，并且常常在一个账号开始蒸馏后不到两小时就把它封掉，累计封了数万个。^[17] 文章还说，蒸馏者会把流量分散到 Anthropic 自己的 API、第三方云平台和其他推理服务商上。

新账号和假身份越来越难用，一把挂在真实老客户名下、有付费历史、不受新账号限制的 key，对蒸馏者和转卖者就都更值钱。这只是我的推测，OpenCode 和三家实验室都没这么说过。但如果它成立，Console、OpenRouter 式的 BYOK（自带 key）网关、公司内部的模型代理，以后都会更常被盯上。

coding agent 身上的凭据是怎么聚起来的

Console 是把别人的 key 聚到一台服务器上。本地的 coding agent 则是把你自己的各种凭据聚到一个进程周围。这不是哪个厂商偷懒，而是 coding agent 的工作方式决定的。

图：coding agent 进程周围的凭据（左）和会自动进入同一进程或子进程的外部代码（右），以及托管网关这条旁路。依据^[11]–^[16]。

第一，它要接很多家模型。OpenCode 支持 75 家以上的 provider，^[7] 一个凭据文件里常常同时躺着好几家的 key 和 OAuth 令牌。远程 MCP 服务器的 OAuth 令牌另存一份，在 ~/.local/share/opencode/mcp-auth.json；配置文件可以用 {env:MY_MCP_CLIENT_SECRET} 这种写法从环境变量取值，文档示例里也有直接把 Bearer 加 key 写进请求头的配置。^[13]

第二，它以你的身份跑 shell。OpenCode 的 SECURITY.md 写得很坦白：OpenCode 不给 agent 做沙箱，权限确认只是让你知道 agent 在干什么的交互功能，不是安全隔离，需要真正隔离就自己放进 Docker 或虚拟机。^[15] 同一份文件把「你配置的外部 MCP 服务器的行为」划在信任边界之外。也就是说，你的用户账号能读到什么，agent 就能读到什么：gh auth token 打印出来的 GitHub 令牌，~/.aws 里的云凭据，~/.ssh 下的私钥。0600 这种文件权限挡住的是同一台机器上的其他用户，对以你身份运行的代码没有任何作用。

截图：OpenCode 的威胁模型，「No Sandbox」和「Out of Scope」两节（GitHub 原页面，2026-10-18 截取）^[15]

第三，它把环境变量交给子进程。OpenCode 启动本地 MCP 服务器时，配置里写的 environment 只是追加项，代码会把宿主进程的整个 process.env 合并进去，源码注释说这和 MCP SDK 原本的 stdio 传输行为一致。^[14] 你在 shell 里 export 过的每一个 key，每个本地 MCP 服务器都拿得到，而这些服务器很多是 npx -y some-package 这样现装现跑的。^[13]

第四，它会自动加载来自云端的代码。Claude Code 是这里最清楚的例子。从 v2.1.273 起，在用 claude.ai 账号登录的终端会话里，账号上启用的 skills 会下载到 ~/.claude/skills/synced/，会话进行中大约每 10 分钟检查一次更新，增删改不用重启；账号上启用的插件在每次启动时同步到 ~/.claude/plugins/synced/，插件里的 skills、agents、hooks、MCP 服务器全部加载，信任级别和你从插件市场装的一样。^[16] 组织标为必装的插件，用户自己关不掉。这是有文档、能关掉的功能（把 syncClaudeAiSkills、syncClaudeAiPlugins 设为 false），目前也没有公开的滥用案例。我提它，是因为它把「谁能往你的 agent 旁边放代码」从你自己扩大到了你的 claude.ai 账号和组织后台。站内写过的 SkillSpector 安装前扫描 和 同类 skill 互相顶替 讲的是 skill 内容本身的风险，这里多出来的是分发渠道。

四点放在一起看：凭据多，权限大，子进程继承环境，外部代码自动进来。攻击者只要让任意一段代码在这个进程旁边以你的身份跑起来，上面这些东西就都能看见。

对照：过去一年打的都是这个位置

图：五起事件的入口、落点和用户最先看到的信号。依据^[2][18]–^[24]。

Nx「s1ngularity」（2025 年 8 月）。 攻击者利用 Nx 的一个 GitHub Actions 注入漏洞偷到 npm 发布令牌，往 npm 发了大约 4 小时的恶意版本。^[18] 恶意的 postinstall 脚本扫描开发机上的敏感数据，还尝试调用本机装着的 Claude Code、Gemini CLI 和 Amazon Q，分别带上 --dangerously-skip-permissions、--yolo、--trust-all-tools，让它们递归搜索钱包文件、.env、SSH key 之类的路径，写进 /tmp/inventory.txt。^[19] 结果通过受害者自己的 GitHub CLI，上传到受害者账号下名为 s1ngularity-repository 的公开仓库。Wiz 统计，第二阶段攻击者用泄露的 GitHub 令牌把 400 多个用户和组织的 5,500 多个私有仓库改成了公开。^[20] StepSecurity 说这是最早有记录的、恶意代码驱使 AI CLI 帮忙侦察的案例之一。它用的正是上一节的第二点：agent 以你的身份运行，一旦关掉确认，它就替攻击者干活。

Amazon Q Developer 扩展 1.84.0（2025 年 7 月）。 AWS 的公告说，这个扩展的 CodeBuild 配置里有一个权限过宽的 GitHub 令牌，攻击者用它往开源仓库提交了恶意代码，代码被自动打进了正式发布版。^[21] 植入的是一段提示词，要 agent 把系统清理到「接近出厂状态」并删除文件系统和云资源，AWS 说因为语法错误没有执行成功。这一次没有偷凭据，但入口同样是一把放错地方的长期令牌，落点同样是开发者信任、会自动更新的 agent 组件。

Shai-Hulud（2025 年 9 月）。 CISA 的告警说，这条会自我复制的 npm 蠕虫感染了 500 多个包。恶意代码扫描环境里的凭据，专找 GitHub 个人访问令牌和 AWS、GCP、Azure 的 API key，外传之后再上传到名为 Shai-Hulud 的公开仓库，然后用偷来的 npm 令牌以受害开发者的身份发布被感染的新版本。^[23] 它说明开发机上的一把发布令牌，本身就是下一轮传播的燃料。

Slopsquatting（幻觉包名抢注）。 Spracklen 等人用 16 个模型生成了 576,000 段代码，模型推荐的 223 万个包里有 19.7% 根本不存在，去重后是 205,474 个不同的假包名；商业模型平均 5.2%，开源模型 21.7%。^[24] 更要命的是可预测：同一个提示重复问 10 次，43% 的幻觉包名每次都会出现。攻击者可以先把这些名字注册下来，等 agent 自己去 pip install 或 npm install。和前三起不同，这里连偷来的令牌都用不着，入口是模型自己写出来的依赖。

OpenCode Console（2026 年 10 月）。 你的机器上没有任何恶意代码在跑，出事的是替你保管 key 的那一方，你最先看到的信号是 provider 账单。

五件事的共同点在于，攻击者找的都是凭据旁边审查最少的那个环节，可能是一把发布令牌、一份 CI 配置、一次依赖安装，也可能是一个替你保管 key 的托管服务。coding agent 让这样的环节变多了，也让它们离凭据更近了。

决策框架：先问四个问题

图：给 coding agent 配凭据前的四个问题，以及第四个问题两种答案对应的做法。

我的建议是按下面四个问题排查，每个问题对应一组动作。

这把 key 现在放在几处？ 本机凭据文件、shell 配置里的 export、项目 .env、CI secret、托管网关，每多一处就多一个泄露点，出事时也多一处要吊销。理想情况是一把 key 只有一个用途、一个存放位置。

它泄露以后最多能花掉多少？ 去 provider 那边设消费上限和用量告警。Noma 提醒上限可能有执行延迟，告警只负责通知，既不会吊销 key，也不保证消费会停。^[9] 所以上限要按「最坏情况你愿意付多少」来定，而不是平时用量乘个系数。

agent 运行时能看到哪些凭据？ 看三样东西：凭据文件里有几家的 key；启动 agent 的那个 shell 里 export 了哪些变量，它们会原样传给本地 MCP 服务器；agent 的 shell 工具能不能读到 ~/.aws、~/.ssh 和 gh 的令牌。

这次任务要不要跑不受信的代码？ 克隆陌生仓库、让 agent 自己装依赖、开着跳过确认的模式长时间无人值守，这三种都算。答案是「要」，就进容器或虚拟机，只挂这个项目需要的目录，只给一把作用域受限、额度很小的 key，再配上出口白名单。答案是「不要」，至少也从一个干净的 shell 启动 agent。

落到具体动作上：

1. 用过 OpenCode Console 并连过外部 provider 的，不管收没收到邮件，都去 OpenAI、Anthropic、Google 等各家后台吊销原 key 再新建，检查最近几天的用量和账单，异常消费找 provider 客服并保留记录。只在 Console 里换 key 或删掉连接，旧 key 在 provider 那边仍然有效。^[9][10]
2. 按工具和环境分 key。给 coding agent 单独建 provider 项目和 key，不复用生产应用的 key，不同项目、不同机器各用各的。出事时你能精确吊销一把，而不是全部推倒重来。
3. 能用短期令牌就别用长期 key。dax 在另一条回复里提到，通过 OpenCode 登录 provider 时默认拿的是 OAuth 令牌，而不是长期有效的 API key。^[5] Claude Code 也支持用 apiKeyHelper 脚本按需取凭据。^[16] Amazon Q 事件之后，Chainguard 的 Matt Moore 说得很直接：长期有效的静态令牌，就是等着被发现、泄露和滥用的负债。^[22]
4. key 放进密钥管理器，用的时候注入给单个进程，别在 .bashrc 或 .zshrc 里全局 export。OpenCode 配置支持 {env:VAR} 引用，^[13] 配合按命令注入，key 就不会常驻在每个子进程的环境里。
5. 给本地 MCP 服务器最小的环境。既然它继承宿主的全部环境变量，就从只含必要变量的 shell 启动 agent，在 environment 里只给它真正需要的那一个令牌；npx -y 现装现跑的服务器，先把版本钉死。
6. 关掉用不上的自动同步。Claude Code 用户如果不需要 claude.ai 上的 skills 和插件，在用户设置里把 syncClaudeAiSkills 和 syncClaudeAiPlugins 设为 false。^[16]
7. 装依赖前核对包名：包是不是真的存在，发布了多久，下载量多少，锁文件有没有提交进仓库。光查「它在不在注册表上」挡不住幻觉包名，因为攻击者可能已经把它注册了。^[24]
8. 做出口控制。CISA 对 Shai-Hulud 的建议之一，就是封掉恶意代码外传用的域名并监控异常出站。^[23] 对 coding agent 更实际的做法是在沙箱里配出口白名单，只放行模型 API、包仓库和代码托管。站内 Claude Code 的四条出站通道 那篇有一份可以照抄的开关清单。
9. 往托管网关里存 key 之前，先问清楚 key 怎么存、谁能读、有没有子 key 或额度隔离、出事后怎么通知和吊销。HN 上有人说 Console 填 key 的页面看不到任何关于存储方式的说明，^[6] 这本身就是一个该停下来想想的信号。

沙箱值得多说一句。它解决的是「不受信的代码在我机器上能碰到什么」，对 Console 这种托管方被攻破的情况毫无帮助；你亲手交给沙箱里 agent 的那把 key，沙箱同样保护不了。沙箱不够 那篇讲过，真正决定损失上限的是 agent 手里握着的权限。所以顺序应该是先把 key 的权限和额度缩小，再谈隔离。

结论

OpenCode 这次的事故本身边界是清楚的：一个托管服务的遗留系统被入侵，一部分用户存进去的 provider key 外泄，被拿去刷了钱。它值得认真看，是因为它暴露了一个比 OpenCode 大得多的问题。模型 API key 正在成为开发者手里最容易变现的凭据，而 coding agent 以及围绕它的网关、插件、MCP 服务器，恰好把这些凭据和大量自动运行的外部代码放在了一起。

我不认为解法是换一个「更安全」的 agent。Claude Code、Codex、OpenCode 都要读你的文件、跑你的 shell、拿你的 key，这正是它们有用的原因。更现实的做法是承认 agent 就是凭据聚集点，然后像对待一张没有额度上限的信用卡那样对待每一把模型 key：分开放，设上限，尽量短期，出事能马上吊销。厂商那边，我希望看到更多 OAuth 和短期令牌、按项目划分的子 key 和硬上限，让 key 被偷的那天，损失是一个确定的数字，而不是一张空白支票。

参考来源

1. OpenCode（@opencode），事件说明（编辑后版本，北京时间 2026-10-18 02:08）：https://x.com/opencode/status/2111519637049319818 ；初版（01:56）：https://x.com/opencode/status/2111516673953935833 ↩
2. Matt Johansen（@mattjay），用户收到泄露通知与通知邮件截图：https://x.com/mattjay/status/2111476982580211851 ；https://x.com/mattjay/status/2111480005435719885 ↩
3. Colin Parsons（@colinparsonscom），OpenAI 与 Anthropic key 异常消费：https://x.com/colinparsonscom/status/2111451256426250580 ↩
4. Lydia Hallie（@lydiahallie），Anthropic 吊销受影响的 Claude API key：https://x.com/lydiahallie/status/2111563956666110287 ↩
5. dax（@thdxr），Console 与 OpenCode 本体的区别：https://x.com/thdxr/status/2111572618340188393 ；个人账号被攻击：https://x.com/thdxr/status/2111528031072461114 ；退款进行中：https://x.com/thdxr/status/2111608620441817449 ；登录默认使用 OAuth 令牌：https://x.com/thdxr/status/2111633979074031801 ↩
6. Hacker News，《OpenCode Hacked: User credentials leaked》讨论帖：https://news.ycombinator.com/item?id=50133401 ↩
7. The Latent，Zack Abrams，《OpenCode says breach tied to distillation attack exposed users’ AI provider keys》：https://thelatent.co/models/opencode-says-breach-tied-to-distillation-attack-exposed-users-ai-provider-keys ↩
8. TSN，《OpenCode Says Breach Tied to “Distillation Attack” Hit 1.4% of Console Users》：https://tsnmedia.org/opencode-console-breach-distillation/ ↩
9. Noma Security，Ron Harnik，《OpenCode Console breach: what security teams need to know》：https://noma.security/blog/opencode-console-breach-what-security-teams-need-to-know ↩
10. ThreatWire，《OpenCode Console breach, revoke saved AI provider keys》：https://www.threatwire.tech/threats/opencode-console-breach-exposes-saved-ai-provider-keys ↩
11. OpenCode 文档，Console · Providers：https://opencode.ai/v2/docs/console/providers/ ↩
12. OpenCode 文档，Providers（Credentials）与 CLI（auth）：https://opencode.ai/docs/providers/ ；https://opencode.ai/docs/cli/ ↩
13. OpenCode 文档，MCP servers：https://opencode.ai/docs/mcp-servers/ ↩
14. OpenCode 源码（commit 60a5a6c），packages/core/src/mcp/stdio.ts 与 packages/core/src/database/database.ts：https://github.com/anomalyco/opencode/blob/60a5a6ca7ce176b04cd2321ffd1819b1ea8e6006/packages/core/src/mcp/stdio.ts ；https://github.com/anomalyco/opencode/blob/60a5a6ca7ce176b04cd2321ffd1819b1ea8e6006/packages/core/src/database/database.ts ↩
15. OpenCode，SECURITY.md（Threat Model）：https://github.com/anomalyco/opencode/blob/dev/SECURITY.md ↩
16. Claude Code 文档，Skills（synced skills）、Plugin loading（synced plugins）与 Settings reference：https://code.claude.com/docs/en/skills ；https://code.claude.com/docs/en/plugins/loading ；https://code.claude.com/docs/en/settings-reference ↩
17. Anthropic，《Strengthening our defenses against distillation attacks》（2026-10-12）：https://www.anthropic.com/research/distillation-defenses ↩
18. Nx，《S1ngularity: What Happened, How We Responded, What We Learned》：https://nx.dev/blog/s1ngularity-postmortem ↩
19. StepSecurity，《s1ngularity: Popular Nx Build System Package Compromised with Data-Stealing Malware》：https://www.stepsecurity.io/blog/supply-chain-security-alert-popular-nx-build-system-package-compromised-with-data-stealing-malware ↩
20. Wiz，《s1ngularity: supply chain attack leaks secrets on GitHub》：https://www.wiz.io/blog/s1ngularity-supply-chain-attack ↩
21. AWS 安全公告 AWS-2025-015，《Security Update for Amazon Q Developer Extension for Visual Studio Code (Version #1.84)》：https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ ↩
22. TechTarget，《What Amazon Q prompt injection reveals about AI security》：https://www.techtarget.com/it-infrastructure/news/366628167/What-Amazon-Q-prompt-injection-reveals-about-AI-security ↩
23. CISA，《Widespread Supply Chain Compromise Impacting npm Ecosystem》（2025-09-23）：https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem ↩
24. Joseph Spracklen 等，《We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs》，arXiv:2406.10279：https://arxiv.org/abs/2406.10279 ↩