GitHub Issues 被黑产广告“爆破”了，我该怎么办？
最近几天，技术圈里不太平。
不少开发者和开源项目维护者一觉醒来，发现自己托管在 GitHub 上的仓库，Issues 区域突然被大量垃圾广告刷屏了。这些内容大同小异，基本都围绕着虚拟货币“搬砖套利”、刷单跑分、色情赌博推广等黑产勾当。数量少则几十条，多则成百上千，直接把正常的技术讨论和用户反馈淹得干干净净。
这可不是个别小项目的不幸遭遇。从去年底到今年三月，一场有组织、全自动、专门针对 GitHub Issues 功能的“爆破式攻击”正在持续蔓延。受影响的不再仅仅是个人小项目，甚至一些知名开源框架、企业级中间件的 Issues 也没能幸免。
为什么是 GitHub Issues？
仔细想想也不奇怪。Issues 的门槛太低了，任何人都可以无需审核直接提交。而且 GitHub 页面在搜索引擎里权重极高，黑产广告发出去很快就能被 Google 收录，变成免费的 SEO 引流渠道。再加上 GitHub 原生缺少批量删除或自动拦截的能力，维护者面对成百上千条垃圾信息，删到手软也赶不上机器人发的速度。攻击者只需要批量注册账号、配上代理池，成本低得可怜。
这场“广告爆破”带来的麻烦是实打实的。
开源维护者苦不堪言，本来 Issues 是用来收用户反馈的，现在打开全是“美女荷官在线发牌”。真实的问题被淹没，项目声誉也跟着受损——新用户一看 Issues 区全是广告，第一反应肯定是“这项目没人管了吧？”。
更麻烦的是，很多自动化流程依赖 Issue 的创建事件。垃圾 Issue 一多，CI/CD 机器人跟着疯狂触发，通知轰炸、日志污染，甚至有可能被恶意利用搞出安全漏洞。部分广告里还夹着钓鱼链接，稍有不慎就可能中招。
那 GitHub 官方管了吗？
截至三月底，GitHub 还没有发布针对这次攻击的公开声明。从社区反馈来看，一些明显是机器人的账号确实被平台自动标记封禁了，相关的 Issue 也被打上了“垃圾内容”的标签。但攻击方也在不断换 IP、换账号、换文案，目前 GitHub 的防御还是偏“事后清理”，很难做到“事前拦截”。
所以，如果你是一个项目的维护者，眼下能做的事其实不少。
一个比较简单的办法是启用 Issue 模板，让用户必须按照固定格式填写内容。再配合 GitHub Actions，调用 Cloudflare Turnstile 这类验证服务，自动把不符合规则的 Issue 关掉或标为垃圾。
如果攻击特别猛烈，也可以考虑暂时限制 Issue 的创建权限，比如只允许协作者或赞助用户发帖。不过这招对需要广泛收集反馈的开源项目不太友好，只能作为临时措施。
清理垃圾的时候，GitHub 自带的“标记为垃圾内容”功能可以用起来，每条 Issue 被足够多人标记后会自动隐藏。如果垃圾量太大，也可以写个脚本调用 GitHub API 批量关闭或删除。别忘了顺手把攻击者的账号举报给 GitHub：https://github.com/contact/report-abuse
另外，社区里已经有人开始做第三方防护工具了，比如基于关键词过滤或简单 NLP 的 Anti-Spam Bot。实在扛不住的时候，干脆在 Settings → Features 里暂时把 Issues 关掉，等这阵风头过去再开。
说实话，这次事件把开放协作平台和黑产自动化攻击之间的不对称对抗暴露得很彻底。
GitHub 作为全球最大的代码托管平台，光靠维护者自己硬扛不是长久之计。平台层面如果能提高新账号或低信誉账号创建 Issue 的门槛，加上图形验证码或行为校验，效果会好很多。再给维护者提供批量管理的工具——比如按用户、按关键词一键删除——也能省下大量精力。更理想的是，GitHub 自己能主动识别黑产关键词和模式，在垃圾 Issue 被看到之前就直接拦截或送进待审区。
开源世界的繁荣，靠的是信任和低协作门槛。黑产利用 Issues 做广告，不只是骚扰几个项目，而是在消耗整个开源生态。
如果你是一个开源维护者，建议现在就去看看自己的仓库 Issues。如果你只是一个普通的 GitHub 用户，看到陌生仓库的 Issues 里出现广告，别点链接，也别回复，顺手点一下右上角的“Report content”，帮维护者一把。
GitHub Issues 是用来讨论代码的，不是黑产的免费广告牌。
你的项目最近也中招了吗？欢迎在评论区分享你的应对经验——记得隐藏好 token 等敏感信息。