CrowdSec 源码泄露：Tanstack 成突破口
CrowdSec Source Code Leak
CrowdSec 确认其在 2026 年 5 月遭遇了源码泄露事件，涉及 GitHub 仓库中的私有代码部分。泄露内容包括 SaaS 控制台、AWS Cloud 例程及部分连接器与自动化脚本，但核心的 Free Open Source Software（如 Security Engine）因本身公开而未受影响。公司强调，此次事件未泄露任何客户数据、登录凭证或 PII（个人身份信息），因为 CrowdSec 本身不存储此类数据。调查指向 Tanstack 组件可能被植入后门，导致 API 密钥被盗用从而读取私有代码库。尽管泄露代码在四个月内已大幅迭代，且难以脱离 CrowdSec 环境独立运作，团队仍已轮换所有相关凭证并持续监控异常活动。
我们的效率依赖于网络效应和规模，仅凭代码本身无法复制这一优势。
HN 评论区
35- mewse-hn
在我花了一整个早上排查并修复 Debian 13 VPS 上的 CrowdSec 安装问题后，看到这个消息真是有点讽刺。显然，因为我运行的是旧版的 Debian 打包版本，而不是直接从他们那里获取（返回 HTTP 500 错误），他们停止向我的机器提供社区封禁列表了。我让一个大语言模型（LLM）基于公开可用源构建了一个封禁列表，而不是把自己更紧密地绑定在他们的 SaaS 平台上。
- 6thbit
> Tanstack 被攻破很可能就是泄露的向量
....看起来是被植入了后门，用于提取一个拥有读取私有代码库权限的 API 密钥。
...
> 立即轮换所有必需的令牌和凭证，以防止进一步事件发生。
轮换 API 密钥并不能让他们处于“防止进一步事件发生”的位置，对吧？下一个 PyPI/npm 供应链问题照样能拿到新密钥？
我想他们使用该密钥的目的应该接受审查，如果可能的话重新界定范围？
GitHub 允许你限制使用某个 API 密钥发起请求的来源地吗？还是说我们还没发展到那一步？
- sandeepkd
有趣的是，看他们的网站标语，他们声称知道谁在攻击你，却偏偏漏掉了谁攻击了他们自己。
事实证明他们其实不是一家安全公司，只是一个恶意 IP 聚合器。理想情况下，这类聚合器问题最适合由一家值得信赖的非营利公司来运营，因为提供数据需要一定的公信力，而查询数据只需收取象征性的费用来维持运营。
- itintheory
我们部署 CrowdSec 是为了缓解机器人和爬虫攻击。架构本身没问题，但对我们来说误报率实在太高，无法接受。这也许是任何基于 IP 信誉的方法都会遇到的问题。在花了几个月时间准备就绪后，我只用了几天就不得不把它关掉。
- giancarlostoro
听起来是某个漏洞利用了凭证来提取代码，这让我好奇，如果结合使用 Ubikey 和 SSL 证书来访问 Git，是否就能彻底阻止这次泄露。