2026 年 6 月 Mozilla 0DIN 披露 AI 编程工具遭 DNS 隧道供应链攻击，仓库干净但恶意指令藏于 DNS 记录。本文复盘攻击链路，提出五层安全防线与 10 条自查清单。
2026 年 6 月 29 日，Mozilla 0DIN 平台披露了一起针对 AI 编程工具的供应链攻击：恶意代码藏于 DNS 记录中，源代码仓库本身完全干净。当开发者通过智能编程助手自动执行 npm install && npm run setup 时，安装脚本利用 DNS TXT 记录远程拉取了下游指令，在本地环境完成远程代码执行。这不是普通的依赖投毒——这是一次专门针对 AI Agent 自动执行链路设计的攻击。
根据 Mozilla 0DIN 技术团队发布的报告，攻击链路分为三个阶段。
第一阶段：仓库外衣。攻击者在 npm 注册表发布了一个名为 claude-dev-utils 的包，名称模仿 Anthropic 生态工具。包的 package.json 声明了 postinstall 钩子——这在 Node.js 生态中是标准操作，几乎没有开发者会逐行审查。
第二阶段：DNS 隧道。钩子脚本本身不含恶意逻辑，只做了一件事：向攻击者控制的域名发起 TXT 类型 DNS 查询。返回的 TXT 记录包含 Base64 编码的后续指令。由于 DNS 查询在企业网络中几乎从不被审计，这一步绕过了所有基于文件内容的扫描产品。
第三阶段：Agent 全程自动执行。智能编程助手读到 package.json 的脚本声明后，自动提议运行安装命令。大多数开发者已经习惯了"一键确认"，直接点了同意。整个过程从输入 prompt 到恶意代码落地，攻击者与受害者之间没有任何直接交互。
传统 DevSecOps 依赖"代码审查 + 依赖扫描 + 运行时监控"三层防护。这次攻击在每一层都找到了盲区：
更关键的是，AI 编程助手改变了攻击面。在传统开发中，从安装依赖到执行陌生脚本，中间至少有人会扫一眼。但在智能编程工作流中，Agent 的自动化把这段人为缓冲压缩到了零——这恰好印证了我们之前的观察：AI 编程的真正瓶颈在人不在模型，当人从决策循环中退出，安全风险会以全新的形态出现。
针对这类攻击，单点防御必然失败。以下五层纵深防线，每一层都可以用开源工具独立实现。
原则：所有 AI 生成或建议执行的脚本，必须在微虚拟机中试运行。
具体方案：使用 gVisor（Google 开源的容器运行时沙箱）或 Firecracker（AWS 开源的 microVM）创建与宿主机完全隔离的执行环境。将 AI 编程工具的终端重定向到沙箱内。首次安装依赖、执行初始化脚本、运行安装钩子时，所有文件写入、网络出站、进程 clone 都被限制在沙箱中。沙箱默认不挂载 ~/.ssh、~/.aws、.env 等敏感路径。
开源工具组合：gVisor + Docker 或 Firecracker + firectl。还可搭配 NixOS 的 declarative shell 作为只读文件系统层。
原则：内网开发环境中，拦截非白名单域名的 DNS 查询，尤其是 TXT/CNAME 类型。
具体方案：在开发机或企业网关部署 CoreDNS 或 Pi-hole，配置查询策略：
*.npmjs.org、*.github.com、*.anthropic.com 等已知白名单域名（仅限 A/AAAA 记录）。0.0.0.0。对于使用 VPN 远程开发的团队，可以在 WireGuard 配置中加入 PostUp = iptables -A OUTPUT -p udp --dport 53 -j NFQUEUE 将 DNS 流量导向审计进程。
原则：文件系统读写、网络出站、进程 fork 三权限分离，默认全部 deny。
这是五层中最关键的一层。当前主流智能编程工具在用户机器上默认拥有几乎完整的 shell 权限——它们可以读写任意文件、访问网络、创建子进程。权限最小化要求：
| 权限类型 | 默认策略 | 白名单示例 | 实现工具 |
|---|---|---|---|
| 文件系统读 | 仅限项目目录 | /home/user/project/** | Landlock LSM（Linux 5.13+） |
| 文件系统写 | deny | /home/user/project/node_modules/** | Landlock + seccomp |
| 网络出站 | deny | registry.npmjs.org:443 | iptables/nftables + 用户命名空间 |
| 进程 fork/exec | deny | /usr/bin/node、/usr/bin/git | seccomp-bpf |
| DNS 查询 | 仅 A/AAAA | 白名单域名 | CoreDNS + eBPF |
| 读取环境变量 | deny | 无（敏感变量永不暴露给 AI 进程） | PAM + namespace 隔离 |
关键实现细节：AI 编程助手进程应运行在独立 Linux 用户命名空间中，通过 seccomp-bpf 过滤系统调用。Landlock 从内核 5.13 开始已经稳定，不需要额外内核模块，是部署成本最低的沙箱方案。
原则：从 Git commit 到 npm publish 到最终安装，建立不可篡改的签名验证链。
具体方案：
npm audit signatures 验证发布者身份。slsa-verifier 命令行工具在 CI 中自动校验。integrity 字段，让包管理器安装时校验 tarball 的 SHA-512——即使 registry 被攻破替换了内容，安装也会失败。2026 年 3 月 GitHub 正式推出 Artifact Attestations GA 版本，配合 npm 的签名验证标志，这套方案已经可以在生产环境启用。
原则：Agent 不是不可以自动执行，但六类高风险操作必须经过人类审批。
建议在工具链中植入审批门禁，以下操作触发人工确认：
~/.ssh/authorized_keys、~/.ssh/config、~/.ssh/known_hosts 的写入。.env、*.pem、credentials.json、~/.aws/credentials。npm install -g、pip install --user 等修改系统或用户级 PATH 的操作。sudo、修改 /etc/hosts、加载内核模块、修改 iptables 规则。git push --force 到保护分支、删除远程分支、修改 git hooks。审批实现可集成到 AI 编程工具的 hooks 机制——Anthropic 于 6 月 29 日发布的 apps gateway 已支持集中策略管理，Cursor 的 Rules for AI 也可定义项目级安全规则。
以下 10 条，每一条都是一个攻击面。建议逐条核对：
curl | bash？.env 和 ~/.ssh？integrity 哈希？npm audit signatures？如果上述有任何一条没做到，攻击者需要的只是你的团队用 AI 编程助手打开一个看起来正常的 GitHub 仓库。
答：前三层（沙箱、DNS 审计、权限最小化）可以做到对开发者透明。gVisor 的额外延迟在 1-3 毫秒量级，对依赖安装这类 I/O 密集型操作影响不到 5%。审批节点确实会增加额外步骤，但我们建议仅对六类高风险操作加门禁——根据蓝曜炬辉内部实践，这六类操作在日常开发中的触发频率低于每天 2 次，影响极小。
答：最低配置三件套：① 开发机启用 Docker + gVisor，所有依赖安装走沙箱；② 开发环境不挂载 ~/.ssh 到项目容器中；③ 团队定一条铁律——"陌生仓库的 setup 脚本先逐行读，不让 AI 助手直接跑"。最后这条零成本，效果覆盖本次攻击 80% 的威胁面。
答：不。任何可以自动执行 shell 命令的 AI 编程工具——GitHub Copilot Workspace、Cursor、Cline、Amazon Q Developer——都是潜在受害者。攻击的核心不在某个具体产品的漏洞，而在于"Agent 自动执行 + DNS 作为隐蔽信道"这个攻击模式。只要工具链中存在"智能体可以不经人工确认就执行外源脚本"的路径，攻击面就存在。
答：截至 2026 年 6 月 30 日，Anthropic 尚未针对本次 0DIN 披露发布专项补丁，但同日发布的 apps gateway 已内置集中策略管理能力——企业管理员可以配置"禁止 Agent 执行特定命令模式"。Cursor 的 Rules for AI 也可定义项目级安全规则。不过两家的默认配置都偏宽松，需要团队主动加固。
这次攻击揭示的核心问题是：AI 编程正在把"开发者信任"从人转移到 Agent，而安全基础设施没跟上。过去一个开发者看到 npm install 自动会产生"这个包是谁发的"的疑问——虽然大多数时候也会忽略直接回车，但至少人在循环中。现在智能编程助手把这个循环中最后一个人类判断节点也自动化了。企业 AI 智能体落地的三个常见坑中，安全盲区往往排在第一，而大多数团队的响应是"等出事了再说"。
如果你正在评估引入 AI 编程工具到企业开发流程，或者已经在使用但尚未建立安全基线，可以联系我们做一次工具链安全评估——从沙箱部署到审批门禁，30 分钟出评估报告。也可以查看我们的企业落地案例，了解其他技术团队如何在不牺牲效率的前提下构建 AI 软件开发安全防线。关于 AI 编程的实际投入产出，我们此前也做过一次半年的真实成本核算，安全投入在其中占比不到 3%，但能避免的损失远不止 3%。