钥匙不在包里，在日志里

根因不在正式报告里

GitHub CLI OAuth token exposure

After a thorough investigation, we have observed specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs.

Access to our internal LiteLLM deployment

We identified an unexpected, innocuously named user account in our internal LiteLLM deployment, which was exposed to the public internet. We believe the attacker gained access to this deployment, obtained the GitHub CLI OAuth tokens from its logs, and subsequently used those credentials to compromise our release workflow.

这句话目前只有一方在说

• 更新日志里有一条：从 2.1.251（2026-08-28）起，页脚的 PR 徽标改为直接调用 GitHub API（via gh auth token、GH_TOKEN 或 GITHUB_TOKEN）。4 也就是说，这个工具会自己去取 GitHub 的原始令牌。
• 会话目录的文档写着，~/.claude 里的文件是明文的；「如果一个工具读了 .env，或者某条命令打印了凭证，那个值就会被写进 projects/<project>/<session>.jsonl」。5 gh auth token 的输出正是「某条命令打印了凭证」。
• 沙箱文档举的第一个遮蔽例子，就是 ~/.config/gh/hosts.yml 里的 GitHub token，并示范「让 Claude 跑 cat ~/.config/gh/hosts.yml」看遮蔽是否生效。6 遮蔽要在配置里自己加，不是默认行为。

那扇门，可能本来就没锁

The proxy exits at boot … when the master key it resolved is not set, is empty or only whitespace, or matches a publicly known unsafe value. With no master key the proxy runs without authentication and accepts every request. The known unsafe value was widely advertised in LiteLLM's own docs and tutorials, so anyone who can reach the proxy can guess it.

三把钥匙，两道锁

• 周一，为了让两名工程师能给客户发日常修复，发布权限被临时扩大了。
• 攻击者手上有三套开发者 GitHub CLI 凭据，其中一套能运行 GitHub workflow。
• 攻击者先试图合并一处改动，让发布器指向另一个源仓库，被分支保护拦下（10:08:29）。三套凭据里有一套属于组织的两名 owner 之一，这个账号关掉了分支保护并强推改动（10:08:34）。
• 改后的 workflow 指向仿冒仓库 Berri-AI/litellm，签名并发布了投毒产物。1

四小时之后，被验证的是钥匙

今晚能查的四件事

1. 把你自己的日志当密钥库查。在网关与代理的响应体日志里搜 ghp_、gho_、github_pat_。找到就不要当误报；日志的保留期通常比一个 token 的授权期长。
2. 查那台网关。master key 设了吗，是不是那个众所皆知的默认值；用户表里有没有说不清来历的账号；它是不是真的只能从内网访问。
3. 数 owner。组织里有几个 owner，他们的 gh token 现在躺在哪些 CI、笔记本、日志与截图里。
4. 看 CloudTrail。先看 GetCallerIdentity 的调用方与来源，再看角色有没有从你的基础设施之外被使用。

边界