VIBECODING 系列 · 011
Vibecoding 安全事件与风险案例研究
副题：泄露的密钥、暴露的数据库与被入侵的 AI 工具链 · 调研时间：2026 年 9 月 · 面向读者：独立开发者 / 小团队
TL;DR 2025—2026 年的公开事件表明，AI 编程的翻车点高度集中：一是 vibe-coded 应用默认配置出错（Moltbook 一个 Supabase 配置错误泄露约 150 万个 API 密钥）；二是开发者凭据与供应链被规模化收割（Shai-Hulud 首个 npm 自复制蠕虫感染 500+ 包，CISA 罕见地为单个 npm 事件发通告）；三是 AI 工具链本身成为攻击面（Nx 事件首次把 Claude Code / Codex 劫持为数据外传工具）。对个人开发者，这三类风险都可以用一份一小时的 checklist 挡掉八成：密钥不进仓库、数据库开 RLS、agent 用最小权限 token、克隆陌生仓库先隔离。
1背景：三个新攻击面
当 Karpathy 在 2025 年 2 月提出 "vibecoding" 时，安全问题还只是段子（“忽略报错继续跑”）。到 2025 年下半年，它变成了 CISA 通告级别的事件源。与传统开发安全相比，AI 编程引入了三个结构性的新攻击面：
- AI 写出的应用本身：非专业开发者以默认配置快速上线，缺鉴权、缺 RLS、缺 CSRF。Zuplo 对 15 个 vibe-coded 应用的检查发现，0 个有 CSRF 防护，只有 1 个尝试做限流。
- 开发者的凭据资产：AI agent 需要拿到 API key、数据库连接串、npm token 才能干活，密钥暴露面从“人的终端”扩大到“agent 的上下文”，而大模型会把密钥打印进日志、写进前端、提交进仓库。
- AI 工具链自身：规则文件、MCP 服务器、npm 依赖都是模型的“输入”，攻击者从“攻击代码”转向“攻击读代码的模型”——提示注入成为供应链攻击的新载荷。
一句话概括 2025—2026 年的变化：攻击者不再需要骗过人，只需要骗过读代码的 agent。
2事件全景与数据
约 150 万
Moltbook 泄露的 API 密钥数（Wiz，2025-07）
500+ 包
Shai-Hulud npm 蠕虫波及规模（2025-09）
0 / 15
vibe-coded 应用有 CSRF 防护的数量（Zuplo）
下表按时间线汇总 2025 年以来与 AI 编程直接相关的代表性安全事件（细节见第 3 节）：
| 时间 | 事件 | 类型 | 后果 / 规模 |
|---|
| 2025-07 | Moltbook 配置错误的 Supabase | 数据库暴露 | 约 150 万个 API 密钥、私信、邮箱可被任意读写 |
| 2025-08-26 | Nx 包劫持（"s1ngularity"） | 供应链 + 提示注入 | 劫持 Claude Code / Codex 窃取 SSH key、钱包、token，外传到新建的公开 GitHub 仓库 |
| 2025-09-16 起 | Shai-Hulud npm 蠕虫 | 供应链（自复制） | 500+ 包被感染；CISA 于 09-23 发布通告；后续出现 2.0 并扩散到 PyPI |
| 2025-11 | Cursor CVE-2025-54135 / 54136 | AI IDE 漏洞 | 恶意 MCP 服务器可绕过信任机制实现持久化代码执行（已修复） |
| 2025 全年 | Langflow CVE-2025-3248 被利用 | 低代码 AI 平台 RCE | CVSS 9.8 未授权 RCE，被用于投放 Flodrix 僵尸网络（与 Cursor 无关，常被误传） |
背景数据同样不乐观：GitClear 对 2.11 亿行代码的分析显示，复制粘贴型代码占比从 2021 年的 8.3% 升至 2024 年的 12.3%（相对增长约 48%），被标记为“重构”的改动占比大幅下降——AI 加速了“先跑起来”的代码进入生产。斯坦福 2023 年的经典实验（arXiv 2211.03622）早已给出心理机制：用 AI 写码的人代码更不安全，但自信心更强。
3四个代表性案例
Moltbook：一个 Supabase 配置错误，150 万个 API 密钥（2025-07）
Moltbook 是一个“给 AI agent 用的社交网络”，典型的一人 vibe-coded 产品。Wiz 研究团队发现其 Supabase 数据库暴露了完全可读写的访问权限：任何访问者都能拿到约 150 万个 API 密钥（其中不乏 OpenAI、Anthropic 等厂商的付费 key）、用户私信和邮箱，并能直接改写任意“agent 账户”的数据——等于整个平台的接管权。根因并不高深：anon key 直连数据库、未启用行级安全（RLS），密钥明文入库。启示：vibe coding 时代“数据库即前端”的架构模式，把一条安全边界整个删掉了。
Shai-Hulud：npm 生态首个自复制蠕虫（2025-09）
Checkmarx 于 9 月 16 日率先追踪到该攻击，社区以《沙丘》沙虫命名。它盗取开发者的 npm token，以受害者身份自动发布其他包的带毒新版本，形成自传播闭环，波及 @ctrl/tinycolor 等常用包在内的 500+ 包（各家统计口径不一）。载荷瞄准云凭据与 CI/CD 密钥。美国 CISA 在 9 月 23 日专门发布供应链通告，GitHub 随后宣布推进 npm 的可信发布（trusted publishing）与细粒度 token 改造。11 月的 “Shai-Hulud 2.0” 及向 PyPI 的扩散说明这不是一次性事件，而是新模式的开端。
Nx / "s1ngularity"：第一次把 AI 编程 agent 变成内鬼（2025-08-26）
恶意 Nx npm 包在被安装后，于代码中埋入针对 Claude Code、Codex、Cursor 的提示注入：agent 一读到恶意注释，就“自愿”执行攻击者的指令，收集本机的 SSH 私钥、加密钱包、GitHub/npm token、环境变量，然后创建名为 s1ngularity-repository-NNN的公开 GitHub 仓库把赃物传出去——传到公开仓库恰好绕过了针对“异常外传目的地”的传统 DLP 规则。Snyk 称之为首批“武器化 AI 编程 agent”的案例。启示：你的 agent 以你的权限在跑，仓库里任何一段注释都可能是指令。
Cursor CVE-2025-54135 / 54136（CurXecute / MCPoison，2025-11，已修复）
Check Point 披露：恶意 MCP 服务器可绕过 Cursor 的信任机制，在开发者机器上实现持久化代码执行。同期 Lakera 披露的 CVE-2025-59944 则利用文件名大小写处理的差异，让“打开一个恶意仓库”就足以静默执行代码。两件事共同说明：AI IDE 把“模型 + 工具 + 自动执行”耦合成一个攻面，其严重性超过传统编辑器。另注意纠偏：网络上流传的 “CVE-2025-3248 是 Cursor 漏洞” 是讹传，该编号实际是低代码平台 Langflow 的未授权 RCE（CVSS 9.8，1.3.0 版修复，曾被用于投放 Flodrix 僵尸网络），引用时勿混淆。
4机会分析
安全事件密集的另一面是工具与服务的缺口。对个人开发者和小团队，可做的切入点有三层：
- 面向 vibe coder 的“上线前体检”工具：一个针对 Lovable / Bolt / Cursor 产出物的扫描器（RLS 是否开启、密钥是否进了前端 bundle、管理员接口是否裸奔），本质是把 SAST 做成三行报告。Zuplo 的 15 个应用检查就是这类需求的最好广告。
- 面向 agent 的凭据代理：AI agent 需要 key，但不需要“你的全部 key”。给 agent 发放一次性、可撤销、带额度上限的派生密钥（参考各家 secret manager 的短期 token 能力），是当前工具链的明显空白。
- 面向小团队的供应链基线服务：lockfile 审计 + npm provenance 校验 + “agent 运行在容器里”的一键模板。Shai-Hulud 之后，企业愿意为这条基线付费。
- MCP 服务器审计：模型上下文协议生态里，第三方 MCP 服务器能拿到提示词、文件甚至凭据，而多数团队装第三方服务器前不做任何审查。做“MCP 安全目录 / 隔离运行器”（容器内跑、按能力授权）是 2026 年刚起步的赛道，Cursor 的 MCPoison 漏洞只是把需求摆上台面。
机会点 “给非程序员开发者的安全 checklist 产品”目前几乎无人做——不是技术难，而是没人把 20 条规则翻译成 vibe coder 能看懂的语言并做成一键扫描。
5风险与挑战
风险：提示注入在原理上无解。只要 agent 读不可信内容（依赖源码、issue、网页），注入就存在。个人层面的对策只有降权限 + 隔离执行，而不是指望“提示词防注入”。
风险：非程序员没有“坏了”的直觉。RLS、CSRF 这类词对他们不存在。产品层面的默认值必须安全（Supabase 已在推动默认开 RLS），否则事故会随用户数线性增长。
风险：agent 权限过大成为常态。Claude Code / Codex 默认能读环境变量、跑任意 shell、发网络请求。一旦克隆的仓库或 MCP 服务器被投毒（Cursor 两个 CVE、Nx 事件都已演示），损失以秒计。
风险：责任真空。AI 生成代码导致泄露时，平台、模型厂商、使用者之间责任不清，保险与合规框架都还没跟上——出事时大概率是“你自己担”。
风险：代码与遥测默认出境。另一类被低估的风险是保密性而非入侵：云端 AI 工具默认把代码片段、报错甚至仓库上下文发往厂商服务器。涉密或客户代码动手前，先确认所用工具的数据政策与企业级选项（不训练承诺、区域化处理、自托管模型），这属于新的“数据出境”管理范畴。
6行动建议
- 今天就做（约 1 小时）：检查所有 Supabase / Firebase 项目是否启用 RLS；用
gitleaks 之类工具全仓扫一遍历史提交中的密钥；凡是进过仓库的 key 一律轮换——默认它已泄露。
- 密钥纪律：密钥只放环境变量或 secret manager，永不写进代码与截图；前端只放可公开的 anon key 并配合 RLS；给 AI agent 单独发放最小权限、可撤销、限额的 key。
- 供应链纪律：提交 lockfile 并锁定版本；CI 中开依赖审计；新装包先看下载量、维护者、provenance；Nx 与 Shai-Hulud 事件的共同教训是“热门包的突发新版本”最危险。
- agent 隔离：克隆陌生仓库、接入新 MCP 服务器时，先在容器 / 沙箱（如 devcontainer）里跑 agent；操作系统级密钥（SSH key、钱包）不放进 agent 可读的环境。
- 上线前 checklist：管理接口鉴权、上传/下载限额、CSRF、HTTPS、错误信息不回显密钥——把 Zuplo 那 15 个应用踩过的坑当成自带清单。
- 保持跟踪：订阅 CISA 通告与你所用工具（Cursor、Claude Code、MCP 服务器）的安全公告页；重大事件后第一时间自查仓库里有无
s1ngularity-repository 类残留。