由于deadbeef分支已不存在 ， GitHub将 deadbeef 解析为攻击者的commit ， 在该commit中找到恶意的Actions工作流 ， 并继续给提供储存库的敏感信息 ， 以及授予攻击者储存库的写入权限的 GITHUB_TOKEN。[5]

请注意 ， 这个攻击场景需要大量的用户互动（攻击者需要等待有人偶然推送一个异常命名的分支） ， 所以它比之前博文中描述的攻击要轻得多 。
在我向GitHub报告这个问题后 ， 他们添加了一个修复程序 ， 确保 pull_request_target事件只能从分支触发 ， 而不是从游离的commits中触发 ， 这就防止了这种攻击的发生 。 在写这篇文章的时候 ， 如果基分支的名字与储存库中的commit短hash相同 ， 仍然有可能用一个被删除的基分支重新打开拉动请求 。 我 认为这不影响安全 ， 但看起来很有趣 。
一些解释：（对应原文[1]-[5]）

2. git CLI也会进行相同的操作 。git CLI和GitHub在这里的行为一致 ， 可能不是巧合——它们似乎都在使用 git rev-parse 的结果 。
3. 这是我的实验第三次在发现安全漏洞方面发挥了作用 。我真的不知道该如何看待这个问题 。也许我现在可以把我所有的实验归类为"安全研究" 。(这是第一次： https://blog.teddykatz.com/2019/11/12/github-actions-dos.html 。第二次是一个低严重性的问题 ， 就略过不谈） 。
4. 具体来说 ， 分支名需要能被 git rev-parse 解析为commit hash 。这可以是一个十六进制的字符串 ， 比如 deadbeef， 也可以是一个 git describe 格式的字符串 ， 比如 anything-123-gdeadbeef， 这仍然会解析为 deadbeef commit 。
5. 上一篇博文发布后 ， GitHub引入了大量可选择的安全功能 ， 以减少这种类型攻击的范围 ， 如Actions environments 。

— END—
《新程序员001-004》全面上市 ， 对话世界级大师 ， 报道中国IT行业创新创造
— 推荐阅读 —
? Python：Bug 官网不要了 ， 全迁去 GitHub！
? 微软若“无故”解雇暴雪 CEO ， 将付 1500 万美元“分手费”
?马斯克：我是Rust粉丝 ， 但我选择C