开发者小心AI工具里的内鬼

跟你说个事儿，AI 编程助手确实挺香的，帮咱们省了不少事儿。但你可能不知道，这事儿背后藏着三个实打实的风险——不是那种“理论上可能”的扯淡，而是已经被发现、被利用、被验证过的安全问题。你敢信吗？

风险一：你用的AI编程工具，自己就是个漏洞

先说个最直接的：你用的AI编程环境，可能正在偷偷往外泄露你的凭证。

这事儿说起来挺有意思。安全公司 LayerX 发现，那个挺火的 Cursor 编程环境，有个高危的访问控制漏洞（CVSS 8.2，够吓人的吧）。问题出在它怎么存数据——Cursor 把开发者的 API 密钥和会话令牌，直接明文存在本地的 SQLite 数据库里，路径是 ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb。

更离谱的是，Cursor 压根没在扩展和这个数据库之间设任何访问控制。这意味着，你安装的任何扩展，都能直接读这个文件，把里面的明文凭证扒出来。攻击者根本不需要特殊权限，也不会触发任何警报。

攻击场景特别清晰：攻击者发布一个看起来人畜无害的扩展（比如换个主题或者搞个效率工具），你安装的时候完全不会收到任何关于凭证访问权限的警告。然后恶意扩展就在后台静默查询数据库，拿到你的 API 密钥和会话令牌，悄无声息地发到攻击者控制的服务器上。

Cursor 安全团队承认了这个问题，但他们的辩解是“扩展和用户处于相同的本地信任边界”。截至 2026 年 4 月，这漏洞还没修。

类似的信任边界问题，VSCode Copilot Chat 也有。研究人员发现，Copilot 的“agent mode”在处理补丁时，对文件移动操作的目标路径没做校验。攻击者可以构造一个看似无害的补丁请求，利用 *** Move to: 指令把恶意内容写入 .git/config，然后通过植入的 sshCommand 把环境变量 GITHUB_TOKEN 传出去。

整个过程里，你看到的确认弹窗只提到了无关文件，没有任何迹象警告 .git/config 要被改。你说吓不吓人？

风险二：AI生成的代码，正在复制不安全的“老毛病”

AI 编程助手不光自己可能出问题，它生成的代码本身也可能是个隐患。这事儿在 Dockerfile 这类基础设施代码上特别明显。

现在很多 AI 模型在生成 Dockerfile、K8s YAML、Terraform 的时候，倾向于输出“更高频、更容易生成、更符合互联网平均实践”的内容，而不是“更安全、更可审计、更适合生产环境”的内容。latest 标签就是最典型的例子。

很多人觉得 FROM ubuntu:latest 只是“不够规范”。但问题在于，latest 本质上不是版本号，而是一个可变指针。今天构建的镜像和三个月后构建的镜像，可能完全不同。上游镜像可能已经换了 Debian 版本、更新了 OpenSSL、升级了 glibc。同一个 Dockerfile，构建结果完全不同。

这在安全领域意味着什么？可审计性下降、漏洞追踪困难、版本回滚复杂、SBOM（软件物料清单）失效。

更值得警惕的是，当 AI Agent 开始参与构建、部署、基础设施生命周期时，流程可能变成“AI generate → auto commit → auto push → auto CI → auto deploy”。一个“不安全默认配置”，就开始具备自动化传播能力。

AI 并没有创造全新的基础设施安全问题，但它正在以自动化方式，大规模复制和放大历史上的不安全实践。这事儿想想就让人头大。

风险三：攻击者盯上了AI工具热潮，精准投毒

第三个风险来自外部：攻击者正在利用开发者对 AI 编码工具的迫切需求，发起精准的供应链投毒攻击。

2026 年初，EclecticIQ 安全研究团队发现了一个针对软件开发者的 SEO 投毒攻击行动。攻击者通过搜索引擎优化技术，把仿冒的 Gemini CLI 和 Claude Code 安装页面推送到搜索结果前列。当你搜索“Gemini CLI install”或“Claude Code setup”时，很容易误入歧途。

攻击流程特别巧妙：合法的 npm 包会正常完成安装，而恶意载荷则在后台静默运行。双轨并行导致受害者很难察觉异常。

恶意代码完全无文件落地，直接在 PowerShell 进程中加载执行。它采用双层防御规避技术：先修补 Event Tracing for Windows（ETW）降低系统日志记录能力，再绕过 Antimalware Scan Interface（AMSI）避免触发安全软件报警。

窃取的目标覆盖了现代软件交付链条的核心凭证类型：OAuth 访问令牌、CI/CD 系统凭据、企业 VPN 详情，以及 Slack、Teams、Discord 等协作平台的会话 Cookie。关键风险在于，有效的会话 Cookie 允许攻击者在不触发二次认证的情况下直接建立已认证会话——这意味着即使你开启了多因素认证（MFA），只要攻击者获取了有效 Cookie，就能完全绕过。

这个攻击基础设施集群包含超过 30 个恶意域名，模仿对象不仅限于 AI 工具，还扩展至 npm、Chocolatey、KeePassXC 等多个领域。攻击者建立了平台化的钓鱼基础设施，具备针对不同开发者群体快速发起定向攻击的能力。

三个风险的共同点

这三个风险看起来各不相同，但有一个共同点：它们都发生在 AI 工具快速普及、开发者安全意识还没跟上的窗口期。

Cursor 的漏洞暴露了 AI 编程工具自身的安全设计缺陷。Copilot 的漏洞展示了 AI Agent 自动化能力与安全边界之间的冲突。AI 生成的 Dockerfile 问题说明模型正在复制互联网的历史技术债务。而 SEO 投毒攻击则表明，攻击者已经盯上了这个窗口期。

个人觉得，对于开发者来说，最需要建立的一个认知是：AI 编程工具生成的代码和配置，不能默认是安全的。无论是工具本身、工具生成的代码，还是安装工具的过程，都需要纳入安全审查的范围。

这不是要否定 AI 编程工具的价值，而是说，在享受效率提升的同时，安全这块短板需要补上。毕竟，谁都不想自己辛辛苦苦写的代码，最后成了别人的“内鬼”。