删掉的 GitHub 仓库，云上的那道「门」可能还开着——OIDC Token 死后接管的完整复盘

你的 GitHub 仓库删了，云上的那道「门」可能还开着。这是 2026 年 6 月安全研究机构 Astrix 披露的一个漏洞：攻击者只需要重建一个同名仓库，就能拿到指向你云账户的 OIDC Token，接管你的 AWS IAM Role 或 GCP Service Account。整个过程不需要任何漏洞利用，只需要你的仓库名被人知道了——而这在 GitHub 上是公开信息。

这个漏洞怎么工作的

GitHub Actions 用 OIDC 代替静态密钥是 2022 年开始推广的最佳实践，逻辑很清晰： workflow 请求一个 JWT，GitHub 签名这个 JWT 声明「这是 repo:X/Y 在 environment:production 从 ref:refs/heads/main 触发的」，云厂商验证签名后发临时凭证。这个方案比存 AWS_ACCESS_KEY_ID 安全太多了——凭证是短命的，过期就废。

问题出在 OIDC 的 sub claim 上。云厂商的 trust policy 通常长这样：

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:environment:production"
  }
}

sub 里包含仓库路径。只要 workflow 拿着这个 sub，云厂商就信任它。问题在于：GitHub 允许重建同名仓库。

你删了 myorg/myrepo，另一个人 fork 或者新建 myorg/myrepo，GitHub 给这个新仓库分配相同的 OIDC sub，因为 sub 里装的就是路径字符串。新仓库的 workflow 请求 OIDC Token，GitHub 签名它，云厂商验证通过——临时凭证到手。

Astrix 把这类「死后身份」叫 Phantom Cloud Identity。它们的 trust policy 还挂在云上，但对应的仓库已经不存在了。攻击者只需要知道路径，不需要黑进任何东西，只需要重建路径。

2026 年的真实案例

这个漏洞不是理论上的。研究员在扫描了数千个云环境后发现了大量这种「僵尸」身份——有些是仓库改名了没清理，有些是内部项目归档了没人管，有些是团队变动导致资源 orphaned。更危险的是，很多公司用模板创建新项目，新仓库继承旧模板的 OIDC 配置，连 trust policy 都没改过。

结合 2026 年已经披露的 GitHub Actions 供应链攻击——actions-cool 两个 action 被劫持标签（credential 盗取），tj-actions/changed-files 23,000+ 仓库被污染，Trivy 整个发布链被拿下——GitHub Actions 作为安全边界的假设正在被动摇。它曾经是「你信任的自动化」，但 2026 年一系列事件说明，攻击者已经把 CI/CD 视为最高价值目标。

怎么排查和修复

第一步：列所有信任 token.actions.githubusercontent.com 的 IAM Role。

AWS 示例：

aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument.Statement[?Principal.Federated==`arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com`]].{RoleName:RoleName,ARN:Arn}'

对每个 Role，用 aws iam get-role --role-name XXX 看 trust policy 的 Condition 里 sub 是什么格式。然后去 GitHub 确认这些仓库是否还存在、是否仍需要这个 Role。

第二步：对每个 orphaned identity，缩小 sub 范围或直接撤销。

如果仓库删了但 Role 还要用，在 trust policy 的 Condition 里加上 ref:refs/heads/main 或 environment:production 做更精确的限制。如果仓库彻底废弃，直接删除 Role 或把 trust policy 清空。

第三步：用 Astrix 或类似工具扫一遍你整个云账号。

纯手工查太慢了，Astrix 提供了自动化扫描，可以列出所有「信任 GitHub OIDC 但对应 repo 已删除」的 Phantom Identity。这个操作值得每季度做一次，尤其是在有团队变动或项目归档之后。

第四步：审计你的仓库删除流程。

加一条规则：删除 GitHub 仓库之前，先查这个 repo 的 OIDC trust policy，清理对应的云身份。很多团队的 SRE 流程里有这一步，但没有显式写进 runbook。

下一步

GitHub Actions 的安全问题在 2026 年已经不是「会不会出事」而是「出事了有没有感知」。OIDC 替代静态密钥是正确方向，但 trust policy 的生命周期管理和 repo 删除的配套流程是必须要补的课。现在去跑一遍上面的命令，看看你的云上有没有 Phantom Identity 在等着被人捡起来。