你仓库里多出来一个 ci-sync 分支的时候，secret 已经被打印进日志了
先说个自查命令，你可以现在就敲一下：git ls-remote --heads origin 'refs/heads/ci-sync-*'
只要它有输出，你的仓库就已经被人进来逛过了。那些 ci-sync- 开头的分支不是同事建的，是有人拿了一个偷来的 GitHub token 建的。
这事不是哪个软件出了漏洞，是别人拿偷来的 token，在你仓库里做了一件平台本来就允许的事——把 secret 打印到日志里。所以他能进哪些仓库、能干多少事，全看那个 token 当初被授了多大权限。
动作很固定，就三步：
1. 用 token 在每个有权限的仓库建一个分支，名字是 ci-sync- 加 6 位随机字符；
2. 提交一个 .github/workflows/sync-check.yml，commit message 固定是「ci: sync config」，没签名，作者显示成 token 的主人；
3. 这个 workflow 只干一件事——把 secrets 里的东西全打印出来。
关键在第三步。GitHub 给日志打码，只对原样出现的 secret 生效。工具把 secret 先做一次 base32 编码再打印，编码后的串跟原值对不上，打码就绕过去了，明文落进日志。紧接着，工具用 GitHub 自己的 API 把日志拉走，几秒内把 run 删掉——你去 Actions 页面翻，什么痕迹都没有。
为什么出网告警也抓不到：整条外泄走的是 GitHub 自己的 API，没有攻击者域名、没有异常外连，在监控眼里就是「你们家 CI 在拉自己的日志」。
哪些仓库挡得住、哪些挡不住：公开仓库有 7/28 上线的「可疑 workflow 需人工批准」盯着，会拦；私有仓库和 GitHub Enterprise Server 不适用这条，已经观察到私有仓库里的 run 正常跑完然后被删。有 environment 的仓库更糟：攻击者用 job matrix 把 environment 级的 secret 也打出来，而那里放的通常就是生产凭证。
顺带一句，像 permissions: {} 这种收紧，限制的是 GITHUB_TOKEN，管不到 secrets 这个上下文，别指望它兜底。
影响面：850+ 个账号、13,500+ 个植入分支，从个人项目到企业私有仓库。凭证来源是 infostealer 日志，以及此前供应链事件（比如 3 月 Trivy）里漏出去的 token。
怎么处置：这不是软件漏洞，没有「补丁」。要做的是——轮换该仓库能见到的全部 secret、revoke 掉那个 token。如果有 self-hosted runner 跑过这个 workflow，那台机器直接当失陷处理。
一句话自查（再贴一次，值得记）：
git ls-remote --heads origin 'refs/heads/ci-sync-*'
出处：Wiz Research《Gheist: attempted scaled abuse of stolen GitHub tokens stumbles》。
页:
[1]