Baseten GitHub PAT 通过公开 Harbor 镜像泄露 – Strix 如何在 25 分钟内发现管理员权限

摘要

2026 年 7 月，自主黑客代理 Strix 在 Basename 的 Harbor 注册表中一个可公开访问的 Docker 镜像中发现了一个嵌入的 GitHub 个人访问令牌（PAT）。该令牌创建于 2023 年 3 月，授予了对 Baseten 主要产品仓库、GitOps 仓库、Homebrew tap 以及多个私有客户仓库的管理员和推送权限。该发现已被披露，令牌已轮换，公开注册表项目已在 24 小时内私有化。

漏洞是如何被发现的

Strix 对 *.baseten.co 域名进行了黑盒侦察，识别出一个公开的 Harbor 注册表（gcp-us-east4-zlw.registry.baseten.co），并匿名拉取了 baseten/baseten-app 镜像。在提取镜像清单和层之后，Strix：

在镜像的文件系统和配置上运行了 TruffleHog。
检测到存储在 Docker 构建历史（history[].created_by）中的 GitHub PAT。
通过发出 GET /user 请求验证令牌仍然有效，该请求返回了账户 basetenbot。

“Docker 构建历史中的令牌，随后 GitHub 将其识别为 basetenbot。凭证已被编辑。” – Strix 博客文章

泄露令牌的范围

GitHub 报告该令牌的 OAuth 范围为 repo，意味着完整的仓库访问权限。Strix 枚举了该令牌可访问的仓库，并发现：

仓库（已混淆）	授予的权限
`basetenlabs/b***`（产品）	admin: true, push: true
`basetenlabs/f***`（GitOps）	admin: true, push: true
`basetenlabs/h***`（CLI）	admin: true, push: true
其他私有仓库	读/写

这些权限将允许攻击者：

修改推理平台的源代码。
更改控制生产集群的 GitOps 清单。
向 CLI 分发渠道注入恶意二进制文件。
访问包含潜在敏感数据的客户特定仓库。

根本原因：泄露构建凭证

该令牌源自 2023 年 3 月 3 日 的一个 Docker 构建步骤，该步骤通过构建参数注入了 GitHub 令牌：

ARG GITHUB_TOKEN
RUN GITHUB_TOKEN=${GITHUB_TOKEN} bash -c '\
  if [[ "${GITHUB_TOKEN}" != "" ]]; then \
    git config --global --add \
      url."https://${GITHUB_TOKEN}@github.com/".insteadOf "git@github.com:"; \
  fi'

Docker 会在镜像的构建历史中记录确切的命令行，从而无意中持久化了原始令牌。潜在的问题包括：

将密钥作为构建参数使用 – Docker 会将值存储在元数据中。
在 Git 配置中持久化令牌 – 即使后来移除了参数，凭证仍保留在镜像中。

建议的补救措施

切勿将密钥作为构建参数传递。使用 Docker BuildKit 秘密挂载（--secret id=github,src=...）来提供临时凭证，这些凭证不会出现在镜像元数据中。
使用 docker history --no-trunc 检查镜像历史，或下载配置 blob 并检查 history[].created_by 中是否有泄露的值。
立即轮换任何暴露的令牌，并审计所有仓库以查找未经授权的更改。
应用最小权限原则：仅授予构建令牌对其所需特定私有依赖项的读取访问权限，并设置较短的过期时间。
私有化托管内部镜像的容器注册表；除非有意为之，否则避免公开暴露它们。

披露时间线和响应

日期和时间	操作
2026 年 7 月 13 日晚上 11:10	提交 Strix 报告 – 实时 `basetenbot` 令牌，公开 Harbor 项目，仓库权限。
7 月 14 日，上午	Baseten 将 Harbor 项目设为私有。
7 月 14 日，下午 4:34	Baseten 安全团队确认严重状态，轮换令牌，并要求删除镜像。
7 月 14 日，下午 5:05	报告者确认删除并添加了两个较低严重性的发现。
7 月 17 日	剩余发现已关闭。
9 月	准备并批准公开披露。

Baseten 的安全团队行动迅速，在几小时内轮换令牌并将注册表私有化，甚至还发送了感谢礼品。

“我们感谢 Strix 的负责任披露。我们立即采取措施使泄露的密钥失效并删除公开容器镜像。我们的日志确认该漏洞从未被利用，也没有客户数据泄露。” – Baseten 安全代表（HN 评论）

社区反应

正面反馈 – 多位评论者赞扬了快速的补救措施和自主测试的价值。
伦理担忧 – 一些用户质疑安全供应商在没有明确事先同意的情况下针对潜在供应商运行自主代理是否合适，并指出可能存在法律灰色地带。
技术观察 – 其他人指出，使用传统渗透测试工具本可以发现该问题，但强调了 AI 驱动代理的速度和自动化优势。

对运营者的启示

将容器镜像视为长期存在的攻击面 – 即使是旧镜像也可能包含活动的密钥。
在文件系统层和构建元数据中自动化密钥扫描。
为 CI/CD 管道和容器构建实施短期、范围受限的令牌。
定期针对自己的域名运行自主安全代理（如 Strix），以便在攻击者之前发现隐藏的暴露。

如果您依赖基于 GitHub 的构建或公开容器注册表，请今天审计您现有的镜像。泄露令牌的代价可能比预防它所需的努力高出几个数量级。