高危漏洞：Claude Code “不再询问” 功能翻车，超千个 GitHub 仓库明文泄露密码、API 密钥

原创

维度攻防
维度攻防

维度攻防

2026年11月9日 09:44
安徽

去阅读

为了提升开发效率，AI 编码助手的 “一键授权、不再弹窗” 功能深受开发者喜爱。但最近安全研究爆出一个严重安全隐患：Claude Code 的「Yes, and don't ask again（是的，不再询问）」功能，会把 Shell 命令里的密码、密钥明文保存，大量配置文件被误提交到公开 GitHub 仓库，造成机密信息大规模泄露The Hacker...。

事件回顾：1122 个公开文件，上千条机密信息外泄

安全公司 Apiiro 的研究团队扫描 GitHub 公开代码库发现，共有1122 个公开仓库中存在泄露敏感信息的.claude/settings.local.json配置文件，合计检出 1379 条独立机密，包含数据库密码、AWS 密钥、Supabase 密钥、SSH 登录凭证等真实敏感凭据。

部分泄露出来的密钥仍处于可用状态，已有被通知的企业确认自家密钥已经对外暴露，随时可能被攻击者利用。即便开发者后续删除仓库里这个配置文件也于事无补，Git 历史记录、项目 Fork 副本依旧完整保留这些泄露内容，单纯删文件无法消除泄露风险The Hacker...。

漏洞原理：方便的 “不再询问” 埋下泄密大坑

默认情况下，Claude Code 在执行 Shell 命令前，会向开发者弹窗请求执行权限。当开发者选择「Yes, and don't ask again（是的，不再询问）」，工具会在项目目录生成.claude/settings.local.json，保存这条命令的放行规则，后续相同命令就不会再重复弹窗确认，减少反复授权的麻烦The Hacker...。

⚠️风险关键点：
如果保存的是完整精确命令，而不是通配匹配规则，整条命令会被原封不动明文写入配置，命令中附带的密码、Token、密钥会一并被保存下来。研究人员使用最新 Opus 5.5、Fable 5.1 版本复现，确认该问题真实存在The Hacker...。

Claude Code 会尝试把该配置写入本机全局 git 排除列表，让本机 Git 忽略该文件。但这个防护有明显局限：

1. 该配置仅作用于当前电脑当前用户的 Git 全局配置，不是项目仓库内的.gitignore；
2. 如果文件已经被提交到仓库，全局排除不会回滚已经提交的记录；
3. 换电脑、新克隆仓库，该排除规则不会跟随项目同步过来，极易发生误提交上传到 GitHub 的事故The Hacker...。

简单说：工具做了本地层面的防护，却没有在项目仓库级别阻止这个配置文件被提交上传，开发者稍不留神，就会把装满密钥的配置文件公开到互联网。

Anthropic 官方回应

Claude Code 团队成员 Boris Cherny 对外承认该问题客观存在。团队表示后续会优化权限模式，但也坦言：自动模式、密钥扫描等手段，无法完全杜绝这类人为授权带来的泄露问题，根源来自开发者确认 “不再询问” 时把携带机密的完整命令做了持久化存储。

🛠️开发者紧急自查与修复建议

如果你使用过 Claude Code

1. 优先轮转密钥：不要先删文件！一旦发生泄露风险，第一时间重置所有相关密码、API Token、数据库密钥。哪怕你已经删掉本地文件，Git 历史依然会留存记录The Hacker...。
2. 项目仓库检查
      - 检索项目是否存在路径：.claude/settings.local.json；
      - 检查 Git 提交历史，确认该文件有没有被提交过；
      - 如果已经提交，需要做 Git 历史清洗，清除历史版本中的该文件；同时提醒所有 Fork 该仓库的人员同步处理。
3. 防护配置
      - 在项目根目录.gitignore强制添加：

.claude/settings.local.json

不要只依赖 Claude Code 的全局 git exclude，项目级别的 gitignore 才会跟随仓库同步，对所有拉取代码的机器生效。

1. 使用习惯调整
      - 尽量少点「不再询问」，避免完整携带密码、密钥的 Shell 命令被持久保存；
      - 执行带敏感凭证的命令，尽量通过环境变量传入密钥，不要直接把密钥写在命令行中。