一名安全研究者在 6 月 18 日发布报告称，他用 GitHub 事件数据和 API 做筛选，找到了约 1 万个疑似分发木马的 GitHub 仓库。
这些仓库有一个反常点：它们不是 fork，却复制了正常项目的提交历史和贡献者信息。页面看上去像一个成熟项目，README 里却多了一个 zip 下载链接。
我更在意的不是“GitHub 上又有恶意仓库”。这件事更像一次规模化分发活动：攻击者把“像正常开源项目”做成了流程。
对维护者和安全研究人员来说，麻烦也在这里。很多风险不是藏在奇怪域名里，而是藏在开发者每天都会看的仓库页、README 和搜索结果里。
异常不在代码里，而在 README 多出来的 zip
研究者最初是在搜索自己项目时发现问题的。
Bing 结果里出现了一个同名、同描述的 GitHub 仓库。提交历史被复制，他本人还显示为贡献者。乍看不像假仓库。
真正新增的东西，是最近一次提交。提交名常见为“Update README.md”，内容是在 README 里加入一个 zip 下载链接。
研究者看到的 zip 包里，典型会有几类文件：cmd 启动脚本、exe 文件、随机命名的 cso 或 txt 文件，以及 lua51.dll。原文没有逆向分析 exe 的具体行为，所以不能直接给它扣上某个家族的帽子。
但检测层面有一个细节很要命：把链接提交到 VirusTotal，可能显示 0 报毒；把 zip 文件本身上传，才会检出木马。
这说明风险不只在仓库页面，也在检测粒度。只扫链接声誉，可能看不到压缩包里的东西。
| 位置 | 看到的现象 | 为什么危险 |
|---|---|---|
| 仓库状态 | 非 fork，但复制正常项目提交和贡献者 | 页面成熟度会骗过第一眼判断 |
| README | 新增 zip 下载链接 | 载荷放在源码之外，用户更容易绕过审查 |
| 提交记录 | 常见提交名为“Update README.md” | 看起来像普通维护动作 |
| VirusTotal | 链接可能 0 报毒，zip 上传后才检出 | 只看 URL 声誉会漏掉风险 |
这类仓库骗的不是完全不懂技术的人。它更容易骗到赶时间的开发者：搜索项目名，点进仓库，看 README，下载工具包。
动作太顺了，警惕心反而低。
从 14 个到约 1 万个，关键是识别模式被修正了
研究者不是靠手工翻仓库数出来的。
他的做法是先用 gharchive 筛选近期 push 事件，再调用 GitHub API 检查提交和 README 内容。GitHub 对外 API 单 token 每小时 5000 次请求，直接扫全量不现实，必须先缩小范围。
原文提到，初版过滤器只找到了 14 个仓库。
问题出在假设太窄。研究者一开始以为这些仓库每隔几小时都会更新，并且最新提交一定会修改 README。后来他修正了条件：允许 24 小时内更新 1 到 24 次，也纳入零变更提交，并关注常见提交名。
匹配样本扩大到约 1 万个。
这个变化很有信息量。它说明这里不是几个孤立恶意仓库，而是有一套可复用的伪装模板：复制项目、补 README 链接、用推送保持活跃痕迹。
但边界也要说清楚。
约 1 万个是研究者基于规则得到的匹配样本，不是 GitHub 官方确认的统计。现有信息也不足以证明所有仓库都属于同一攻击团伙。更稳妥的说法是：它们疑似属于同类恶意软件分发活动。
研究者已经公开了仓库列表和检测脚本 Git Malware Finder。对安全团队来说，这比单篇报告更有用：它给了复查样本、改规则、做内部扫描的起点。
最该行动的是维护者和安全研究人员
这件事不意味着所有 GitHub 项目都不可信，也不代表普通用户会大规模受害。
风险更集中在两类人身上。
一类是开源项目维护者。攻击者复制项目后，借的是你的项目名、提交历史和贡献者关系。用户一旦中招，信任损耗会回到原项目身上。
维护者可以做几件很具体的事：
- 定期搜索项目名、描述和关键 README 句子，尤其是新项目、冷门项目；
- 重点看“非 fork 但提交历史高度相似”的仓库；
- 如果 README 新增外部 zip、网盘链接或可执行文件下载，先截图、保存 URL 和提交记录；
- 向 GitHub 举报时，把原项目地址、可疑仓库地址、恶意提交和下载链接一起提交。
另一类是安全研究人员和企业安全团队。
更值得盯的不是某一个 zip，而是模式能不能被产品化检测：非 fork 克隆提交历史、贡献者列表异常复用、README 新增压缩包外链、短期重复推送。
这套规则也有现实限制。GitHub 承载的是海量正常项目，很多项目确实会在 README 里放 release 包、测试数据或外部工具。平台如果只按“README 有 zip 链接”删除，误伤会很大。
所以更合理的观察点有三个：
| 观察点 | 为什么重要 | 可能影响 |
|---|---|---|
| GitHub 是否清理匹配仓库 | 判断平台是否认可这类模式的风险 | 维护者举报成本可能下降 |
| 搜索引擎是否继续收录这类仓库 | 很多入口来自搜索结果 | 开发者是否需要更谨慎核对来源 |
| zip 是否共享基础设施或构建特征 | 有助于确认是否为同类活动 | 安全团队能否写出更稳定规则 |
原文还提到，2026 年 4 月已有类似报道，披露 109 个假 GitHub 仓库分发 SmartLoader 和 StealC 的案例。这个背景不能直接套到本次所有样本上，但能说明一种趋势：开发者工作流本身正在被当成投递通道。
过去看一个仓库是否可信，很多人会扫几眼星标、提交记录、贡献者和 README。现在这些信任信号有一部分可以被复制。
假作真时，真也会被拖下水。
回到开头那个反常点：危险不在于页面很粗糙，而在于页面太像真的。开源的低门槛仍然是好事，但低门槛不能替代信任校验。