软件供应链安全厂商 Apiiro 于 2026 年 10 月 8 日披露，恶意行动 FakeGit 已于 10 月 4 日重新活跃，其在 GitHub 上的恶意仓库总数达到约 17610 个。这些仓库以迷惑性的 README 与下载按钮为诱饵，投递加载器 SmartLoader，最终落地 StealC 信息窃取程序。由于 FakeGit 滥用 GitHub 这一被高度信任的开发者基础设施，删除单个仓库几乎无法压制行动，而当前最该警惕的人群，正是习惯从 GitHub 随手安装 AI 技能与 MCP 服务器的开发者。
事件概述
FakeGit 这一名称最早由企业浏览器厂商 Island 在 2026 年 7 月提出，当时统计约 7600 个虚假仓库在传播 SmartLoader，其中 800 多个伪装成出现在公开 AI 注册表与目录中的 AI 技能或 MCP 服务器。Island 还发现，ChatGPT、Gemini 与 Claude 在被要求完成相关任务时可能推荐这些仓库。据 Apiiro 报告，行动于 10 月 4 日恢复，规模扩大至 17610 个仓库；仅 34 小时内就推送了超过 13000 个仓库，峰值达每小时 2999 个。操作者主要使用一次性账号，但研究者识别出至少 700 个账号疑似属于真实开发者。
技术细节
FakeGit 的手法并不复杂，胜在规模与伪装。每个仓库都配有一份可信度较高的 README，其中「Download」按钮指向一个 ZIP 压缩包。在 Apiiro 抽样的提交中，97% 只改动了 README 文件，88% 把下载按钮重新指向安装 SmartLoader 的 ZIP。研究者指出，操作者无需新建任何仓库——「仓库舰队早已存在，只是被重新瞄准」。SmartLoader 负责建立持久化并投递最终载荷；据 Island 分析，它会通过计划任务驻留，并从 Polygon 区块链上的智能合约获取 C2 服务器地址，以规避域名封禁。部分仓库专门伪装成 AI 技能或 MCP 服务器，开发者一旦安装，恶意代码就运行在 AI 智能体所处的环境中，可直接获得该智能体所持有的 API 密钥、源码仓库与内部系统访问权。
影响评估
FakeGit 之所以难以清除，是结构性问题。首先，封禁清单只覆盖了一小部分恶意仓库——Apiiro 报告发布时，71% 的仓库舰队并未出现在 abuse.ch 的 URLhaus 恶意链接库中。其次，对域名做 DNS 封禁在 GitHub 场景下不可行：若诱饵托管在 github.com 域内，封禁域名等于连带封禁整个 GitHub。第三，备份副本无处不在——研究者发现恶意压缩包散布在 fork、旧版本文件、release 附件、issue 附件以及专门的下载托管仓库中，删掉一个链接，操作者只需把 README 指向另一份副本。因此，逐条删除的猫鼠游戏，防守方几乎每轮都会落后。
防护建议
- 安装任何仓库前核实所有者：复制自知名项目的代码却挂在陌生账号名下，即使 README 再精美也应警惕。
- AI 技能与 MCP 服务器只从官方注册表或厂商自有仓库获取，不要从搜索结果或第三方 README 直接下载。
- 若怀疑已执行 SmartLoader，应按 GitHub 账号可能被入侵处理：撤销活跃会话与访问令牌，改用通行密钥（passkey）登录。
- 轮换受影响机器上出现过的所有凭据、云密钥与 AI 服务商 API 密钥，因为 StealC 专门窃取浏览器数据与保存的机密。
- 对开发终端加强检测：重点关注从 GitHub 下载并解压 ZIP、随后拉起陌生进程的行为。