关了设置仍在偷传？实测抓包 ZCode 偷传 .git 历史与 GitSpawn 漏洞：我们给 AI 编程助手开的权限彻底失控了
智谱 AI 旗下桌面编程助手 ZCode 被开发者实测抓包证实，在后台静默将本地工作区打包上传至阿里云 OSS，其中包含大量私钥与未公开分支的 .git 历史占比高达 86.6%，且关闭设置后仍未停止；叠加同期曝光波及 Cursor、Claude Code 等 7 大智能体的 GitSpawn 任意代码执行漏洞，宣告 AI 编程工具正在遭遇系统级信任危机。开发者切勿心存侥幸，应立即轮换历史提交中的私密凭证，并将所有终端智能体收拢至容器沙箱。
# 关了设置仍在偷传？实测抓包 ZCode 偷传 .git 历史与 GitSpawn 漏洞：我们给 AI 编程助手开的权限彻底失控了
2026 年 9 月中旬，全球开发者社区与信息安全圈接连遭遇两场重型地震。一边是独立开发者实测抓包披露，智谱 AI 旗下的桌面编程助手 ZCode 在用户不知情的情况下，静默将本地工作区打包加密上传至云端对象存储，其中代表项目完整提交历史的 .git 目录体积占比竟高达 86.6%，且在用户关闭“优化计划”后上传动作依旧继续；另一边，安全机构曝光了代号为 GitSpawn 的严重漏洞，黑客只需在开源仓库植入恶意配置文件，就能让 Cursor、Claude Code、Codex、Qwen Code 等 7 大主流编程智能体在毫无沙箱弹窗警示的情况下在宿主机执行后门指令。两起看似孤立的事件，共同撕开了 AI 编程工具繁荣背后的系统级隐患：为了追求全自动写代码与代码库级理解的快感，我们赋予了 AI 助手过高的本地系统权限，却几乎没有建立起任何有效的信任与隔离防线。
---
核心结论：撕开代码智能体的安全滤镜
- 抓包实锤：全量工作区静默上传，.git 历史占比高达 86.6%：独立安全研究员与开发者实测验证，ZCode 在运行期间自动生成包含整个项目目录的归档文件并回传至云端。在典型的 345MB 测试工程中，生成的 313MB 加密包里绝大部分是版本库历史与 LFS 缓存，并非仅限于当前正在编辑的业务代码文件。
- 杀伤力根因：删掉的私钥全在版本历史与 Reflog 里裸奔：开发者常常误以为“代码已清理”就代表安全，然而 Git 的对象存储和 Reflog 会永久记录所有历史提交。一旦包含提交历史的
.git目录脱离本地受控环境，曾经误提交并随后被“删除”的云服务密钥、数据库密码和内部接口将彻底暴露。 - 行业横向共振：GitSpawn 漏洞击穿 7 大主流 Agent 本地防线：几乎在同一时间段曝光的 GitSpawn 漏洞证明，智能体在自动化解析项目依赖和调用本地终端命令时存在严重的上下文盲区，使黑客能够利用克隆的恶意代码仓库直接在开发者电脑上取得远程代码执行（RCE）权限。
- 底线行动：别等官方补丁与致歉，立刻轮换凭证并收紧本地权限：任何在 ZCode 中打开过核心业务仓库的团队，必须立即轮换历史 Git 提交中涉及的所有 API Key 和访问凭证；同时将所有具备自动化终端执行能力的 AI 工具限制在无内网凭证的容器化沙箱中运行。
---
发生了什么：从一次日常抓包到 313MB 加密压缩包的曝光
事件的导火索始于开发者在日常网络排查中捕捉到的异常流量。
根据独立开发者 ferstar 在技术论坛与社交平台公布的逆向工程报告，当用户登录并使用智谱 AI 推出的 ZCode 桌面客户端时，系统后台会触发静默归档任务：
``text
网络流量分析与本地临时文件取证记录：
- 监控对象：ZCode 桌面客户端后台守护进程
- 目标上传地址：阿里云 OSS 对象存储桶（oss-cn-shanghai.aliyuncs.com）
- 生成归档文件名：workspace_snapshot.zip（临时哈希命名）
- 本地测试样本工程体积：345 MB
- 生成并上传的加密包体积：313 MB
- 归档内容构成分析：.git/objects 及 reflogs 占比 86.6%，业务源码占比 11.2%，配置文件占比 2.2%
- 加密手段：本地 AES-256-CTR 加密，加密公钥归属官方服务端
- 异常行为：在客户端设置中手动关闭“优化计划”与索引开关后，后台上传仍周期性发生
``
在详细的取证分析中，三处反常的设计细节引发了开发者群体的强烈信任危机：
- 归档范围毫无过滤机制，客户端并未遵守 .gitignore 规则，甚至直接穿透至根目录的隐藏版本库；
- 数据被本地强加密包装，但解密私钥仅存在于服务端，导致开发者即使发现流量外发，也无法直观审计被打包回传的具体数据内容；
- 用户界面中提供的退出数据收集选项并未真正切断底层的打包服务，形成了事实上的“UI 欺骗”。
随着网络讨论持续发酵，智谱官方团队随后紧急发布回应声明：解释称该行为源于内部正在测试的“代码库云端索引（Codebase Indexing）”功能，初衷是为开发者提供跨设备会话同步、代码历史回滚以及自动生成“项目 Wiki”。官方表示该功能在早期测试版本中被错误地默认开启，目前已紧急推送修复版本阻断自动上传，并承诺后续将对 ZCode 进行开源、引入第三方安全机构审计，同时向受影响用户发放算力额度补偿。
---
为什么重要：偷传 .git 比偷传源代码致命十倍
很多非安全背景的工程师在初次听闻此事件时，下意识会产生误判：“代码写得又不算独家发明，传到云端做索引能有什么大危害？”
这是对版本控制系统底层机制的严重认知偏差。
- Git 对象数据库的不可变性：在 Git 的底层存储机制中，每一个被 commit 过的文件都会被生成为独立的 blob 对象保存在
.git/objects中。即使开发者随后执行了修改提交或者git rm，只要没有经过极端苛刻的历史重写与垃圾回收，那些历史版本文件就会一直驻留在本地磁盘上。 - 真实研发环境中的凭证残留惯性：在敏捷开发和快速本地调试中，开发者普遍存在手滑将测试环境变量、云厂商 AccessKey、生产数据库连接串硬编码在代码中的行为。绝大多数人随后采取的补救措施是在下一次提交中将私钥删除，而这些早已被历史提交捕获的敏感资产，随着
.git整体被压缩外发，立刻变为黑客字典中的明文凭证。 - 本地分支与草稿设计的暴露：除了历史私钥，
.git目录还完整记录了开发者从未git push到远程服务器的本地临时分支、架构设计草图、未公开的缺陷工单以及内部员工的 Git 邮箱签名，这意味着企业的未公开研发动态和内网架构全盘公之于众。
---
行业横向对比：从 ZCode 到 GitSpawn，AI Agent 的权限大冒险
如果将视野从单一工具的失误跳脱出来，审视整个 AI 编程工具链，会发现这绝非个别团队的偶然疏忽，而是整个行业在追求“全知全能 Agent”过程中的系统性冒险：
| 评估维度 | 传统轻量编辑器（如 VS Code 裸机） | ZCode 抓包事件暴露机制 | GitSpawn 漏洞波及智能体（Cursor/Claude Code 等） | 理想的防护型沙箱智能体 | | :--- | :--- | :--- | :--- | :--- | | 文件系统访问边界 | 仅按需读写当前打开文件 | 全量穿透工作区，甚至静默读取 .git/ 与私密缓存 | 允许 Agent 自动遍历并读取全库，包括配置文件 | 仅限挂载当前源码目录，物理隔离 .git 与 .env | | 网络数据外发行为 | 仅在用户明确安装同步插件或提交代码时外发 | 后台自动打包并通过 OSS 回传，本地加密阻断用户审阅 | 触发后门直接建立反向 Shell，数据无感外泄 | 本地模型或网关级审查，阻断未授权外部连接 | | 终端命令执行权限 | 用户手动输入并确认每一行终端指令 | 本地守护进程静默运行，无需前台命令交互 | 恶意 .git/config 欺骗 Agent 自动执行任意命令 | 严格受限容器内执行，禁止宿主机高权限提权 | | 安全控制权归属 | 开发者具备 100% 确定性控制权 | 界面开关失效，云端策略优先于本地设定 | 依赖模型语义判断，极易遭遇 Prompt/配置注入 | 基于 Linux 原生 Namespace 与 Seccomp 硬隔离 |
从上表对比可以看出，当前开发者正面临智能体演进带来的三重深层安全断裂：
1. GitSpawn：一个恶意配置文件如何打穿 7 大智能体
几乎在 ZCode 争议发酵的同时，安全机构公布的 GitSpawn 概念验证（PoC）展现了另一种维度的危险：攻击者在 GitHub 开源项目中夹带恶意的 .git/config 文件，该配置定义了特定的外部凭据助手或清理脚本。当开发者使用 Cursor、Claude Code 等工具打开项目并让 AI 检查代码时，AI 为了“理解仓库状态”会自动执行原生 Git 查询命令，直接触发了宿主机上的恶意钩子，完成了静默提权与任意代码执行。
2. 从打字机到超级特工：AI 智能体权限膨胀的必然代价 在 Copilot 时代，AI 充其量只是一个行内文本预测器，它没有终端权限，也不关心项目架构；但在 2026 年的智能体时代，每一个编程工具都在宣传“一句话重构全项目”、“自主跑单测自愈缺陷”。为了实现这些功能，开发者不得不赋予 AI 读写全盘文件、在控制台运行 Shell 命令、安装第三方依赖甚至启动本地 Docker 的“超级特工”权限，任何一处安全边界的溃缩都会引发宿主机沦陷。
3. 惰性架构的恶果：云端全量索引成为开发者的安全噩梦 为什么团队总喜欢在后台把代码库打包到云端？本质上是因为在云端集中部署 GPU 集群计算向量嵌入（Embeddings）和代码知识图谱，在工程实现上远比在成千上万台算力各异、内存受限的开发者本地设备上计算要廉价和快速得多。为了节省客户端资源与研发周期，工程团队轻率地选择了“先把整个仓库传上来再说”的懒惰路线，最终亲手炸毁了用户的信任堤坝。
---
编辑部判断与行动建议：程序员如何给 AI 助手上紧安全发条
商业竞争再激烈，也不能拿开发者的系统底线做筹码。针对当前的信任危机，AI Radar 编辑部给出如下硬核应对建议：
- Guideline 01: 立即执行历史提交凭证的全面轮换（Rotate）：不要抱有“没人会特意翻我小项目”的侥幸心理。只要曾经在被抓包工具中打开过的项目，立即检查其历史 commit、配置环境变量，并在云控制台吊销所有曾出现在其中的 API Token、AK/SK 与数据库授权。
- Guideline 02: 配置全局 Git 与文件忽略防御规则：在个人开发机上配置全局
~/.gitignore，并在 AI 插件配置中增加阻断规则，强制剥离.git、.env*、id_rsa、*.pem等私密文件，从物理路径上禁止插件的守护进程接触版本历史。 - Guideline 03: 将具备终端命令权限的 Agent 关入容器沙箱：坚决不在宿主机直接运行允许自主执行命令的开发工具。使用 Docker、DevContainer 或 macOS 虚拟机搭建无内网凭据挂载的开发环境，将 AI 的活动半径限制在沙箱以内。
- Guideline 04: 优先选用纯本地模型或私有化网关工具：对于涉密项目与核心业务代码，优先使用 Ollama、LM Studio 等纯离线本地推理工具，或者采购支持本地向量化索引且具备无日志保留（Zero Data Retention）企业协议的成熟平台。
- Guideline 05: 建立 AI 编程工具准入审计规范：团队技术主管应将 AI 编程客户端视同第三方二进制软件进行严格安全准入，定期使用抓包工具监控其网络端口行为，严禁任何闭源工具在未经网络授权的前提下向未申报的公有云端点发送大数据包。
---