从窃取PAT到魔改Workflow：聊聊这波差点掀翻GitHub的骚操作

原创

Hankzheng
Hankzheng

技术修道场

2026年10月20日 08:00
广东

去阅读

大家好，作为经常折腾DevOps和CI/CD的IT老兵，大家对GitHub Actions肯定不陌生。但就在最近（2026年10月初），一个名为 GhostAction 的攻击行动在GitHub上掀起了一场血雨腥风。

根据GitGuardian和诸多安全团队的追踪，这波攻击直接端掉了大约1,900个开发者的GitHub账号，超过30,000个代码仓库被当成了提款机。黑客的目标非常明确：从咱们的公共仓库CI流水线里，薅走各种高价值的凭证和密钥。

今天我就带大家扒一扒这次事件的技术内幕，看看这帮黑客到底用了什么骚操作，以及我们该如何防范这种防不胜防的供应链攻击。

01 破防的第一步：并不是GitHub有漏洞

一提到几万个仓库被黑，很多人第一反应是：“GitHub又出0day漏洞了？”

其实真不是。这是一起典型的针对开发者基础设施的供应链攻击。黑客根本不需要去刚GitHub的服务器，他们玩的是“社会工程”和“端点渗透”。

这波攻击的源头，是黑客拿到了开发者们的 个人访问令牌。这些Token是怎么泄露的呢？绝大多数是通过信息窃取木马从开发者的个人电脑里顺走的，或者从暗网的各种数据泄露库里买来的。

技术吐槽：

兄弟们，PAT这种长效凭证一旦泄露，黑客就等于拿到了你仓库的“免死金牌”。加上很多人给PAT开了过大的读写权限，这简直就是给黑客敞开了自家后院的大门。

02 鸠占鹊巢：用你的账号，跑他的恶意流水线

拿到权限后，黑客并没有选择直接去下载代码（那样动静太大，且效率低）。他们的目标是CI/CD流水线里的环境变量和密钥——比如AWS凭证、npm/PyPI/DockerHub的发布Token，甚至是现在最值钱的AI大模型API Key。

怎么偷？这帮人非常狡猾。他们利用被劫持的账号，往你的代码库里强推一个恶意的GitHub Actions workflow文件。

为了掩人耳目，他们会给这个文件起一个极具欺骗性的名字，比如：

• security-audit.yml

（安全审计，好家伙，贼喊捉贼啊）
* github_actions_security.yml

（GitHub Actions安全配置）

不知情的开发者乍一看，还以为是公司安全团队统一推送的合规检查脚本，根本不会去阻拦。

03 硬核拆解：Payload的“三次进化”与骚操作

这是我觉得整篇文章最值得技术人学习的地方。从2026年8月底开始，GhostAction的攻击手法发生了一次明显的“变异”。安全研究员发现，这帮黑客没有用自动化脚本无脑平推，而是进入了实验性质的“手工微调”阶段。

他们的恶意Payload经历了三次非常阴险的技术迭代：

进化一：暴力翻找 Git History

最初的Payload只关注当前环境变量。但新版本加入了一个Git历史记录密钥扫描功能。黑客写了一套非常完善的正则表达式（Regex），专门去匹配Git提交历史里的AWS Key ID、GitLab Token等。很多开发者以为只要在最新代码里把误提交的密码删掉就没事了，但在懂行的黑客眼里，只要你不重写Git提交历史（git filter-branch 或 BFG），这些密码依然等于明文裸奔。

进化二：精准的“上下文匹配”

这也是让我直呼“好家伙”的一个细节。搞过AWS的朋友都知道，AWS的凭证通常是成对出现的：一个 Access Key ID 加一个 Secret Access Key。光拿到ID没用，必须有Secret才能调用API。第二版Payload做了一个绝妙的改进：当它在代码或历史里用正则命中一个AWS Key ID时，它会自动截取该命中位置上下大约两行的代码上下文。这样一来，黑客就能轻松将ID和Secret配对，大大提高了凭证的可用率。

进化三：Git历史上下文深度提取

最终版的Payload将“上下文匹配”直接集成到了Git历史扫描的阶段中，实现了边翻历史记录、边提取上下文的自动化一条龙服务。通过这套组合拳，他们试图从受害者的CI环境中提取出 3,174个核心密钥。

04 攻防博弈与我们的反思

这场攻击的时间线也很有意思。黑客非常讲究“灰度发布”：

• 第一阶段：

先拿160个之前中过招的“老客户”进行Payload测试。
* 第二阶段：

20分钟后，确认脚本没问题，直接大规模推送到28,000个新仓库（10月8日-9日）。

好在GitHub官方在10月9日出手了，直接从平台层面阻断了这些恶意Workflow的运行，导致后续10号和12号的攻击波次全部扑街，未能成功带走密钥。

但这起事件留给我们一个细思极恐的细节：那些在9月份甚至去年就被黑过的受害者，这次又在受害名单里。为什么？因为他们被黑之后，根本没有去轮换自己的密钥和Token！黑客就是在赌你们的惰性。

💡 笔者有话说：给技术人的防御建议

作为一线的技术研发，咱们不能光看热闹，得把自家的防御体系搞起来。针对GhostAction这种攻击手法，我给大家提几个切实可行的建议：

• 废弃长效PAT，拥抱短期凭证：

尽量别用无过期时间的PAT了，能上OIDC进行身份验证的云服务，坚决不用硬编码密钥。
* 严格限制Token权限：

你只是想触发个CI，就别给整个Repo的Write权限。使用细粒度的权限控制。
* 查查自己的Git History：

别光扫描最新的代码树，用 trufflehog 或者 gitleaks 把历史提交也犁一遍，发现泄漏必须去云厂商那里把原来的Key注销掉，而不是只在代码里删除。
* 管好你的生产力工具：

别在乱七八糟的网站下破解软件，你的浏览器Cookie和开发Token被Infostealer打包带走，那就是分分钟的事。

安全无小事，代码需谨慎。你的仓库里，是不是也躺着几年前不小心Push上去的测试Key呢？赶紧去查查吧！

觉得这篇硬核解析对你有帮助，不妨点个赞和收藏，转发给团队里的运维和开发兄弟们提个醒。有问题咱们评论区见！