1900个GitHub账号被劫持，攻击者又盯上3万个仓库

攻击事件概述

近期一起大规模 GitHub 安全事件引发开发者社区广泛关注：攻击者成功劫持了约 1900 个 GitHub 账号，随后将目标扩展至超过 30000 个代码仓库。这类事件并非孤例，而是近年来针对开发者平台供应链攻击的典型模式——先拿下账号，再横向渗透仓库资源。

从攻击链路来看，攻击者通常不会直接攻击 GitHub 平台本身，而是瞄准开发者个人这一最薄弱环节：钓鱼邮件、撞库攻击、泄露的凭据数据库，都是常见的入口。

攻击者的典型手法

第一步：批量获取账号凭据

攻击者往往从暗网购买或自行撞库获取大量「用户名-密码」组合。许多开发者在多个平台复用相同密码，一旦某个网站发生数据泄露，GitHub 账号便首当其冲。

第二步：绕过或规避安全验证

部分账号未开启多因素认证（MFA），攻击者拿到密码即可直接登录。即使开启了 MFA，攻击者也可能利用**个人访问令牌（PAT）**绕过二次验证——令牌一旦泄露，等同于把仓库钥匙交给了别人。

第三步：渗透仓库资源

拿到账号权限后，攻击者可以：

• 读取私有仓库中的敏感配置（API 密钥、数据库连接串、云服务凭据）
• 篡改依赖源，在 CI/CD 流程中注入恶意代码
• 推送后门提交，污染项目历史记录
• 利用仓库中存储的其他凭据，进一步攻击企业内网或云基础设施

这就是为什么 1900 个账号被劫持后，影响面会迅速扩大到 30000 个仓库——每个账号背后关联着多个项目。

开发者防护清单

立即执行

1. 开启多因素认证（MFA）：在 GitHub 设置中启用 TOTP 或硬件安全密钥，这是最基础也最有效的防线。
2. 轮换所有访问令牌：检查个人访问令牌（PAT）和细粒度令牌，删除不再使用的，对仍在使用的设置最短有效期。
3. 审计近期登录活动：在 GitHub 的「安全日志」中查看异常登录地点和设备。

长期习惯

1. 使用密码管理器：为每个平台生成独立随机密码，杜绝密码复用。
2. 优先使用 SSH 密钥认证：相比令牌，SSH 密钥更难被远程窃取，且支持硬件绑定。
3. 配置仓库级安全策略：
   • 开启分支保护规则，要求代码审查后才能合并
   • 限制谁能推送代码和修改设置
   • 启用 Dependabot 自动安全更新
4. 定期审查仓库协作者列表：移除不再需要的成员，避免权限残留。

对团队和企业的建议

对于使用 GitHub Enterprise 的团队，建议：

• 强制所有成员启用 MFA
• 通过 SSO 集中管理身份认证
• 启用审计日志并接入 SIEM 系统实时监控
• 定期开展凭据泄露扫描，使用工具检测代码中硬编码的密钥

总结

这次事件再次提醒我们：开发者的账号安全是整个软件供应链安全的起点。1900 个账号的失守导致 30000 个仓库面临风险，这种放大效应源于权限管理的松懈。从个人到组织，建立纵深防御体系不是可选项，而是必修课。