我先查阅这类 “凭据扫描计数” 的经验记录，再联网核实原始报道和官方修复进展。
这件事的核心结论是：Apiiro 的安全研究人员在公开 GitHub 仓库里扫出了 2,539 个真实凭据，分布在 1,994 个代码库中，根子是 Claude Code 的 “是，且不再询问” 授权机制 —— 它会把整条已批准的 Shell 命令原样写进项目里的 .claude/settings.local.json，命令里如果夹着数据库密码、API Token、SSH root 登录信息，这些明文就一起被存了下来。需要先说清楚口径：这 2,539 个不是 “当前文件里躺着 2,539 个”，而是把当前本地设置文件（1,122 个文件、1,379 个凭据）、Git 历史版本（509 个仓库里的 734 个）、他人 fork（74 个仓库的 211 个）、共享设置文件与智能体对话记录合并后的总数，受影响组织 63 家。研究团队明确说明没有去测试这些凭据、也没有连接对应主机，所以准确表述是 “暴露”，不等于 “全部仍然可登录”。官方这边，Claude Code 负责人 Boris Cherny 已在 11 月 7 日于 Hacker News 回应，称团队正在研究预防措施，承认设置文件本不该进版本控制，并考虑把密钥扫描内置进 Claude Code，但没有给出交付时间表。
一、先拆数字：三层口径，别混成一个数
这类 “发现 N 个凭据” 的报道，最容易在传播中被放大。把 Apiiro 的披露拆开看是这样：
| 口径层级 | 范围 | 文件数 | 凭据数 | 仓库数 |
|---|---|---|---|---|
| 当前可见的本地设置文件 | 公开的 .claude/settings.local.json 副本 | 104,185 份副本中 1,122 份含密（约 1.1%） | 1,379 个 | 103,617 个仓库为扫描基数 |
| Git 历史版本 | 已被删除但留在历史里的内容 | — | 734 个 | 509 个 |
| fork 副本 | 从原仓库分叉出去的拷贝 | — | 211 个 | 74 个 |
| 合并后总数（含共享设置文件、智能体对话记录） | 全部来源 | — | 2,539 个 | 1,994 个 |
关键限定有两句必须保留：一是研究者没有验证凭据是否仍然有效，只在通知企业时有一家确认自己的密钥当时确实可用；二是目前没有确认证据表明这些凭据已经被利用。所以标题里的 “真实凭据”，准确含义是 “格式与上下文判断为真实密钥，而非测试样例或占位符”，不是 “已被验证可登录”。
二、泄露是怎么发生的：一条便利设置，把临时密码变成永久明文
路径并不复杂，也不涉及恶意提示词或供应链投毒，是正常使用流程里长出来的：
- Claude Code 要跑某条 Shell 命令时，会先弹确认，问你是否允许。
- 你选了 “是，且不再询问”，这条授权就被写成一条 permission 规则，存进项目目录下的 .claude/settings.local.json。
- 如果命令原文里带着 PGPASSWORD=xxx、sshpass -p、mysql -p 后面的口令，或者 curl 请求头里的 Bearer Token，这些值会被一并存进去，变成项目目录里的持久明文。
- 原本的设计是让 Claude Code 把该文件加进开发者的全局 gitignore，正常情况下不会被提交。但这个全局规则不会跟着仓库走：项目被克隆到另一台机器、普通文件夹后来才 git init、或者文件已经被 Git 跟踪过，保护就失效。
- 研究还发现，1,105 个受影响仓库里有 539 个存在 Claude 作为共同作者的提交，改动了这个设置文件 —— 也就是说，部分提交是智能体参与完成的。
- 一旦进了公开仓库，事情就很难回收：删掉当前文件不等于删掉 Git 历史，fork 里还会继续留着。
还有两个放大器：允许列表越长，泄露概率越高 —— 超过 8 KB 的设置文件里，大约每十个就有一个含真秘密，而小于 500 字节的文件里这个比例不到五百分之一；开发者点 “不再询问” 的时间越长，文件里攒的口令就越多。
三、泄露了什么：凭据类型与受影响对象
| 凭据类型 | 数量 | 说明 |
|---|---|---|
| 数据库口令 | 379 个 | 覆盖 MySQL、PostgreSQL 等连接口令 |
| Supabase service-role 密钥 | 122 个 | 具备较高数据权限 |
| Supabase 账号 Token | 103 个 | 账号级访问令牌 |
| SSH 登录凭据 | 43 个 | 含 root 级登录信息 |
| GitHub / GitLab / npm Token | 42 个 | 可触达代码仓库与包发布链路 |
| AWS 密钥 | 23 个 | 云基础设施访问 |
| 私钥 | 6 个 | — |
特别敏感的个案包括：一家数据库厂商的管理级云密钥、一套 Azure PostgreSQL 生产库口令、一个 Square 生产环境令牌，以及一个医疗记录数据库的所有者级密码。受影响主体共 63 家组织，以软件公司为主，也涵盖学生团队、初创企业、软件代理商和成熟供应商；多数仓库属于个人开发者。除 GitHub 之外，研究者还在 Hugging Face、GitLab 上发现同类文件，并提示这些内容也可能进入已发布的软件包、Docker 镜像和项目压缩包。
四、官方修复到哪一步了：承认问题、在评估方案、没有时间表
时间线拉一下会更清楚：
| 时间 | 事件 |
|---|---|
| 2025-08-11 | 已有开发者在 GitHub 提交相关 bug 报告，指出被批准的含密命令未做清洗就落盘；据 IT 之家报道，此类报告后来因 60 天无活动被自动关闭 |
| 2026-11-05 | Apiiro 发布研究报告，11-08 更新 |
| 2026-11-07 | Claude Code 负责人 Boris Cherny 在 Hacker News 公开回应 |
| 2026-11-09 | Ars Technica 等媒体跟进报道，事件扩散 |
| 2026-11-10 | 中文科技媒体转载，官方表述仍为 “正在研究预防措施” |
Boris Cherny 的公开说法有三点：历史上 Claude Code 没有做密钥清洗；设置文件本不应被提交到版本控制；团队在原型验证 “让自动模式识别这类情况” 和 “内置基础密钥扫描”，但未给出上线日期。他同时建议用户启用更安全的 Auto 模式、别手工维护允许 / 禁止清单，并无论用哪个编程智能体都开着 GitHub 的密钥扫描。这属于 “已确认、在修、未交付” 的状态，不是 “已修好”。
五、为什么常规扫描器漏了约两成
研究者把 1,122 个含密文件喂给两款主流工具，结果是：
| 工具 | 命中文件数 |
|---|---|
| Gitleaks | 564 |
| TruffleHog | 643 |
| 两者都没报出来 | 215（约占 19.2%） |
原因是这类工具依赖 “厂商前缀 + 长随机串” 的特征匹配，而写在 PGPASSWORD=、sshpass -p、mysql -p 后面的口令，在扫描器眼里就是命令里一个普通单词；curl 请求头里的 Token 也常被当成普通文本。结论很直白：CI 里接了密钥扫描不等于安全，得把智能体的配置目录一起纳入扫描范围。
六、自查与处置清单（按顺序做）
处置顺序有个硬原则：先轮换，再清理。文件删了，密钥还在历史、fork、别人的克隆里活着。
- 盘一遍本地：检查 .claude/settings.local.json、.claude/settings.json，逐条看 permission 规则里有没有完整命令带口令。
- 确认是否被跟踪：若已在版本控制里，先取消跟踪再加忽略 ——git rm --cached .claude/settings.local.json，然后在仓库级 .gitignore 里加 .claude/settings.local.json，别只依赖全局 gitignore。
- 查历史与 fork：扫 Git 历史提交、看有没有他人 fork 保留了同一批内容。
- 轮换所有已暴露的凭据：数据库口令、云密钥、SSH 账号、代码托管 Token、npm 发布 Token 一律重置，并翻一遍对应服务的访问日志找异常。
- 改掉写法：命令里不要塞明文口令，改用环境变量引用密钥管理服务里的值；批准授权时批 “命令模式”（如 Bash(npm run:*)），而不是整条带参数的命令。
- 扩扫描范围：把 .claude、.cursor、.gemini 这类目录和智能体记忆文件，按 .env 的级别对待，纳入预提交钩子和 CI 扫描。
【常见问题】
问题 1：Claude Code 这次在 GitHub 上暴露的 2539 个凭据，是不是都还能直接登录？
回答 1：不能这么理解。Apiiro 统计的 2,539 个凭据是 “合并全部来源后的暴露总数”，研究团队明确表示没有去测试这些凭据、也没有连接对应主机，因此结论是 “暴露” 而非 “验证有效”。只有一家被通知的企业确认，自己那个密钥在通报时确实处于可用状态。另外这 2,539 个里有相当一部分来自 Git 历史和 fork，当前文件里已经看不到，但仍可被翻出来。看到 Claude Code 相关报道时，把 “暴露数量” 和 “可用数量” 分开看，判断才不会跑偏。
问题 2：为什么 Claude Code 会把密码写进项目文件，是它主动上传的吗？
回答 2：不是主动外传，是授权机制的副作用。你在 Claude Code 里选择 “是，且不再询问” 时，它会把你批准的那条 Shell 命令原文当作 permission 规则，写进项目下的 .claude/settings.local.json；命令里如果带着 PGPASSWORD=、sshpass -p 或 curl 头里的 Token，这些值就跟着落成明文。Claude Code 原本会把这个文件加进开发者的全局 gitignore，但这条规则不随仓库传递，遇到克隆、后建仓库或文件已被跟踪的情况就失效，之后随提交进了 GitHub。
问题 3：官方到底修没修？现在还能放心用 Claude Code 吗？
回答 3：官方目前的公开状态是 “确认问题、正在研究预防措施”，尚未交付具体修复。Claude Code 负责人 Boris Cherny 在 11 月 7 日回应称，团队在原型验证让自动模式识别这类情况、以及内置基础密钥扫描，但没有给出上线时间；他也说明设置文件本不该进版本控制。在此之前，GitHub 上相关 bug 报告曾因 60 天无活动被自动关闭。日常使用可以继续，但要把 .claude/settings.local.json 当成敏感文件管理，别在里面留明文口令，也别把它提交到 GitHub。
问题 4：我们仓库已经开了 Gitleaks，为什么还会漏掉 Claude Code 写进去的凭据？
回答 4：因为漏检率不低。Apiiro 把 1,122 个含密文件同时跑了两款主流工具，Gitleaks 报出 564 个，TruffleHog 报出 643 个，有 215 个两家都没报，约占 19.2%。这些工具靠 “厂商前缀加长随机串” 的特征匹配，而写在 PGPASSWORD=、sshpass -p、mysql -p 后面的口令在命令里就是个普通单词，没有可识别格式。所以除了常规密钥扫描，还得把 .claude、.cursor、.gemini 这些智能体目录和历史提交单独扫一遍，Claude Code 这条链路才堵得住。
问题 5：如果我在公开 GitHub 仓库里发现了泄露的凭据，第一步该做什么？
回答 5：先换密钥，再删文件。Claude Code 这类场景里，凭据可能同时存在于当前文件、Git 历史、他人 fork 和本地克隆中，只删当前文件等于没处理。正确顺序是：立即在对应服务上吊销并重置该凭据，翻访问日志确认有无异常调用，然后用 git rm --cached 取消跟踪、在仓库级 .gitignore 里排除 .claude/settings.local.json，最后再评估是否需要清理历史。把 “轮换优先于清理” 当成固定动作，能避免清理干净了但密钥还活着的尴尬。
【参考资料】
[2026-11-10]（官方正在修复：Claude Code 被爆把密码写进项目文件，GitHub 上发现 2539 个真实凭据）IT 之家（新浪科技转载）
[2026-11-09]（Anthropic Claude Code's 'Don't Ask Again' Feature Exposes 2,539 Secrets on GitHub）GBHackers
[2026-11-09]（Claude Code помог опубликовать тысячи паролей и ключей доступа на GitHub）iXBT
[2026-11-08]（Claude Code filtró contraseñas en 1.122 repos públicos de GitHub）Facialix
[2026-11-07]（Claude Code Permission Feature Exposes 2,539 Secrets Across GitHub Repositories）The 420.in
[2026-11-07]（Claude Code expose 2 539 secrets sur GitHub）CyberC4st
[2026-11-05]（Apiiro 研究报告：Claude Code 配置文件的凭据暴露分析，11 月 8 日更新，经 GBHackers 与 The 420.in 引述）Apiiro
【免责声明】
本文基于 2026 年 11 月 10 日前公开的研究披露与媒体报道整理，2,539 个凭据为跨当前文件、Git 历史、fork、共享设置文件与智能体对话记录的合并统计值，研究团队未对凭据有效性做连接验证，也未确认存在实际利用行为，具体数量、受影响组织与修复进展以 Apiiro 原始报告及 Anthropic 官方后续公告为准。文中涉及的命令与处置步骤仅用于防护与自查，请勿用于任何未授权系统的访问或测试；企业与个人应结合自身仓库权限、密钥管理规范与合规要求执行，本文不构成安全评估结论或责任认定。